055.3 Bài 1

Đầu ra chính của hầu hết các dự án mã nguồn mở đều sẽ là phần mềm; vì vậy, các dự án này ít nhất cần phải có các lập trình viên, nhà thiết kế hoặc kiến ​​trúc sư phần mềm, kiểm thử viên, người quản lý phát hành và các chuyên gia khác trong phát triển mã. Tài liệu thường cũng là một phần của các dự án này; vì vậy, cộng đồng của dự án cũng sẽ cần phải có các tác giả, biên tập viên và người đánh giá.

Một số dự án có thể sẽ không tạo ra mã; thay vào đó, chúng lại taọ ra các “sản phẩm có thể chuyển giao được” khác như sách, dự án nghệ thuật hoặc âm nhạc hay báo cáo chính sách. Wikipedia là một ví dụ nổi tiếng về sự hợp tác trong một dự án mã nguồn mở tập trung vào tài liệu văn bản và phương tiện truyền thông. Các dự án này cần có các chuyên gia về thiết kế, sản xuất và phân phối các sản phẩm có thể chuyển giao được.

Các cộng đồng cũng sẽ được hưởng lợi từ nhiều kỹ năng phổ quát khác như tiếp thị và truyền bá, quản lý, tư vấn pháp lý, hỗ trợ về nghệ thuật để tạo ra logo hoặc sơ đồ trong tài liệu cũng như các kỹ năng duy trì trang web của dự án hay các công cụ truyền thông khác. Các dự án mã nguồn mở có thể sẽ tổ chức các cuộc họp mặt thực tế hay thậm chí là các hội nghị nơi họ sẽ cần tới các chuyên viên tổ chức sự kiện để biến những hội nghị đó thành hiện thực.

Các phần tiếp theo sẽ cung cấp cho chúng ta một cái nhìn chung về các loại kỹ năng mà một cộng đồng tìm kiếm. Những vai trò chung này có thể được chia nhỏ hơn thành nhiều nhiệm vụ tập trung khác nhau. Một ví dụ đơn giản về các nhiệm vụ như vậy là khi một tác giả biên tập lại tác phẩm của các tác giả khác.

Đối với các lập trình viên, phạm vi kinh nghiệm là một yếu tố quan trọng. Một dự án lành mạnh sẽ luôn cần tới một số lập trình viên kỳ cựu (hoặc lập trình viên_cao cấp) hiểu rõ về mã và tiêu chuẩn mã hóa của dự án cũng như những lập trình viên _non trẻ có khả năng cung cấp các ý tưởng mới và trợ giúp các tác vụ đơn giản như sửa lỗi. Các lập trình viên non trẻ luôn được kỳ vọng sẽ phát triển lên thành thế hệ kỳ cựu tiếp theo.

Việc đảm bảo chất lượng của mã cần tới một sự kiểm soát nghiêm ngặt về những gì được đưa vào kho lưu trữ trung tâm chia sẻ với người dùng. Do đó, một số lập trình viên cao cấp sẽ được chỉ định trạng thái người được uỷ thác (committer). Họ sẽ chịu trách nhiệm kiểm tra các đóng góp về chất lượng, tính hữu dụng và sự tuân thủ các tiêu chuẩn về mã hóa. Họ có đặc quyền chấp nhận mã được đề xuất vào kho lưu trữ. Các nhà phát triển đóng góp khác sẽ gửi mã cho người được uỷ thác để họ xét duyệt.

Rất nhiều người được uỷ thác và những lập trình viên kỳ cựu khác cũng sẽ đào tạo các nhà phát triển đóng góp mới để hướng dẫn họ về các tiêu chuẩn và thông lệ thực hành cần thiết để mã của họ được chấp nhận.

Một số người được uỷ thác không biết cách trân trọng món quà mà các nhà phát triển đóng góp mang lại. Nếu đóng góp không đạt về chất lượng hoặc tiêu chuẩn mã, người được uỷ thác hoàn toàn có thể từ chối đóng góp đó. Tuy nhiên, việc từ chối đóng góp có thể sẽ khiến các nhà phát triển đóng góp tiềm năng nản lòng và có thể khiến cộng đồng mất đi một cơ hội mang tính giáo dục có giá trị. Hãy nhớ rằng một người được uỷ thác tốt cũng sẽ đóng vai trò như một nhà cố vấn. Vì vậy, họ sẽ đưa ra gợi ý cho các nhà phát triển đóng góp để giúp mã đạt mức tiêu chuẩn cũng như để đồng hành với họ theo thời gian. Nếu đóng góp thực sự không thể sử dụng được, ít nhất nhà phát triển đóng góp cũng nên được cảm ơn và khuyến khích đóng góp trên các phương diện khác cho dự án. Điều quan trọng nhất là giúp tất cả mọi người khám phá và tinh chỉnh các kỹ năng của chính họ.

