Mô hình điều hành người tài lãnh đạo

Meritocratic governance model

By Ross Gardler, Gabriel Hanganu, Published: 15 February 2010, Reviewed: 14 February 2012

Theo: http://www.oss-watch.ac.uk/resources/meritocraticGovernanceModel

Bài được đưa lên Internet ngày: 14/02/2012

Lời người dịch: Bên cạnh mô hình điều hành của nhà độc tài nhân từ, còn có mô hình điều hành theo chế độ người tài lãnh đạo, thường thấy trong các dự án phần mềm tự do nguồn mở. Bài viết này đưa ra một mẫu template ví dụ về mô hình thứ 2 ở trên. “Một tài liệu điều hành rõ ràng và minh bạch là phần chính của bất kỳ dự án phát triển mở nào. Nó xác định các qui tắc tham gia trong cộng đồng và mô tả mức độ ảnh hưởng nào một thành viên cộng đồng có thể kỳ vọng để có đối với một dự án. Bổ sung thêm, nó cho phép các thành viên quyết định mức độ tham gia của họ với cộng đồng đó. Trong trường hợp của chế độ người tài lãnh đạo, nó cũng đưa ra một cách thức rõ ràng để đóng góp và một hệ thống tưởng thưởng trực quan cao. Mô hình điều hành ví dụ này tới từ đầu dân chủ hơn của phổ kiểm soát được thấy trong các dự án phát triển mở. Ở một đầu khác, mô hình điều hành của nhà độc tài nhân từ (bản dịch tiếng Việt) mô tả một mô hình trong đó một cá nhân duy nhất nắm nhiệm vụ duy trì sự đồng thuận trong dự án, và nếu cần có tiếng nói cuối cùng trong qui trình ra quyết định”. Nếu bạn muốn xây dựng một cộng đồng xung quanh một phần mềm tự do nguồn mở, thì bài này chắc chắn là dành cho bạn để tham khảo.

Điều hành theo chế độ người tài lãnh đạo là một mô hình được thấy là phổ biến trong đó những người tham gia giành được ảnh hưởng đối với một dự án thông qua sự thừa nhận những đóng góp của họ. Quỹ Phần mềm Apache - ASF (The Apache Software Foundation) có lẽ là ví dụ nổi tiếng nhất về một cộng đồng người tài lãnh đạo phạm vi rộng. Quỹ này vận hành với một cấu trúc 'phẳng' hầu như hoàn toàn, có nghĩa là mỗi người có thiện chí đóng góp có thể tham gia với các dự án của họ ở bất kỳ mức độ nào. Ở đầu khác của phổ 'kiểm soát' là mô hình điều hành của nhà độc tài nhân từ (bản dịch tiếng Việt), nó được một cá nhân dẫn dắt.

Mô hình điều hành theo đó một dự án được quản lý được mô tả trong một tài liệu điều hành. Trong phần 2 chúng tôi đưa ra một mẫu template cho các dự án mong muốn áp dụng mô hình theo chế độ người tài lãnh đạo và tạo ra tài liệu điều hành của riêng chúng. Mẫu template này có thể được sử dụng lại hoàn toàn hoặc được sửa đổi để phù hợp với các nhu cầu cá nhân. Giống như hầu hất các tư liệu của chúng tôi, nó là sẵn sàng theo một giấy phép Creative Commons và có thể vì thế được sử dụng lại và được sửa đổi, miễn là ghi cong cho OSS Watch được giữ lại. Để có thông tin về mục đích của các mô hình điều hành, hoặc về một thảo luận những lợi ích của mô hình này so với mô hình kia, hãy xem tài liệu chung về các mô hình điều hành (bản dịch tiếng Việt) của chúng tôi.

Giới thiệu

Bất chấp những khác biệt rõ ràng về cấu trúc giữa chế độ người tài lãnh đạo và các nhà độc tài nhân từ, cả 2 đều góp vào cùng các nguyên tắc như nhau của nguồn mở về việc chia sẻ mã nguồn và việc khuyến khích mỗi người đóng góp trở ngược về cho cộng đồng. Vì thế không ngạc nhiên là các ban quản lý dự án theo chế độ người tài lãnh đạo và các nhà độc tài nhân từ đều thực thi sức mạnh ra quyết định của họ thông qua lòng trung thành hơn là phù hợp với pháp luật. Tất cả họ đều biết rằng các thành viên là tự do để lấy mã nguồn và tạo ra các dự án lựa chọn thay thế. Trong thực tế, khả năng để rẽ nhánh này là rất quan trọng cho sự lành mạnh của các cộng đồng nguồn mở. Điều này là vì nó đảm bảo rằng những người đã tham gia trong điều hành dự án đấu tranh để làm cho các quyết định đúng cho cộng đồng, hơn là cho một cá nhân hoặc công ty duy nhất.