Khi một công ty bắt đầu một dự án mã nguồn mở, đôi khi công ty sẽ chỉ định người được uỷ thác từ chính các nhân viên của mình để đảm bảo rằng công ty có thể kiểm soát được hướng đi và chất lượng của dự án. Tuy nhiên, các công ty cũng thường cho phép những người không phải nhân viên nhưng thể hiện được kỹ năng và sự tận tâm trong việc trở thành người được uỷ thác.

Trưởng dự án (project lead) sẽ đưa ra các quyết định quan trọng (như những tính năng mới nào sẽ được hỗ trợ). Những trưởng dự án này thường cũng sẽ phải đưa ra các quyết định không liên quan đến mã hóa như cách quảng bá dự án, giải quyết các bất đồng lớn và nhận tài trợ. Các trưởng dự án và người được uỷ thác sẽ làm việc chặt chẽ với các nhà quản lý phát hành để quyết định xem khi nào cơ sở mã được coi là ổn định và sẵn sàng được chia sẻ với người dùng.

Một số dự án chỉ có một trưởng dự án duy nhất thường được gọi là nhà độc tài tốt bụng (benevolent dictator). Đây thường là người đã bắt đầu dự án (Linus Torvalds là một ví dụ điển hình trong trường hợp của Linux) và cũng là người có thẩm quyền hay thậm chí là có sức hút lớn. Tuy nhiên, hầu hết các dự án đều chọn thành lập một ủy ban nhỏ các trưởng dự án thay vì một nhà độc tài tốt bụng duy nhất. Ngay cả dự án Linux cũng đã chuyển sang cách tiếp cận này.

Các dự án cũng có thể yêu cầu các nhà phát triển đóng góp cụ thể cung cấp hỗ trợ người dùng trên diễn đàn của dự án. Các dự án lành mạnh nên có nhiều người dùng hiểu biết hỗ trợ lẫn nhau.

Chúng ta sẽ kết thúc phần này bằng một vai trò rất quan trọng: người quản lý cộng đồng (community manager). Đây là người chịu trách nhiệm duy trì giao tiếp cởi mở và mang tính xây dựng để đảm bảo cộng đồng tiến triển theo đúng mục tiêu của nó. Người quản lý cộng đồng phải biết cách đưa các nhà phát triển đóng góp lên cùng chiến tuyến và khuyến khích họ, giải quyết các tranh cãi, bảo vệ các thành viên cộng đồng khỏi bị lạm dụng và thực hiện các nhiệm vụ khác để duy trì sức khỏe của cộng đồng.

Trên nhiều phương diện, các dự án mã nguồn mở sẽ bao gồm các nhiệm vụ tương tự như các dự án truyền thống được thực hiện trong một tổ chức duy nhất (ví dụ như việc mọi mã đều yêu cầu kiểm thử). Tuy nhiên, theo một số cách, các dự án mã nguồn mở cũng sẽ khác với các dự án độc quyền nơi chỉ một nhóm người hạn chế mới được phép thay đổi mã và mã nguồn thường bị ẩn khỏi công chúng.

Ví dụ: các công ty thường sẽ chỉ định nhân viên đảm bảo chất lượng (Quality Assurance - QA) đã qua đào tạo để kiểm thử mã. Tuy nhiên, nhiều dự án mã nguồn mở sẽ chỉ yêu cầu người dùng thử nghiệm mỗi bản phát hành (các dự án độc quyền cũng sẽ yêu cầu người dùng của họ tham gia vào quá trình kiểm thử bên cạnh QA).