Tuy nhiên, có những khác biệt có thể lưu ý thấy giữa 2 mô hình đó, đặc biệt với cách mà việc ra quyết định trong cộng đồng được triển khai. Tại hầu hết các cực của nó, một mô hình điều hành theo chế độ người tài lãnh đạo dường như bỏ đi sự kiểm soát đối với các thành viên cộng đồng để đáp lại những đóng góp của họ cho dự án. Nhưng trong thực tế, sự kiểm soát không được trao mà không có sự cân nhắc. Một chế độ người tài lãnh đạo không phải là một nền dân chủ; đó là, không phải mọi người có được một phiếu bầu ràng buộc. Chỉ những người mà chiếm được nó thông qua sự đóng góp tích cực cho dự án có được một phiếu bầu ràng buộc. Điều này cho phép những người lãnh đạo dự án đảm bảo rằng chỉ những người mà chia sẻ một tầm nhìn chung và, thật quan trọng, có thiện chí để làm việc hướng tới tầm nhìn được chia sẻ đó, được trao ủy quyền ra quyết định.

'Tính phẳng' của một cấu trúc dự án do người tài lãnh đạo tới từ thực tế là một khi ai đó có quyền ra quyết định, thì họ chính xác có quyền y hệt như mọi người khác. Một khía cạnh khác của tính phẳng này là các trách nhiệm ra quyết định thường được giữ lại cho những người có thiện chí và có khả năng để hiểu, và đại diện phù hợp, cho các quan điểm của cộng đồng rộng lớn hơn. Vì thế, khi một quyết định quan trọng được thực hiện, những người với một phiếu bầu được kỳ vọng để đại diện cho các quan điểm của những người mà còn chưa giành được một phiếu bầu.

Các dự án theo chế độ người tài lãnh đạo, giống như tất cả các dự án, thường bắt đầu cuộc sống với một số lượng nhỏ những người ra quyết định, có khả năng thậm chí chỉ là một người duy nhất. Hệ quả là, những giai đoạn đầu cảu quản lý dự án là ít khác với những gì được thấy trong mô hình nhà độc tài nhân từ. Sự khác biệt chính là đội khởi xướng đưa ra một cơ chế cho sự phân phối kiểm soát từ 'nhà độc tài' sang một cấu trúc phẳng theo sự thừa nhận về sự đóng góp.

Trong phần tiếp theo chúng tôi đưa ra một mẫu template cho một mô hình điều hành theo chế độ người tài đóng góp, các dự án đó có thể sử dụng như là cơ sở cho việc xây dựng tài liệu điều hành của riêng chúng. OSS Watch có thể giúp bạn tinh chỉnh mô hình đó cho phù hợp với các nhu cầu đặc thù của bạn.

Mẫu template đó dựa vào mô hình theo chế độ người tài lãnh đạo được sử dụng trong Quỹ Phần mềm Apache (ASF). Tuy nhiên, nên lưu ý là, các dự án riêng rẽ của ASF tự do thiết kế nội qui của riêng chúng. Vì thế, mô hình này có lẽ không y hệt như nhau được sử dụng trong bất kỳ dự án nào của ASF.

Mẫu template cho một tài liệu điều hành theo chế độ người tài lãnh đạo

Tổng quan

Đây là một dự án cộng đồng dựa vào sự đồng thuận, chế độ người tài lãnh đạo. Bất kỳ ai với một sự quan tâm trong dự án có thể tham gia cộng đồng, đóng góp cho thiết kế của dự án và tham gia trong qui trình ra quyết định. Tài liệu này mô tả cách mà sự tham gia đó diễn ra và cách để thiết lập để có được giá trị trong cộng đồng của dự án.

Các vai trò và trách nhiệm

Người sử dụng

Những người sử dụng là các thành viên cộng đồng có một nhu cầu đối với dự án. Họ là những thành viên quan trọng nhất của cộng đồng và không có họ thì dự án có thể không có mục đích. Bất kỳ ai cũng có thể là một người sử dụng; không có những yêu cầu đặc biệt nào.

Dự án yêu cầu những người sử dụng của minh tham gia trong dự án và cộng đồng càng nhiều có thể càng tốt. Những đóng góp của những người sử dụng xúc tác cho đội dự án đảm bảo rằng họ đang làm thỏa mãn các nhu cầu của những người sử dụng đó.

Những đóng góp chung của những người sử dụng bao gồm (như không bị hạn chế):

• việc truyền bá về dự án (như, một đường liên kết trên một website và việc nâng cao nhận thức bằng truyền khẩu).
• thông tin cho các lập trình viên về những điểm mạnh và yếu từ quan điểm của người sử dụng.
• đưa ra sự hỗ trợ tinh thần (một câu 'cảm ơn' đi cùng)
• đưa ra sự hỗ trợ tài chính (phần mềm là nguồn mở, nhưng các lập trình viên cần phải ăn)

Những người sử dụng mà tiếp tục tham gia với dự án và cộng đồng của nó thường sẽ trở nên có liên quan ngày một nhiều hơn nữa. Những người sử dụng như vậy tự thấy họ đang trở thành những người đóng góp, như được mô tả trong phần sau.

Những người đóng góp

Những người đóng góp là các thành viên của cộng đồng mà đóng góp theo những cách thức cụ thể cho dự án. Bất kỳ ai cũng có thể trở thành một người đóng góp, và những đóng góp có thể nằm ở nhiều dạng, như được mô tả trong một tài liệu riêng rẽ (bản dịch tiếng Việt).

Không có mong đợi về cam kết cho dự án, không có những yêu cầu kỹ năng đặc biệt và không có qui trình lựa chọn.

Bổ sung thêm vào những hành động của họ như những người sử dụng, những người đóng góp cũng có thể thấy họ đang làm một hay nhiều hơn những điều sau đây:

• hỗ trợ cho những người sử dụng mới (những người sử dụng đang tồn tại thường là những người tốt nhất để hỗ trợ cho những người sử dụng mới)
• báo cáo các lỗi
• xác định các yêu cầu
• cung cấp các hình đồ họa và thiết kế web
• lập trình
• viết tài liệu
• sửa các lỗi
• bổ sung thêm các tính năng

Những người đóng góp tham gia với dự án thông qua trình theo dõi vấn đề và danh sách thư, hoặc bằng việc viết hoặc soạn thảo tài liệu. Họ đệ trình những thay đổi cho bản thân dự án thông qua các bản vá (bản dịch tiếng Việt), chúng sẽ được những người đệ trình (xem phần sau) cân nhắc để đưa vào trong dự án. Danh sách thư của các lập trình viên là nơi thích hợp nhất để yêu cầu sự trợ giúp khi tiến hành sự đóng góp đầu tiên đó.

Như những người đóng góp giành được kinh nghiệm và sự quen thuộc với dự án, hồ sở của họ trong, và cam kết tới, cộng đồng sẽ gia tăng. Ở giai đoạn nào đó, họ có thể thấy chính họ đang trở thành những ứng viên cho chế độ của người đề xuất.

Những người đề xuất

Những người đề xuất là các thành viên của cộng đồng mà đã chỉ ra được rằng họ tận tâm cho sự phát triển liên tục của dự án thông qua sự cam kết liên tục với cộng đồng. Chế độ của người đề xuất cho phép những người đóng góp dễ dàng hơn triển khai các hoạt động có liên quan tới dự án của họ bằng việc trao cho họ sự truy cập trực tiếp tới các tài nguyên của dự án. Đó là, họ có thể thực hiện những thay đổi trực tiếp tới các kết quả đầu ra của dự án, mà không phải đệ trình những thay đổi đó thông qua các bản vá.

Điều này không có nghĩa là một người đệ trình là tự do làm những gì họ muốn. Trên thực tế. những người đề xuất không có quyền nhiều hơn so với những người đóng góp đối với dự án. Trong khi chế độ của những người đề xuất chỉ định một thành viên được quý trọng của cộng đồng, người đã thể hiện sự tôn trọng lành mạnh đối với các mục tiêu và mục đích của dự án, thì công việc của họ vẫn tiếp tục sẽ được cộng đồng rà soát lại trước khi chấp nhận trong một phát hành chính thức. Sự khác biệt chính giữa một người đệ trình và một người đóng góp là khi sự phê chuẩn này được thấy từ cộng đồng. Một người đệ trình tìm kiếm sự phê chuẩn sau sự đóng góp được làm, hơn là trước đó.

Việc tìm kiếm sự phê chuẩn sau khi thực hiện một đóng góp được biết tới như là một qui trình đệ trình sau đó rà soát lại. Nó có hiệu lực hơn để cho phép những người được tin cậy thực hiện những đóng góp trực tiếp, khi mà đa số những đóng góp đó sẽ được dự án chấp nhận. Dự án sử dụng các cơ chế giao tiếp khác nhau (bản dịch tiếng Việt) để đảm bảo rằng tất cả những đóng góp được cộng đồng như một tổng thể rà soát lại. Với thời gian, một người đóng góp được mời để trở thành một người đệ trình, họ sẽ trở nên quen thuộc hơn với các công cụ khác nhau của dự án như một người sử dụng và sau đó như một người đóng góp.