Một ví dụ khác về sự khác biệt: một dự án độc quyền thường sẽ giao cho các nhà phát triển được trả lương những nhiệm vụ cụ thể và cho họ biết cần dành bao nhiêu thời gian mỗi tuần cho các nhiệm vụ đó. Một số dự án mã nguồn mở lại được hưởng lợi từ những nhà phát triển đóng góp được trả lương bởi người sử dụng lao động của họ, hoặc đôi khi thậm chí được chính dự án tuyển dụng, và sẽ được giao nhiệm vụ theo cùng cách với các nhà phát triển độc quyền. Trong hầu hết các dự án lành mạnh, rất nhiều đóng góp lại đến từ các tình nguyện viên chỉ thực hiện các nhiệm vụ khi thời gian của họ cho phép. Vì dự án không dựa vào các tình nguyện viên để hoàn thành đúng tiến độ nên bản phát hành mã nguồn mở có thể bị trì hoãn cho đến khi các nhà phát triển cảm thấy các tính năng đã sẵn sàng hoặc có thể được phát hành vào những thời điểm cố định với bất kỳ tính năng nào đã sẵn sàng.

Giao tiếp rất quan trọng đối với cả các dự án độc quyền lẫn các dự án mã nguồn mở nhưng lại thường được tiến hành theo các cách khác nhau. Các dự án độc quyền thường tập hợp một nhóm trong văn phòng và tổ chức các cuộc họp ngắn tuân thủ lịch trình thường xuyên theo một phương pháp phát triển như SCRUM. Vì các dự án mã nguồn mở được phân bổ theo địa lý nên các phương pháp như vậy rất hiếm. Thay vào đó, giao tiếp sẽ diễn ra trực tuyến và không đồng bộ.

Tóm lại, các dự án phần mềm mã nguồn mở và tự do thường đạt được các mục tiêu tương tự như các dự án độc quyền nhưng theo những cách khác.

Báo cáo lỗi là một phần quan trọng của quá trình phát triển phần mềm với một tập hợp các vai trò riêng do chính nó tạo ra. Sẽ phải có người theo dõi cơ sở dữ liệu lỗi và chỉ định mức độ ưu tiên. Nếu một lỗi được tính là nghiêm trọng (và đặc biệt là nếu lỗi có thể làm suy yếu tính bảo mật của phần mềm), nó nên chỉ định cho một chuyên viên bảo trì có năng lực để sửa chữa.

Trưởng dự án và quản lý cộng đồng nên xem xét sự tham gia của các thành viên vào dự án và quyết định xem có thiếu sót gì không. Liệu có phải có quá ít người sẵn sàng kiểm thử mã không? Liệu có bị thiếu tài liệu không? Có phải có quá nhiều thành viên kỳ cựu hoặc thành viên dự án cấp cao rời đi mà không được thay thế hay không? Trưởng dự án và quản lý cộng đồng có thể tập trung vào việc tuyển dụng để lấp đầy các vị trí cần thiết.

Trưởng dự án và quản lý cộng đồng của các dự án lớn thường cũng sẽ thu thập các số liệu để tìm hiểu những thông tin quan trọng (như liệu các lỗi quan trọng có được khắc phục kịp thời hay không).

Như đã được giải thích trong phần trước, những người đưa mã, tài liệu hoặc các mục khác vào kho lưu trữ trung tâm được gọi là các nhà phát triển đóng góp. Các thành viên dự án chấp thuận các đóng góp và nhận chúng vào kho lưu trữ được gọi là người được uỷ thác. Một số thành viên sẽ đảm nhận các vai trò chung khác trong phát triển phần mềm.

Mặc dù thuật ngữ nhà phát triển đóng góp thường được dành riêng cho người phát triển mã hoặc một phần nào khác của dự án chính thức nhưng bất kỳ ai tham gia vào thành công của dự án cũng đều đã đóng góp theo một cách nào đó và nên được cảm ơn vì lý do này. Những đóng góp ít chính thức hơn này bao gồm việc báo cáo lỗi, trả lời câu hỏi trên diễn đàn, quyên góp hoặc gây quỹ và quảng bá dự án cho những người bên ngoài dự án.

Giống như các dự án độc quyền, các dự án mã nguồn mở cũng sẽ hỏi người dùng về mong muốn của họ trên phương diện tính năng, cải thiện hiệu suất hoặc các thay đổi khác đối với dự án. Những người dùng này đều mang tới những đóng góp quan trọng bằng cách nêu lên ý kiến ​​của họ.