Bất kỳ ai cũng có thể trở thành một người đệ trình; không có những yêu cầu đặc biệt, khác với phải chỉ ra được một thiện ý và khả năng để tham gia trong dự án như một tay chơi của đội. Điển hình, một người đề xuất tiềm tàng cần phải thể hiện rằng học có một sự hiểu biết về dự án, các mục đích và chiến lược của nó. Họ cũng sẽ đã đưa ra được những đóng góp có giá trị cho dự án qua một giai đoạn thời gian.

Những người đề xuất mới có thể được bất kỳ người đề xuất đang tồn tại nào đề cử. Một khi họ đã được đề cử, sẽ có một phiếu bầu của ban quản lý dự án – PMC (Project Management Committee) (xem bên dưới). Việc biểu quyết của những người đề xuất là một trong những hoạt động hiếm hoi diễn ra trong danh sách quản lý riêng tư của dự án. Điều này là để cho phép các thành viên của PMC tự do bày tỏ những ý kiến của họ về một ứng viên mà không gây ra sự bối rối lúng túng nào. Một khi cuộc biểu quyết được tổ chức, thì các kết quả biểu quyết được tổng hợp sẽ được xuất bản trong danh sách thư công khai. Ứng viên có quyền yêu cầu một sự giải thích đối với bất kỳ phủ quyết 'không' nào chống lại họ, bất kể kết quả của biểu quyết là thế nào. Sự giải thích này sẽ được Chủ tịch của PMC đưa ra (xem bên dưới) và sẽ là nặc danh và có tính xây dựng một cách tự nhiên.

Các ứng viên có thể từ chối sự chỉ định của họ như một người đề xuất. Tuy nhiên, điều này là không thường thấy, khi mà dự án không mong đợi bất kỳ thời điểm đặc thù hay cam kết về tài nguyên nào từ các thành viên cộng đồng của nó. Ý định đằng sau vai trò của người đệ trình là để cho phép mọi người đóng góp cho dự án dễ dàng hơn, không trói họ vào dự án theo bất kỳ cách chính thức nào.

Điều quan trọng để nhận thức rằng chế độ của người đề xuất là một sự ưu tiên, không phải một quyền. Sự ưu tiên đó phải giành được và một khi giành được thì nó có thể bị PMC loại bỏ được (xem phần dưới) trong những hoàn cảnh đặc biệt. Tuy nhiên, theo những hoàn cảnh thông thường thì chế độ của người đề xuất tồn tại lâu cho tới khi người đề xuất mong muốn tiếp tục tham gia với dự án.

Một người đề xuất mà thể hiện một mức đóng góp trên trung bình cho dự án, đặc biệt với sự tôn trọng đối với đường hướng chiến lược và sự lành mạnh dài hạn của nó, có thể được đề cử để trở thành một thành viên của PMC. Vai trò này được mô tả bên dưới.

Ban Quản lý Dự án

Ban quản lý dự án bao gồm những cá nhân được xác định như là 'những người chủ dự án' trên site phát triển. PMC có các trách nhiệm bổ sung đối với và trên cả những trách nhiệm của một người đề xuất. Các trách nhiệm đó đảm bảo sự điều hành trơn tru của dự án. Các thành viên PMC được kỳ vọng sẽ rà soát lại những đóng góp mã nguồn, tham gia trong việc lên kế hoạch chiến lược, phê chuẩn những thay đổi cho mô hình điều hành và quản lý các bản quyền trong các kết quả của dự án.

Các thành viên của PMC không có quyền đáng kể đối với các thành viên khác của cộng đồng, dù đây là PMC mà biểu quyết về những người đề xuất mới. Nó cũng ra các quyết định khi sự đồng thuận của cộng đồng không thể đạt được. Bổ sung thêm, PMC có sự truy cập tới danh sách thư riêng và của dự án và kho lưu trữ của nó. Danh sách này được sử dụng cho các vấn đề nhạy cảm, như các cuộc biểu quyết đối với những người đề xuất mới và các vấn đề pháp lý mà không thể được thảo luận công khai. Nó không bao giờ được sử dụng để quản lý hoặc lên kế hoạch dự án.

Membership of the PMC is by invitation from the existing PMC members. A nomination will result in discussion and then a vote by the existing PMC members. PMC membership votes are subject to consensus approval of the current PMC members.

Cơ chế thành viên của PMC là được mời từ các thành viên PMC đang tồn tại. Một ứng viên sẽ gây ra sự thảo luận và sau đó cuộc biểu quyết từ các thành viên PMC đang tồn tại. Các cuộc biểu quyết cơ chế thành viên của PMC tuân theo sự phê chuẩn đồng thuận của các thành viên PMC hiện hành.