Mặc dù nhiều dự án mã nguồn mở được tạo ra bởi những cá nhân nhiệt thành hoặc các nhóm tình nguyện viên nhỏ nhưng họ sẽ thường tìm kiếm sự hỗ trợ của các tổ chức khi các dự án trở nên lớn hơn. Sự hỗ trợ của các tổ chức có thể ở dưới nhiều hình thức. Nhìn chung, các tổ chức thường thực hiện những đóng góp này khi một dự án mã nguồn mở có thể đáp ứng nhu cầu kinh doanh của họ với chi phí thấp và đáng tin cậy hơn so với việc tái phát minh các tính năng tương tự trong mã độc quyền. Nhiều tổ chức cũng rất coi trọng các đảm bảo do giấy phép mã nguồn mở hoặc tự do mang lại.

Một số người theo chủ nghĩa lý tưởng không tin vào các tập đoàn hoặc tổ chức lớn và sẽ muốn giữ các dự án mã nguồn mở hoàn toàn không bị ảnh hưởng bởi họ. Trong những năm qua, kiểu suy nghĩ tương đối dễ lý giải này đã trở nên ít phổ biến hơn. Hầu hết những người ủng hộ mã nguồn mở đều tin rằng các tập đoàn và các tổ chức khác có thể cung cấp nhiều nền tảng quan trọng cho các dự án mã nguồn mở.

Nhiều dự án mã nguồn mở được bắt đầu trong một tổ chức và thậm chí có thể được dựa trên mã độc quyền mà công ty quyết định mở ra. Để kiếm tiền, công ty có thể quyết định giữ quyền kiểm soát chặt chẽ đối với dự án và chia dự án thành các phần mở và độc quyền: đây được gọi là mô hình lõi mở (open core). Có nhiều người sáng lập dự án bắt đầu dự án dưới dạng mã nguồn mở nhưng dần từ đó thành lập ra một công ty; công ty này có thể hoặc không sử dụng mô hình lõi mở.

Các dự án khác thường sẽ cố gắng đảm bảo rằng không có công ty nào kiểm soát hướng đi của họ. Việc duy trì sự độc lập thường đòi hỏi phải có sự tham gia của nhiều tổ chức ủng hộ để không ai có đủ quyền lực để đưa ra các quyết định độc đoán.

Các tổ chức sẽ hỗ trợ mã nguồn mở như thế nào? Như đã đề cập tới trước đây, nhiều tổ chức sẽ đưa các nhân viên được trả lương vào các dự án. Ngoài ra, họ có thể thuê những cá nhân có năng suất cao đã đóng góp cho dự án với tư cách là tình nguyện viên và cũng đã có sự phát triển về chuyên môn trong dự án. Đây là một con đường rất có giá trị giúp cho sinh viên và những nhà phát triển đóng góp tình nguyện khác thăng tiến trong sự nghiệp của mình.

Những công ty cần các phần mở rộng không thu hút người dùng khác không nên gây sức ép để buộc dự án mã nguồn mở phải thêm các tính năng bổ sung; họ nên trả tiền cho nhân viên của mình để viết các tính năng đó mà không phải đóng góp chúng lại cho dự án.

Một ví dụ thú vị về sự căng thẳng có thể xảy ra do nhu cầu của công ty được thể hiện qua hệ điều hành Android nổi tiếng; hệ điều hành này dựa trên Linux và được Google phát triển để điều khiển các thiết bị di động của mình. Một số thay đổi do Google thực hiện đối với Linux sẽ được đóng góp ngược trở lại cho cộng đồng Linux, trong khi những thay đổi khác sẽ chỉ xuất hiện trong Android. Các nhà phát triển Linux đôi khi cũng sẽ từ chối những thay đổi do Google mang lại — giống như việc mọi dự án đều sẽ chỉ chọn những đóng góp thích hợp.

Có nhiều lý do khiến một công ty hoặc một nhóm nhà phát triển tạo ra một phiên bản riêng cho mã. Lý tưởng nhất là họ có thể đáp ứng nhu cầu của chính mình bằng cách thêm một thư viện tùy chọn hoặc một chuỗi mã có thể được loại trừ trong quá trình biên dịch. Tuy nhiên, đôi khi một nhóm sẽ cảm nhận được một nhu cầu lớn không tương thích với định hướng mà các nhà lãnh đạo dự án đã chọn. Khi một phiên bản riêng biệt của dự án được tạo ra, nó sẽ được gọi là nhánh (fork).

Việc phân nhánh từng được coi là đại diện cho sự thất bại trong hợp tác; nhưng ngày nay, nó đã được chấp nhận nhiều hơn. Thông thường, những người tạo ra nhánh sẽ thiết lập một kho lưu trữ mới và bắt đầu một dự án mới. Một số người sẽ làm việc trên cả dự án gốc lẫn dự án nhánh.

(Hãy lưu ý rằng GitHub sử dụng từ “nhánh” cho một hiện tượng rất khác: nhân bản hoặc tạo bản sao của mã dự án để làm việc trên đó một cách riêng biệt.)

Bên cạnh mã, nhiều công ty còn đóng góp cả về mặt tài chính. Họ có thể tài trợ trên các phương diện như tiếp thị hay hội nghị. Họ cũng có thể tham gia vào hội đồng quản trị và đưa ra lời khuyên chuyên môn về định hướng và chiến lược của dự án.

Một ví dụ về tầm quan trọng của những “hỗ trợ mềm” như vậy về máy chủ web Apache cũ. Dự án đã có bước tiến lớn ngay từ đầu khi được IBM quan tâm. Các luật sư của IBM đã chỉ cho dự án cách tạo ra các biện pháp bảo vệ pháp lý và một cuộc họp do IBM chi trả đã giúp ban lãnh đạo Apache tạo ra một tổ chức vững mạnh.

Để duy trì tính độc lập, nhiều dự án mã nguồn mở đã hình thành một quỹ phi lợi nhuận hoặc tham gia một quỹ đã có sẵn. Các ví dụ nổi tiếng về các quỹ hướng dẫn các dự án mã nguồn mở bao gồm Quỹ Linux (Linux Foundation), Quỹ Apache (Apache Foundation) và Quỹ Eclipse (Eclipse Foundation).

Sự hỗ trợ của một tổ chức rất có giá trị vì nó có thể cung cấp các dịch vụ hậu cần mà hầu hết các nhà phát triển phần mềm không muốn giải quyết: hỗ trợ pháp lý như đăng ký nhãn hiệu, bồi thường và cấp phép; hỗ trợ huy động vốn; cơ sở hạ tầng (như cơ sở dữ liệu lỗi và trang web), v.v.

Cũng giống như sách, nhạc và các nỗ lực sáng tạo khác, phần mềm cũng liên quan đến mối quan hệ phức tạp giữa các nhà phát triển, các tổ chức phân phối đóng góp của họ và công chúng nói chung. Về cơ bản, những người đóng góp phải thực hiện một số bước để hợp thức hóa quyền của một dự án mã nguồn mở để có thể sử dụng và phân phối mã của mình.

Vì vậy, nhiều tổ chức mã nguồn mở sẽ yêu cầu những người đóng góp ký một thỏa thuận cấp phép cho người đóng góp (Contributor License Agreement - CLA). Đôi khi, người đóng góp sẽ cung cấp luôn mã cho dự án. Dự án sẽ sở hữu mã và mọi quyền đối với mã đó giống như một công ty độc quyền sở hữu mã mà họ trả tiền cho nhân viên của mình để phát triển.

Các CLA khác sẽ để lại một số quyền trong tay của những cá nhân đóng góp. Những người đóng góp có thể sẽ thích sự linh hoạt này vì họ có thể tiếp tục đóng góp cùng một mã cho một dự án khác hoặc xây dựng doanh nghiệp của riêng họ dựa trên đó.

Để cân đối các đóng góp khác nhau từ những bên khác nhau, giấy phép được cấp cho mã là một yếu tố rất quan trọng. Nhân Linux là một trong những dự án để lại quyền sở hữu trong tay những người đóng góp; do đó, đến nay đã có hàng ngàn người sở hữu quyền đối với mã Linux. Tuy vật, tất cả những người đóng góp cho mã lõi đều đưa nó vào Giấy phép Công cộng Chung GNU (phiên bản 2). Do đó, Linux có thể được tất cả mọi người sử dụng, thay đổi và tái phân phối.

Việc sử dụng một giấy phép duy nhất cho tất cả mọi mã trong một dự án là cách đơn giản nhất để đảm bảo rằng không có điều gì cản trở việc phân phối và sử dụng mã. Tuy nhiên, đôi khi một dự án sẽ cho phép các phần khác nhau của mã được đóng góp theo các giấy phép khác nhau, thường là vì dự án muốn tận dụng một số mã đã tồn tại trước đó đã được phát hành theo một giấy phép khác. Các chuyên gia cấp phép nên đảm bảo rằng các giấy phép trong dự án phải tương thích với nhau.