Chủ tịch PMC

Chủ tịch PMC là một cá nhân duy nhất, được các thành viên PMC bầu. Một khi ai đó được chỉ định thành Chủ tịch, họ vẫn giữ trong vai trò đó cho tới khi họ chọn về hưu, hoặc PMC biểu quyết với đa số hơn 2/3 để loại bỏ họ.

Chủ tịch PMC không có quyền bổ sung nào đối với các thành viên khác của PMC: vai trò đó là vai trò của nhà điều phối và người tạo thuận lợi. Chủ tịch cũng được kỳ vọng đảm bảo rằng tất cả các qui trình điều hành sẽ được gắn kết mạch lạc, và có quyền biểu quyết khi dự án không đạt được sự đồng thuận.

Sự hỗ trợ

Tất cả các thành viên trong cộng đồng được khuyến khích cung cấp sự hỗ trợ cho những người sử dụng mới trong cơ sở hạ tầng quản lý dự án. Sự hỗ trợ này được cung cấp như một cách thức phát triển cộng đồng. Những người tìm cách hỗ trợ nên nhận thức được rằng tất cả hoạt động hỗ trợ trong dự án là tự nguyện và vì thế được cung cấp như và khi thời gian cho phép. Một người sử dụng có yêu cầu về số lấn hoặc các kết quả trả lời được đảm bảo vì thế nên tìm cách mua một hợp đồng hỗ trợ từ một thành viên cộng đồng. Tuy nhiên, đối với những người có thiện ý tham gia với dự án trong các điều khoản riêng của mình, và có thiện ý để giúp hỗ trợ cho những người sử dụng khác, thì các kênh hỗ trợ cộng đồng là lý tưởng.

Qui trình đóng góp

Bất kỳ ai cũng có thể đóng góp cho dự án, bất kể các kỹ năng của họ, khi mà có nhiều cách thức để đóng góp. Ví dụ, một người đóng góp có thể là tích cực trong danh sách thư của dự án và trình theo dõi vấn đề, hoặc có thể cung cấp các bản vá (bản dịch tiếng Việt). Các cách thức đóng góp khác nhau được mô tả chi tiết hơn trong một tài liệu riêng rẽ (bản dịch tiếng Việt).

Danh sách thư của các lập trình viên của dự án được thực hiện thông qua thảo luận với tất cả các thành viên của cộng đồng, từ người sử dụng mới nhất cho tới thành viên có kinh nghiệm nhất của PMC. Tất cả các thảo luận quản lý dự án không nhạy cảm diễn ra trong danh sách thư của những người đóng góp cho dự án. Thỉnh thoảng, thảo luận nhạy cảm diễn ra trong một danh sách thư riêng.

In order to ensure that the project is not bogged down by endless discussion and continual voting, the project operates a policy of lazy consensus. This allows the majority of decisions to be made without resorting to a formal vote.

Để đảm bảo rằng dự án không bị sa lầy vì những thảo luận bất tận và biểu quyết liên miên, dự án vận hành một chính sách đồng thuận lười. Điều này cho phép đa số các quyết định được thực hiện mà không dùng tới phương sách của một biểu quyết chính thống.

Đồng thuận lười

Việc ra quyết định thường có liên quan tới các bước sau:

• Đề xuất
• Thảo luận
• Biểu quyết (nếu sự đồng thuận đạt được thông qua thảo luận)
• Quyết định

Bất kỳ thành viên nào của cộng đồng cũng có thể thực hiện một đề xuất để cộng đồng cân nhắc. Để khởi xướng một thảo luận về một ý tưởng mới, họ sẽ gửi một thư điện tử tới danh sách của những người đóng góp cho dự án hoặc đệ trình một bản vá triển khai ý tưởng đó cho trình theo dõi vấn đề (hoặc hệ thống kiểm soát phiên bản nếu họ có sự truy cập đệ trình). Điều này sẽ nhắc về một rà soát lại và, nếu cần, một thảo luận về ý tưởng đó. Mục tiêu cảu rà soát lại và thảo luận này là để giành được sự phê chuẩn cho sự đóng góp. Vì hầu hết mọi người trong cộng đồng dự án có một tầm nhìn chia sẻ, sẽ thường có ít nhu cầu cho sự thảo luận để đạt tới sự đồng thuận. Thông thường, miễn là không ai hoàn toàn phản đối một đề xuất hoặc bản vá, thì nó được thừa nhận như là có sự ủng hộ của cộng đồng. Điều này gọi là sự đồng thuận lười - đó là, những người mà không nói lên ý kiến của họ một cách rõ ràng có sự đồng ý hoàn toàn đối với sự triển khai của đề xuất đó.