Nhiều cộng đồng trực tuyến nổi tiếng với việc ngôn luận không giới hạn (một cách nghĩ khá vô tư rằng “thế nào cũng được”) dẫn đến nhiều tình huống lạm dụng lời nói và cãi vã. Ngày nay, hầu hết các cộng đồng mã nguồn mở đều đang đấu tranh với khuynh hướng này (vốn rất dễ được tiếp nhận). Ngược lại, các cộng đồng hiện đại đều muốn mọi người có tính xây dựng, lịch sự, tôn trọng và không phân biệt bất kể giới tính, nhóm dân tộc, kiểu tính cách, v.v.

Kỳ vọng của các thành viên nhóm thường được nêu rõ trong bản quy tắc ứng xử giải thích cách tương tác với những thành viên khác trong dự án, cả trực tuyến lẫn trực tiếp. Để có hiệu quả, bản quy tắc ứng xử này phải được thực thi bởi người quản lý cộng đồng và các lãnh đạo của dự án.

Đôi khi, một cá nhân công khai chế giễu hoặc hạ thấp một thành viên khác của cộng đồng sẽ bị trục xuất tạm thời hoặc vĩnh viễn. Trong những trường hợp khác, quản lý cộng đồng hoặc một đồng nghiệp chỉ cần công khai tuyên bố rằng hành vi đó đã vi phạm quy tắc ứng xử và có thể cần trao đổi với người vi phạm bên ngoài diễn đàn. Thông thường, người vi phạm trước đó đã cảm thấy thất vọng, thiếu sự chú ý hoặc kiệt sức, và các thành viên trong cộng đồng có thể giúp người vi phạm tìm ra một biện pháp phù hợp hơn để thể hiện bản thân.

Ngoài hành vi xã hội, cộng đồng cũng sẽ thiết lập các tiêu chuẩn về chất lượng. Tiêu chuẩn chính thức nhất bao gồm hướng dẫn cấu trúc mã (để cố gắng đảm bảo rằng tất cả mã có thể trông giống nhau). Các hướng dẫn có thể nhắc nhở các nhà phát triển về các thông lệ thực hành tốt như sử dụng các dấu ngoặc bao bọc các khối mã hoặc có thể chỉ định các chi tiết như cách đặt tên biến và loại thụt lề cần sử dụng.

Các cộng đồng mã nguồn mở cũng có các quy tắc xung quanh việc phát hành mã hoặc các sản phẩm khác. Một số dự án sẽ thiết lập thời gian cố định cho các bản phát hành (ví dụ: Ubuntu đã hứa hẹn một phiên bản hỗ trợ dài hạn (LTS) mới sau mỗi hai năm cùng với các bản phát hành tạm thời thường xuyên hơn). Các dự án khác có thể duy trì một danh sách các tính năng mới và các bản sửa lỗi mà họ muốn trong bản phát hành sắp tới cũng như phê duyệt bản phát hành khi mọi thứ trong danh sách đã được thực hiện. Không giống như hầu hết các doanh nghiệp, các cộng đồng mã nguồn mở thường không thiết lập thời hạn cho những người tham gia vì không ai có thể yêu cầu quá nhiều từ những tình nguyện viên.

Ngoài thỏa thuận cấp phép cho người đóng góp đã được đề cập tới ở trên, một số dự án sẽ yêu cầu người đóng góp ký giấy chứng nhận xuất xứ của nhà phát triển (Developer Certificate of Origin - DCO). Trong DCO, người đóng góp sẽ cam kết rằng họ có quyền hợp pháp để tặng mã.

Ngoài thỏa thuận cấp phép cho những nhà phát triển đóng góp đã đề cập tới ở trên, một số dự án sẽ yêu cầu họ ký giấy chứng nhận xuất xứ của nhà phát triển (DCO). Trong DCO, nhà phát triển đóng góp sẽ hứa rằng họ có quyền hợp pháp để tặng mã.

DCO được cho là sẽ đảm bảo rằng nhà phát triển đóng góp thực sự đã viết mã hoặc có được mã một cách hợp pháp. Dự án mã nguồn mở phụ thuộc vào sự trung thực của người đóng góp và những thông tin họ điền vào chứng chỉ.

Các nhà khoa học xã hội đã khẳng định rằng các dự án và công ty được hưởng lợi từ việc có nhiều thành viên với các giới tính, chủng tộc, hoàn cảnh kinh tế, quốc tịch và khả năng khác nhau. Mọi tổ chức đều mang một xu hướng tự nhiên của con người là gắn kết với những cá nhân khác giống với họ. Vì vậy, một cộng đồng coi trọng sự đa dạng và công bằng phải có ý thức đào tạo các thành viên của mình trở nên cởi mở hơn với những người khác biệt so với họ. Phong trào thực hiện lý tưởng này được gọi là sự đa dạng, công bằng và hòa nhập (Diversity, Equity, Inclusion - DEI).

Quy tắc ứng xử là điểm khởi đầu cho DEI. Quy tắc này phải hoan nghênh những người thuộc các giới tính, chủng tộc, v.v. khác nhau. Mọi hành vi vi phạm quy tắc ứng xử đều phải được xử lý kịp thời với một thái độ phản đối rõ ràng. Điều này là do một số nhóm thiểu số đã phải chịu đựng sự kỳ thị và những bình luận tiêu cực trong suốt cuộc đời của họ, và chỉ một tương tác tồi tệ trên diễn đàn của một cá nhân nào đó cũng có thể khiến họ quyết định rằng họ không còn lý do gì để tham gia vào cộng đồng nữa. Phản ứng nhanh chóng đối với các hành vi gây hấn có thể trấn an họ, để họ biết được rằng cộng đồng đang ủng hộ họ.

Nhưng DEI còn đi xa hơn thế nữa. Cộng đồng nên tiếp cận các nhóm chưa được đại diện nhiều. Ví dụ: nếu đang phát triển một ứng dụng tìm kiếm việc làm, chúng ta nên đảm bảo rằng nó sẽ hiển thị cả việc làm cho những người thu nhập thấp lẫn những người thuộc tầng lớp trung lưu và thượng lưu. Chúng ta cũng nên quảng cáo ứng dụng trong cộng đồng thu nhập thấp và tuyển dụng thành viên từ những cộng đồng đó để thử nghiệm.

Một cộng đồng có thể hưởng lợi từ việc tìm kiếm các tổ chức đào tạo những người từ các cộng đồng thiểu số và từ đó có thể tuyển dụng các thành viên mới cho nhóm của mình. Nhiều tổ chức như vậy đã được thành lập tại các khu vực địa phương cũng như các khu vực không được biết đến rộng rãi trên phạm vi toàn quốc hoặc quốc tế.

Việc hiểu được nhu cầu của các cộng đồng thiểu số chính là chìa khóa. Liệu những người khiếm thị có thể truy cập vào trang web của chúng ta không? Chúng ta có dịch tài liệu của mình sang các ngôn ngữ mà cộng đồng mục tiêu quen thuộc không? Có lẽ chúng ta cần tạo ra các diễn đàn cụ thể sử dụng các ngôn ngữ khác nữa.

Hầu hết các giao tiếp trong cộng đồng mã nguồn mở đều là các giao tiếp không đồng bộ và trực tuyến. Tuy nhiên, nếu có các cuộc họp hoặc phiên trò chuyện đồng bộ, hãy xem xét về vị trí địa lý của mọi thành viên và tìm cách để giúp tất cả mọi người đều có mặt. Ví dụ: khi mọi người đến từ nhiều quốc gia và khu vực đang cùng giao tiếp bằng tiếng Anh, hãy cố gắng giữ cho từ vựng và ngữ pháp thật đơn giản.

Cuối cùng, nếu có thành viên là người thuộc nhóm thiểu số trong nhóm, hãy đảm bảo chúng ta đang lắng nghe họ. Một triệu chứng dễ nhận thấy của sự phân biệt đối xử là không coi trọng những gì các thành viên thuộc nhóm thiểu số nói hoặc là đánh giá thấp tầm quan trọng của chúng.

Mặt khác, đừng tạo gánh nặng cho các thành viên thuộc nhóm thiểu số bằng việc khiến họ phải giải thích về nhu cầu từ cộng đồng của họ — mọi người đều nên được giao nhiệm vụ tìm hiểu về chúng. Các thành viên thuộc nhóm thiểu số có thể thực hiện hoạt động tiếp cận có giá trị cho dự án, nhưng chúng ta không nên gây áp lực để buộc họ phải làm điều này. Mỗi người đều nên có các cơ hội bình đẳng để tham gia theo cách họ muốn mà không cần phải là một nhóm thiểu số tượng trưng.