Đồng thuận lười là khái niệm rất quan trọng trong dự án. Chính qui trình này cho phép một nhóm lớn mọi người đạt được sự đồng thuận một cách có hiệu lực, khi ai đó không có sự phản đối một đề xuất thì không cần bỏ thời gian ra nói quan điểm của họ, và những người khác không cần bỏ thời gian ra để đọc các thư như vậy.

Sự đồng thuận lười sẽ có hiệu lực, nó là cần thiết để cho phép ít nhất 72 giờ đồng hồ trước khi giả thiết rằng không có sự chống đối nào cho đề xuất đó. Yêu cầu này đảm bảo rằng mỗi người có đủ thời gian để đọc, suy nghĩ và trả lời cho đề xuất. Giai đoạn thời gian được chọn sao cho sẽ là bao gồm tất cả những người tham gia, bất chấp những cam kết của họ về vị trí và thời gian.

Biểu quyết

Không phải tất cả các quyết định có thể được thực hiện bằng sự đồng thuận lười. Các vấn đề mà có ảnh hưởng tới đường hướng chiến lược hoặc quan điểm pháp lý của dự án phải giành được sự phê chuẩn rõ ràng ở dạng của một phiếu bầu. Mỗi thành viên của cộng đồng được khuyến khích thể hiện ý kiến của họ trong tất cả các thảo luận và tất cả các phiếu bầu. Tuy nhiên, chỉ những người đề xuất dự án và/hoặc các thành viên PMC (như được xác định ở trên) có những phiếu bầu ràng buộc vì những mục đích của việc ra quyết định. Một tài liệu riêng rẽ về việc biểu quyết trong mô hình điều hành người tài lãnh đạo mô tả chi tiết hơn cách biểu quyết được tiến hành trong các dự án tuân theo thực tiễn được thiết lập trong Quỹ Phần mềm Apache.

Kết luận

Một tài liệu điều hành rõ ràng và minh bạch là phần chính của bất kỳ dự án phát triển mở nào. Nó xác định các qui tắc tham gia trong cộng đồng và mô tả mức độ ảnh hưởng nào một thành viên cộng đồng có thể kỳ vọng để có đối với một dự án. Bổ sung thêm, nó cho phép các thành viên quyết định mức độ tham gia của họ với cộng đồng đó. Trong trường hợp của chế độ người tài lãnh đạo, nó cũng đưa ra một cách thức rõ ràng để đóng góp và một hệ thống tưởng thưởng trực quan cao.

Mô hình điều hành ví dụ này tới từ đầu dân chủ hơn của phổ kiểm soát được thấy trong các dự án phát triển mở. Ở một đầu khác, mô hình điều hành của nhà độc tài nhân từ (bản dịch tiếng Việt) mô tả một mô hình trong đó một cá nhân duy nhất nắm nhiệm vụ duy trì sự đồng thuận trong dự án, và nếu cần có tiếng nói cuối cùng trong qui trình ra quyết định.

Meritocratic governance is a commonly found model in which participants gain influence over a project through the recognition of their contributions. The Apache Software Foundation (ASF) is perhaps the most famous example of a large-scale meritocratic community. The foundation operates with an almost completely ‘flat’ structure, which means that anyone willing to contribute can engage with their projects at any level. At the other end of the ‘control’ spectrum is the benevolent dictator governance model, which is led by one individual.

The governance model under which a project is run is described in a governance document. In section 2 we provide a template for projects wishing to adopt the meritocratic model and create their own governance document. This template can be reused in its entirety or edited to suit individual needs. Like most of our materials, it is available under a Creative Commons licence (see footer for details) and can therefore be reused and modified, as long as attribution to OSS Watch is maintained. For information about the purpose of governance models, or for a discussion of the benefits of one model over another, please see our general document on governance models.

Introduction

Despite the apparent structural differences between meritocracies and benevolent dictatorships, both subscribe to the same open source principles of sharing the code and encouraging everyone to contribute back to the community. It is no surprise, therefore, that meritocratic project management committees and benevolent dictators both exercise their decision making power through loyalty rather than legalities. They all know that members are free to take the code and create alternative projects. In fact, this ability to fork is very important to the health of open source communities. This is because it ensures that those involved in project governance strive to make the right decisions for the community, rather than for a single individual or company.

However, there are notable differences between the two models, particularly with regard to how decision making within the community is carried out. At its most extreme, a meritocratic governance model appears to give away control to community members in response to their contributions to the project. But in reality, control is not handed out without due consideration. A meritocracy is not a democracy; that is, not everyone has a binding vote. Only those who have earned it through positive contribution to the project have a binding vote. This allows project leaders to ensure that only those that share a common vision and, just as importantly, are willing to work towards that shared vision, are given decision making authority.

The ‘flatness’ of a meritocratic project’s structure comes from the fact that once someone has decision making authority, they have exactly the same authority as everyone else. Another aspect of this flatness is that decision making responsibilities are usually reserved for those willing and able to understand, and appropriately represent, the views of the wider community. So, when an important decision is to be made, those with a vote are expected to represent the views of those who have yet to earn a vote.

Meritocratic projects, like all projects, usually start life with a small number of decision makers, possibly even a single person. Consequently, the early stages of project management are little different from those found in the benevolent dictator model. The key difference is that the initial team provides a mechanism for the distribution of control from the ‘dictator’ to a flat structure in recognition of contribution.

In the next section we provide a template for a meritocratic governance model, which projects can use as a basis for drawing up their own governance document. OSS Watch can help you fine-tune the model to suit your specific needs.

The template is based on the meritocratic model used in The Apache Software Foundation. It should be noted, however, that individual ASF projects are free to design their own bylaws. Therefore, this model is not likely to be identical to that employed in any given ASF project.

Template for a meritocratic governance document

Overview

This is a meritocratic, consensus-based community project. Anyone with an interest in the project can join the community, contribute to the project design and participate in the decision making process. This document describes how that participation takes place and how to set about earning merit within the project community.

Roles and responsibilities

Users

Users are community members who have a need for the project. They are the most important members of the community and without them the project would have no purpose. Anyone can be a user; there are no special requirements.

The project asks its users to participate in the project and community as much as possible. User contributions enable the project team to ensure that they are satisfying the needs of those users. Common user contributions include (but are not limited to):

• evangelising about the project (e.g. a link on a website and word-of-mouth awareness raising)
• informing developers of strengths and weaknesses from a new user perspective
• providing moral support (a ‘thank you’ goes a long way)
• providing financial support (the software is open source, but its developers need to eat)

Users who continue to engage with the project and its community will often become more and more involved. Such users may find themselves becoming contributors, as described in the next section.

Contributors

Contributors are community members who contribute in concrete ways to the project. Anyone can become a contributor, and contributions can take many forms, as detailed in a separate document. There is no expectation of commitment to the project, no specific skill requirements and no selection process.

In addition to their actions as users, contributors may also find themselves doing one or more of the following:

• supporting new users (existing users are often the best people to support new users)
• reporting bugs
• identifying requirements
• providing graphics and web design 4
• programming
• assisting with project infrastructure
• writing documentation
• fixing bugs
• adding features

Contributors engage with the project through the issue tracker and mailing list, or by writing or editing documentation. They submit changes to the project itself via patches, which will be considered for inclusion in the project by existing committers (see next section). The developer mailing list is the most appropriate place to ask for help when making that first contribution.

As contributors gain experience and familiarity with the project, their profile within, and commitment to, the community will increase. At some stage, they may find themselves being nominated for committership.

Committers

Committers are community members who have shown that they are committed to the continued development of the project through ongoing engagement with the community. Committership allows contributors to more easily carry on with their project related activities by giving them direct access to the project’s resources. That is, they can make changes directly to project outputs, without having to submit changes via patches.

This does not mean that a committer is free to do what they want. In fact, committers have no more authority over the project than contributors. While committership indicates a valued member of the community who has demonstrated a healthy respect for the project’s aims and objectives, their work continues to be reviewed by the community before acceptance in an official release. The key difference between a committer and a contributor is when this approval is sought from the community. A committer seeks approval after the contribution is made, rather than before.

Seeking approval after making a contribution is known as a commit-then-review process. It is more efficient to allow trusted people to make direct contributions, as the majority of those contributions will be accepted by the project. The project employs various communication mechanisms to ensure that all contributions are reviewed by the community as a whole. By the time a contributor is invited to become a committer, they will have become familiar with the project’s various tools as a user and then as a contributor.

Anyone can become a committer; there are no special requirements, other than to have shown a willingness and ability to participate in the project as a team player. Typically, a potential committer will need to show that they have an understanding of the project, its objectives and its strategy. They will also have provided valuable contributions to the project over a period of time.

New committers can be nominated by any existing committer. Once they have been nominated, there will be a vote by the project management committee (PMC; see below). Committer voting is one of the few activities that takes place on the project’s private management list. This is to allow PMC members to freely express their opinions about a nominee without causing embarrassment. Once the vote has been held, the aggregated voting results are published on the public mailing list. The nominee is entitled to request an explanation of any ‘no’ votes against them, regardless of the outcome of the vote. This explanation will be provided by the PMC Chair (see below) and will be anonymous and constructive in nature.

Nominees may decline their appointment as a committer. However, this is unusual, as the project does not expect any specific time or resource commitment from its community members. The intention behind the role of committer is to allow people to contribute to the project more easily, not to tie them in to the project in any formal way.

It is important to recognise that commitership is a privilege, not a right. That privilege must be earned and once earned it can be removed by the PMC (see next section) in extreme circumstances. However, under normal circumstances committership exists for as long as the committer wishes to continue engaging with the project.

A committer who shows an above-average level of contribution to the project, particularly with respect to its strategic direction and long-term health, may be nominated to become a member of the PMC. This role is described below.

Project management committee

The project management committee consists of those individuals identified as ‘project owners’ on the development site. The PMC has additional responsibilities over and above those of a committer. These responsibilities ensure the smooth running of the project. PMC members are expected to review code contributions, participate in strategic planning, approve changes to the governance model and manage the copyrights within the project outputs.

Members of the PMC do not have significant authority over other members of the community, although it is the PMC that votes on new committers. It also makes decisions when community consensus cannot be reached. In addition, the PMC has access to the project’s private mailing list and its archives. This list is used for sensitive issues, such as votes for new committers and legal matters that cannot be discussed in public. It is never used for project management or planning.

PMC Chair

The PMC Chair is a single individual, voted for by the PMC members. Once someone has been appointed Chair, they remain in that role until they choose to retire, or the PMC casts a two-thirds majority vote to remove them.

The PMC Chair has no additional authority over other members of the PMC: the role is one of coordinator and facilitator. The Chair is also expected to ensure that all governance processes are adhered to, and has the casting vote when the project fails to reach consensus.

Support

All participants in the community are encouraged to provide support for new users within the project management infrastructure. This support is provided as a way of growing the community. Those seeking support should recognise that all support activity within the project is voluntary and is therefore provided as and when time allows. A user requiring guaranteed response times or results should therefore seek to purchase a support contract from a community member. However, for those willing to engage with the project on its own terms, and willing to help support other users, the community support channels are ideal.

Contribution process

Anyone can contribute to the project, regardless of their skills, as there are many ways to contribute. For instance, a contributor might be active on the project mailing list and issue tracker, or might supply patches. The various ways of contributing are described in more detail in a separate document.

The developer mailing list is the most appropriate place for a contributor to ask for help when making their first contribution.

Decision making process

Decisions about the future of the project are made through discussion with all members of the community, from the newest user to the most experienced PMC member. All non-sensitive project management discussion takes place on the project contributors’ mailing list. Occasionally, sensitive discussion occurs on a private list.

Lazy consensus

Decision making typically involves the following steps:

• Proposal
• Discussion
• Vote (if consensus is not reached through discussion)
• Decision

Any community member can make a proposal for consideration by the community. In order to initiate a discussion about a new idea, they should send an email to the project contributors’ list or submit a patch implementing the idea to the issue tracker (or version-control system if they have commit access). This will prompt a review and, if necessary, a discussion of the idea. The goal of this review and discussion is to gain approval for the contribution. Since most people in the project community have a shared vision, there is often little need for discussion in order to reach consensus.

In general, as long as nobody explicitly opposes a proposal or patch, it is recognised as having the support of the community. This is called lazy consensus - that is, those who have not stated their opinion explicitly have implicitly agreed to the implementation of the proposal.

Lazy consensus is a very important concept within the project. It is this process that allows a large group of people to efficiently reach consensus, as someone with no objections to a proposal need not spend time stating their position, and others need not spend time reading such mails.

For lazy consensus to be effective, it is necessary to allow at least 72 hours before assuming that there are no objections to the proposal. This requirement ensures that everyone is given enough time to read, digest and respond to the proposal. This time period is chosen so as to be as inclusive as possible of all participants, regardless of their location and time commitments.

Voting

Not all decisions can be made using lazy consensus. Issues such as those affecting the strategic direction or legal standing of the project must gain explicit approval in the form of a vote. Every member of the community is encouraged to express their opinions in all discussion and all votes. However, only project committers and/or PMC members (as defined above) have binding votes for the purposes of decision making. A separate document on the voting within a meritocratic governance model describes in more detail how voting is conducted in projects following the practice established within the Apache Software Foundation.

Conclusion

A clear and transparent governance document is a key part of any open development project. It defines the rules of engagement within the community and describes what level of influence a community member can expect to have over a project. In addition, it enables members to decide their level of involvement with that community. In the case of a meritocracy, it also provides a clear way to contribute and a highly visible reward system.

This example governance model comes from the more democratic end of the spectrum of control found within open development projects. At the other end, the benevolent dictator governance model describes a model in which a single individual takes the task of maintaining consensus within the project, and if necessary has the final say in the decision making process.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com