Các mô hình điều hành

Governance models

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

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

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

Lời người dịch: Để một dự án phát triển mở thành công, cần tới một mô hình điều hành được làm thành các tài liệu một cách rõ ràng ngay từ khi khởi xướng dự án để thu hút được các đóng góp từ bên ngoài phù hợp với các mục tiêu của dự án. Có nhiều mô hình, nổi bật nhất trong thế giới các dự án phần mềm tự do nguồn mở là mô hình điều hành của (1) Nhà độc tài Nhân từ và (2) Chế độ Người tài Lãnh đạo. Nếu bạn khởi xướng một dự án nguồn mở và cần một mô hình điều hành để dự án có khả năng thành công trong tương lai, thì bài viết này chính là dành cho bạn.

Một mô hình điều hành mô tả các vai trò mà những người tham gia dự án có thể đưa vào qui trình ra quyết định trong dự án. Bổ sung thêm, nó mô tả các qui tắc cơ bản cho sự tham gia trong dự án và các qui trình cho việc giao tiếp và chia sẻ bên trong đội và cộng đồng dự án. Nói cách khác thì đây là mô hình điều hành ngăn cho một dự án nguồn mở khỏi đi xuống thành hỗn loạn. Tài liệu này giải thích vì sao một mô hình điều hành là cần thiết, cân nhắc một số thách thức có liên quan tới việc áp dụng một mô hình điều hành trong các dự án nguồn mở, và xem xét những lĩnh vực chính như một mô hình cần phải giải quyết. Nó cũng mô tả cách để gói mô hình điều hành của bạn trong một tài liệu điều hành.

Vì sao một dự án cần tới một mô hình điều hành?

Có hầu như rất nhiều phương án trong các chiến lược quản lý nguồn mở giống như các dự án nguồn mở. Chính vì thế là sống còn cho một dự án để truyền đạt một cách rõ ràng các chính sách và chiến lược của nó tới những người sử dụng và các lập trình viên tiềm năng về đầu ra của dự án. Một mô hình điều hành rõ ràng cũng cho phép những người đóng góp tiềm năng hiểu được cách mà họ sẽ tham gia với dự án, những gì được mong đợi đối với họ và những sự bảo vệ nào được cung cấp để đảm bảo rằng những đóng góp của họ sẽ luôn là sẵn sàng đối với họ. Bổ sung thêm, nó mô tả các qui trình kiểm tra chất lượng mà giúp đảm bảo cho những người sử dụng tiềm năng về khả năng trụ vững được của dự án. Sự phát triển và giao tieps của một mô hình điều hành rõ ràng và súc tích là một trong những bước quan trọng nhất mà một dự án có thể nắm hướng tới tính bền vững (bản dịch tiếng Việt) thông qua sự phát triển mở.

Các mô hình điều hành trải từ sự kiểm soát tập trung của một cá nhân hoặc tổ chức (nhà độc tài nhân từ) cho tới sự kiểm soát phân tán được trao trong sự thừa nhận những đóng góp (chế độ người tài lãnh đạo). Bạn có thể thấy các mô hình điều hành ở bất kỳ thời điểm nào trong phổ này; cũng có khả năng đối với một mô hình điều hành được chọn của dự án để dịch chuyển dọc theo phổ này khi dự án chín muồi. Bên dưới là một vài ví dụ về các mô hình chung và các dạng dự án trong đó chúng có thể được thấy. (Bảng này có dẫn xuất từ công việc được trình bày trong Phần mềm Nguồn Mở: Có đáng để chuyển sang không?. Các khái niệm như 'nhà thờ lớn' và 'cái chợ' được giải thích trong bài viết trên Wikipedia về tiểu luận Nhà thờ lớn và Cái chợ).

Các mô hình điều hành chung

Dạng dự án	Mục tiêu	Dạng kiểm soát	Cấu trúc cộng đồng	Các ví dụ
Hướng khai thác	Chia sẻ sự đổi mới và tri thức	Kiểm soát tập trung như nhà thờ lớn	Lãnh đạo dự án, nhiều độc giả	Perl, Nhân - Kernel Linux
Hướng tiện ích	Làm thỏa mãn nhu cầu của một cá nhân	Kiểm soát phi tập trung như cái chợ	Nhiều lập trình viên bên ngoài, hỗ trợ ngang hàng cho những người sử dụng thụ động	GNU/Linux (bao gồm cả nhân - Kernel)
Hướng dịch vụ	Cung cấp dịch vụ ổn định	Kiểm soát tập trung như Hội đồng	Các thành viên cốt lõi, thay vì lãnh đạo dự án, nhiều người sử dụng phát triển các hệ thống cho những người sử dụng đầu cuối	Apache, PostgreSQL

Các mô hình điều hành đang sử dụng

Hãy xem xét các ví dụ về các mô hình điều hành. Đầu tiên, xem xét mô hình điều hành của Ubuntu. Mô hình này tập trung vào việc mô tả cấu trúc cộng đồng và các trách nhiệm có liên quan tới từng thành phần của cấu trúc đó. Nó cũng phác thảo các qui trình ra quyết định được thấy trong dự án. Dự án Ubuntu đã chọn cách tách thông tin của các lập trình viên khỏi thông tin cấu trúc được thấy trong tài liệu điều hành của nó, nhưng các qui trình quản lý kỹ thuật cũng được ghi thành tài liệu một cách rõ ràng.

Quỹ Phần mềm Apache có 2 tập các tài liệu điều hành cho từng dự án. Tập đầu có liên quan tới sự điều hành của quỹ, nó thiết lập cấu trúc của tổ chức như một tổng thể. Quỹ cũng đưa ra một tập các tài liệu về các qui trình chính được thấy trong các dự án của nó, như việc ra quyết định. Tuy nhiên, vì mỗi dự án là tự do, trong những ràng buộc nhất định, để xác định các biến thể của riêng nó về các qui trình đó, nhiều dự án có tài liệu điều hành riêng của nó. Xem mô tả điều hành Apache Forrest như là một ví dụ.

Ví dụ thứ 3 và là cuối cùng của chúng tôi về mô hình điều hành trong thực tế được thấy trong dự án Taverna. Đây là một ví dụ về một dự án nguồn mở đã lớn lên trong cộng đồng hàn lâm và vì thế thể hiện một mô hình được thấy để làm việc trong môi trường hàn lâm. Mô hình Taverna, giống như các mô hình của Ubuntu và ASF, tập trung vào cấu trúc và các qui trình quản lý của dự án.

Các rào cản cho việc áp dụng một mô hình điều hành

Bất chấp tầm quan trọng của việc xác định một mô hình điều hành ngay từ đầu, nhiều dự án không làm như thế. Có một số lý do có thể cho điều này. Trong đó chung nhất là:

• qui trình được thừa nhận như là 'quan liêu'
• có sự lo ngại rằng dự án sẽ mất ý nghĩa về đường lối
• cảm thấy rằng sự kiểm soát chiến lược của dự án sẽ bị mất
• dự án được nghĩ là quá non trẻ hoặc quá nhỏ để lôi cuốn được những người sử dụng hoặc các lập trình viên tích cực

Dù từng trong 3 mối lo đầu tiên là hợp lệ tiềm tàng, những sợ hãi đó dẽ dàng được xua tan bằng việc sử dụng một mô hình điều hành phù hợp. Tuy nhiên, lo ngại cuối cùng, về tuổi của dự án, không bao giờ là hợp lệ cả. Điều này là vì bất kỳ người đóng góp tiềm năng nào cho dự án cũng cần biết làm thế nào để đóng góp có hiệu quả và hiệu lực, và làm thế nào đóng góp của họ sẽ được quản lsy. Không có chỉ dẫn rõ ràng về những điều đó, hầu hết mọi người sẽ quay đi hơn là tham gia vào một dự án còn chưa chín. Nhưng nếu những người áp dụng sớm đó được chỉ ra rằng họ có thể giúp hướng dẫn dự án khi nó chín muồi, thì họ có thể quyết định ở lại. Một người đóng góp bên ngoài duy nhất có thể có được tốt một hiệu ứng chủ chốt về tính bền vững của một dự án, vì thế những người khởi xướng dự án có thể đơn giản không đủ khả năng để mạo hiểm đánh mất đi người đóng góp đó như là kết quả của việc cố gắng tiết kiệm một lượng nhỏ nỗ lực trong những giai đoạn đầu.

Là hữu dụng để giải quyết từng trong những lo ngại ở trên càng sớm càng tốt trong cuộc sống của dự án, sao cho chúng không trở thành những rào cản cho việc áp dụng một mô hình điều hành rõ ràng. Hãy khai thác chúng chi tiết hơn một chút.

Quan liêu

Một số người lĩnh hội được một mô hình điều hành sẽ không là gì ngoài sự quan liêu. Nhưng điều này không nhất thiết đúng rằng việc xác định một mô hình điều hành là một sự thực thi quan liêu không cần thiết: nó phụ thuộc vào cách mà mô hình đó được thiết kế thận trọng thế nào. Mục tiêu là để làm cho mô hình đó đơn giản nhưng hiệu quả. Nó không cần có một qui tắc cho việc điều khiển mỗi tình huống; quả thực, nó sẽ không định làm thế. Thay vào đó, mô hình đó sẽ cung cấp một cách thức nhẹ nhàng trong việc chỉ dẫn quản lý dự án theo một cách thức rõ ràng và minh bạch. Sự minh bạch này sẽ khuyến khích các bên thứ 3 tham gia dự án. Họ có thể thấy cách mà dự án được quản lý và dự báo trước cách mà nó sẽ phản ứng với những đóng góp của họ trước khi bỏ ra bất kỳ nỗ lực đáng kể nào vào công việc đó.

Điều quan trọng để lưu ý rằng một mô hình điều hành sẽ làm cho qui trình thực hiện và đánh giá những đóng góp của các bên thứ 3 dễ dàng hơn, chứ không khó khăn hơn. Nó sẽ loại bỏ sự không chắc chắn mà có thể dẫn tới mất thời gian cho mỗi người có liên quan.

Mất phương hướng

Lo sợ rằng một mô hình điều hành sẽ ràng buộc dự án như nó áp dụng cho một môi trường thay đổi có thể bị qui cho thực tế là có nhiều dự án nguồn mở được điều hành tồi mà chúng quả thực bị hạn chế trong tính linh hoạt của chúng. Tuy nhiên, vấn đề nảy sinh từ sự thiếu mô hình điều hành rõ ràng hơn là có dự phòng một mô hình. Một mô hình điều hành tốt thưc sự sẽ làm gia tăng sự lanh lẹ của dự án, khi mà nó xác định cách mà những người đóng góp mới có thể nắm lấy dự án theo những đường hướng không mong đợi mà không có việc can thiệp vào các mục tiêu cốt lõi của nó. Nó đưa ra một cơ chế cho phép cộng đồng như một tổng thể để xác định đường hướng họ cảm thấy dự án cần phải nắm lấy, trong khi vẫn đảm bảo rằng đội dự án cốt lõi không đánh mất sự kiểm soát. Vấn đề kiểm soát được thảo luận trong phần tiếp theo; ở đây chúng tôi sẽ tập trung vào tầm nhìn và đường hướng.

Vì không có khả năng đối với một dự án trở thành tất cả mọi thứ cho tất cả mọi người, mục tiêu của một dự án bền vững nên là để cung cấp một giải pháp càng hoàn chỉnh có thể càng tốt cho những người tham gia đóng góp cốt lõi của nó, trong khi vẫn có lợi ích cho những người tham gia đóng góp tiềm năng khác. Dự án cũng phải sẵn sàng để chấp nhận đầu vào từ khắp 4 phương không được mong đợi, và phải có khả năng, bất kỳ khi nào có thể, dàn xếp những nhu cầu của họ theo tầm nhìn và phương hướng trong tương lai của nó. Làm được thế sẽ gia tăng đáng kể kho các tài nguyên mà dự án có thể thiết kế ra theo yêu cầu của nó để trở nên bền vững. Tuy nhiên, việc cố gắng để bao gồm được tất cả sẽ gần như luôn tạo ra sự thất bại, khi nỗ lực trở nên dàn trải quá mỏng qua miền các vấn đề đó.

Giải pháp là để tùy biến một mô hình điều hành đưa ra được các cơ chế cho việc xác định và ép tuân thủ rõ ràng các biên giới của khả năng chấp nhận trong dự án. Mô hình đó nên được thiết kế để cho phép những người lãnh đạo dự án tránh được những trệch hướng không cần thiết và hoang phí bởi những yếu tố xấu tiềm năng trong cộng đồng. Mô hình cũng phải đảm bảo rằng những người với các chiến lược được sắp xếp có thể thực hiện công việc bổ sung theo một cách thức cộng tác và xây dựng. Dạng cộng tác này mở rộng phạm vi của dự án mà không có việc gia tăng đáng kể những đòi hỏi trong đội dự án gốc ban đầu.

Mất kiểm soát

Có lẽ nỗi sợ hãi lớn nhất cho tất cả là mô hình điều hành sẽ lát đường cho các bên thứ 3 để nắm sự kiểm soát của dự án. Sau tất cả, một mô hình điều hành khuyến khích sự tham gia của các bên thứ 3 bằng việc trang bị cho các bên đó trong dự án. Tuy nhiên, như với tất cả lo ngại được đề cập tới ở đây, một mô hình điều hành được thiết kế tốt đảm bảo rằng sự kiểm soát vẫn nằm chính xác ở những nơi mà sự lãnh đạo dự án muốn nó. Điều này có thể có nghĩa rằng tất cả việc ra quyết định được tổ chức kiểm soát (như MySQL và SugarCRM), hoặc nó có thể có nghĩa là tất cả các quyết định được cộng đồng như một tổng thể thực hiện (như Apache HTTPD Server và DoJo).

Khi quyết định về mức kiểm soát theo yêu cầu của đội dự án của bạn, hãy cân nhắc cách mà những nỗ lực của đội đó sẽ được duy trì liên tục. Nếu, ví dụ, dự án đang sản xuất một sản phẩm có lợi nhuận cao mà sẽ được khai thác một cách thương mại, thì sẽ có một số lợi ích trong việc duy trì sự kiểm soát trong khi vẫn khuyến khích sự cộng tác. Điều này là đúng rằng việc chọn một mô hình tập trung hóa sẽ đảm bảo rằng sự tiến bộ của sản phẩm được tối ưu hóa cho con đường khai thác đã chọn. Tuy nhiên, nó giới hạn cả bề rộng và chiều sâu của những người đóng góp có khả năng nắm lấy một lợi ích trong dự án, khi các mục tiêu chiến lược của họ có thể khác.

Mặt khác, nếu dự án đang sản xuất một phần của thành phần mà, theo bản thân nó, có giá trị thương mại thấp, thì mục tiêu thường là để đảm bảo rằng thành phần đó càng được sử dụng rộng rãi bao nhiều càng tốt. Trong hoàn cảnh đó, mục tiêu có thể là tối đa hóa sự tham gia bằng việc cho phép tất cả các đối tác có quan tâm và tích cực tham gia vào trong việc lên kế hoạch chiến lược.

Khi các cộng đồng chia tách (rẽ nhánh)

Một trong những điểm mạnh của mô hình cấp phép nguồn mở là bất kỳ ai cũng có quyền lấy mã nguồn và phát triển nó một cách độc lập đối với người nắm giữ bản quyền. Điều này được gọi là rẽ nhánh. Điều này có nghĩa là sự kiểm soát được lãnh đạo dự án sử dụng chỉ là mạnh chừng nào còn sự hỗ trợ mà cộng đồng trao cho sự lãnh đạo đó.

Bất chấp các nội dung của tài liệu điều hành, có khả năng cho những người về cơ bản không đồng ý vói việc kiểm soát các ảnh hưởng để bắt đầu một dự án mới. Đây không phải là vài trò của một mô hình điều hành để ngăn cản việc rẽ nhánh như vậy của dự án. Đúng hơn, nó sẽ xác định rõ ràng ảnh hưởng mà một người đóng góp tiềm năng có khả năng có đối với đường lối chiến lược của một dự án. Chỉ thông qua sự quản lý cẩn trọng của cộng đồng mà những người lãnh đạo dự án nguồn mở vẫn còn 'nắm quyền'. Việc thiết lập ra các qui tắc rõ ràng của cộng đồng theo cách này là một phần quan trọng của qui trình quản lý này.

Dự án quá trẻ hoặc quá nhỏ

Cuối cùng, chúng ta quay sang vấn đề của một dự án là quá trẻ để lôi cuốn những người sử dụng và những người đóng góp là các bên thứ 3 và vì thế không cần thiết để lo ngại cho bản thân với cách để quản lý chúng. Rất phổ biến đối với các dự án để cảm thấy rằng một mô hình điều hành còn chưa cần thiết, mà điều này, theo quan điểm của chúng tôi, là không bao giờ thế.

Không bao giờ là quá sớm để xác định một mô hình quản lý phù hợp. Không có một mô hình nào, thì những cơ họi của các bên thứ 3 có mong muốn đóng góp được xem là sẽ suy giảm. Điều này là vì một số lý do:

• những người đóng góp tiềm năng sẽ không biết làm thế nào để đóng góp

• họ sẽ không chắc chắn điều gì sẽ xảy ra cho sự đóng góp của họ
• dự án sẽ không thấy nghiêm túc về việc tham gia với các bên thứ 3
• không có sự đảm bảo trực quan rằng những đóng góp sẽ được quản lý theo một cách thức mà chúng sẽ giữ được giá trị cho người đóng góp gốc ban đầu

Vì bạn không bao giờ biết được khi nào một người đóng góp có thể sảy chân trong dự án của bạn, điều quan trọng sẽ là sẵn sàng từ những ngày sớm nhất có thể. Từng cơ hội bị bỏ lỡ để lôi cuốn những người đóng góp gây thiệt hại cho tính bền vững của dự án. Cũng hãy nhớ rằng đây là hợp đồng đầu tiên giữa một dự án và một người đóng góp mà nó là điều quan trọng nhất. Ví dụ, một sự sửa lỗi được một bên thứ 3 cung cấp có thể gây ra cho vài người có một kinh nghiệm tốt hơn của người sử dụng, nó có thể gây ra trong nhiều người sử dụng hơn. Điều này, tới lượt nó, có thể làm cho dự án cuốn hút hơn cho những người sử dụng và những người đóng góp.

Một sự hiểu sai phổ biến khác là không có đủ những người sử dụng hoặc những người đóng góp tiềm năng để làm cho nó đáng tranh thủ được họ. Một lần nữa, chúng tôi muốn đấu tranh rằng một sự đóng góp duy nhất mà cải thiện được chất lượng và khả năng sử dụng của sản phẩm là đáng có. Nỗ lực có liên quan trong việc tạo ra một mô hình điều hành phù hợp thường là ít hơn so với nỗ lực có liên quan tới tất cả nhưng là nhỏ nhất đối với những đóng góp.

Một lo ngại cuối cùng thường nảy sinh là dự án là quá nhỏ để vượt qua được một sự tràn vào của những người sử dụng và những người đóng góp của các bên thứ 3. Điều này minh họa sự thiếu hiểu biết về cách mà sự phát triển mở làm việc: trước hết, thậm chí lớn nhất đối với các dự án không lôi cuốn được nhiều hơn so với một nhúm các lập trình viên tích cực ở bất kỳ thời điểm nào. Thứ 2, một cộng đồng được quản lý tốt phần lớn sẽ là tự hỗ trợ. Điều này là đặc biệt đúng đối với các cộng đồng phân tán.

Các dự án phát triển mở ra các quyết định như thế nào?

Việc ra quyết định trong một dự án nguồn mở dường như, từ cái nhìn đầu tiên, sẽ là một vấn đề phức tạp và là trọng tâm cho nhiều nỗi sợ hãi được xem xét trong phần trước. Nhiều người biết, ví dụ, khó khăn thế nào có thể đối với một ủy ban để đạt được một quyết định. Việc làm thành tài liệu qui trình theo đó các quyết định sẽ được thực hiện vì thế là một phần chủ chốt của một mô hình điều hành, và đáng bỏ ra một chút thời gian để khai thác các tiếp cận khác nhau được nắm lấy để ngăn chặn những tình huống đình trệ hoàn toàn khỏi xảy ra trong các cộng đồng phát triển mở.

Việc ra quyết định trong các dự án phát triển mở có thể trải từ hoàn toàn tập trung cho tới hoàn toàn phân tán. Thông qua sự cần thiết và quen thuộc, gần như tất cả các dự án sẽ bắt đầu sống với một mô hình tập trung, với một số lượng nhỏ những người đóng góp ban đầu, có lẽ chỉ như 1. Kết quả là, tất cả các quyết định được đội nhỏ này thực hiện. Đối với một đội nhỏ, việt tập trung hóa ra quyết định là dễ dàng, và giống những gì được thấy trong các dự án đóng. Tuy nhiên, khi một dự án phát triển, ngày càng nhiều người hơn sẽ có thiện chí đóng góp cho các mục tiêu của dự án. Qui trình ra quyết định có thể cần phải tiến hóa một cách tương ứng.

Những nhà độc tài nhân từ

Những người sáng lập dự án mà duy trì sự kiểm soát thông qua toàn bộ cuộc đời của dự án đôi khi được gọi là các nhà độc tài nhân từ (bản dịch tiếng Việt). Một nhà độc tài nhân từ có trách nhiệm xác định đường lối chung của dự án và ra các quyết định cuối cùng khi cộng đồng là không đồng ý kiến. Khi mà ngày càng nhiều thành viên tham gia vào cộng đồng, nhà độc tài nhân từ đấu tranh để đảm bảo rằng những quyết định đó là vì lợi ích tốt nhất của dự án, hơn là những lợi ích của bất kỳ cá nhân hoặc tổ chức đặc biệt nào. Một nhà độc tài nhân từ tốt cần phải có khả năng cân bằng những yêu cầu xung đột nhau của các thành viên cộng đồng. Đây là nhiệm vụ không dễ dàng. Trước khi bạn tự mình thiết lập như một nhà độc tài nhân từ thì bạn nên hỏi: 'Tôi có thể là một nhà độc tài nhân từ tốt hay không?'

Trong khi đội dự án là nhỏ, và cộng đồng những người sử dụng là nhỏ, thì có khả năng đối với nhà độc tài nhân từ sẽ đưa ra tất cả các quyết định theo một cách thức từ trên xuống dưới theo truyền thống. Tuy nhiên, khi cộng đồng phát triển, điều này trở thành ngày càng khó khăn. Rất ít người sẽ có khả năng hiểu đầy đủ được tất cả các chi tiết của vấn đề đang được giải quyết. Hệ quả là, có thể cảm thấy sự không chắc chắn về việc ra các quyết định trong các lĩnh vực trong đó họ ít thành thạo hơn. Khi dự án phát triển về kích cỡ và phạm vi, những lĩnh vực không chắc chắn đó sẽ gia tăng, và vì thế nhà độc tài có thể cảm thấy không có khả năng ra một quyết định một cách thường xuyên như theo yêu cầu.

Vì lý do này, một nhà độc tài nhân từ có hiệu quả dần nắm lấy vai trò của trọng tài và người điều phối. Như một qui tắc, họ không theo bên nào trong bất kỳ tranh luận đặc biệt nào. 'Tôi thà có 15 người tranh luận về thứ gì đó còn hơn 15 người chia thành 2 phe, mỗi phe tin chắc nó đúng và không nói cho phe bên kia', Linus Torvalds nói. Ở đây Linus nhận thức được rằng bằng việc theo các bên ông sẽ gây ảnh hưởng cho những người còn lưỡng lự và vì thế lái sự phát triển đồng thuận theo một cách thức không mong đợi. Điều này là chấp nhận được nếu bản thân ông có một ý kiến khẳng định chắc chắn, nhưng trong những lĩnh vực nơi mà những người khác có đủ năng lực hơn để dẫn dắt qui trình đó, thì có thể gây ra những quyết định không đạt mức tối ưu.

Trong một dự án trung bình hoặc lớn, thường sẽ tốt hơn cho những người lãnh đạo để cho phép thảo luận để xử lý và chỉ chỉ ra sự ưu tiên trong trường hợp không chắc là không có sự đồng thuận có thể nhìn thấy nổi lên. Vì thế, nhà độc tài nhân từ cố gắn ngăn chặn tranh luận không có kết quả, nhưng khuyến khích tranh luận có đủ thông tin. Theo cách này, họ có thể được xem như là một chủ tọa hơn là một nhà độc tài.

Khi viết phần về ra quyết định của một tài liệu điều hành cho một dự án được kiểm soát tập trung, điều quan trọng để chỉ định rằng trong khi sức mạnh ra quyết định là tập trung, thì cộng đồng phân tán được kỳ vọng sẽ thông báo quyết định đó thông qua tranh luận. Không làm được điều này có thể làm cho một số cá nhân xa lánh, những người sợ rằng có ít cơ hội cho họ để mang sự tinh thông của họ tới dự án.

Những người tài lãnh đạo

Trong khi một số dự án duy trì sự kiểm soát chặt chẽ đối với qui trình ra quyết định, thì những dự án khác cảm thấy có hiệu quả hơn để cho phép cộng đồng như một tổng thể ra các quyết định. Trong trường hợp này, có một nhu cầu gia tăng cho một qui trình ra quyết định chính thức, vì không có người duy nhất nào có khả năng phá được sự bế tắc hoàn toàn.

Cấu trúc thành viên của những cộng đồng như vậy đặc thù thấy bằng phẳng hơn so với trong những cộng đồng được nhà độc tài nhân từ dẫn dắt. Tuy nhiên, những người đóng góp giành được sự tôn trọng của cộng đồng thông qua những đóng góp thường xuyên và hữu dụng có xu hướng có một 'tiếng nói to hơn'. Điều này có nghĩa là các nhân vật lãnh đạo sẽ vẫn nổi lên và các nhân vật đó phải, giống như các nhà độc tài nhân từ, vận dụng quyền được thừa nhận của họ một cách thận trọng. Mô hình chiếm được sự ủy quyền thông qua đóng góp thường được gọi là mô hình người tài lãnh đạo.,

Mô hình người tài lãnh đạo (bản dịch tiếng Việt) cố gắng đảm bảo rằng những người mới tới cộng đồng cảm thấy được tham gia và cam kết từ ngay ngày đầu tiên. Nó trao cho mỗi người tiếng nói và thưởng cho những ai thực hiện được những đóng góp có giá trị bằng việc cung cấp các cơ chế cho sự thừa nhận, như tính trực quan gia tăng trong dự án (điều này được thảo luận chi tiết hơn trong ví dụ của chúng tôi về mô hình người tài lãnh đạo). Như với mô hình nhà độc tài nhân từ, các quyết định được đưa ra bằng việc lắng nghe cộng đồng và cuối cùng thực hiện hành động dựa vào sự đồng thuận nổi lên. Tuy nhiên, trong nhiều trường hợp không có nhu cầu cho sự thảo luận, vì con đường đúng là rõ ràng. Trong trường hợp này, đủ để đơn giản nói ra những ý định của một người và cho phép thời gian cho ai đó phản đối. Trong trường hợp không có sự phản đối, được giả thiết rằng cộng đồng đồng ý với hành động được đề xuất. Điều này đôi khi được gọi là 'sự đồng thuận lười biếng'.

Hiệu ứng đồng thuận lười biếng có nghĩa là, trong thực tế, hầu hết các quyết định trong một chế độ người tài lãnh đạo được thực hiện theo một cách thức rất tương tự như với các dự án vận hành theo mô hình nhà độc tài nhân từ. Đó là, một khi ai đó đã giành được giá trị để cho phép họ xác định qui trình hành động, thì sử dụng sự đồng thuận lười biếng cho phép họ cứ thế tiến lên và thực hiện bất kỳ hành động nào mà họ muốn. Chỉ giống như một nhà độc tài nhân từ có thể làm. Trong trường hợp một sự không đồng ý không thể giải quyết được bằng thảo luận thì 2 mô hình là khác nhau. Trong hầu hết chế độ người tài lãnh đạo, một tiếng nói được gọi tới để phá vỡ những bế tắc đó; trong những cuộc biểu quyết như vậy, tất cả các thành viên của cộng đồng có một tiếng nói, nhưng chỉ những thành viên cộng đồng nào mà giành được đủ giá trị sẽ có quyền phủ quyết.

Làm thế nào để xây dựng một tài liệu điều hành

Một khi bạn đã thiết lập được mô hình nào bạn sẽ áp dụng, thì bạn cần xây dựng một tài liệu điều hành để chi tiết hóa qui trình theo đó các quyết định được thực hiện và những đóng góp được thừa nhận. Bên dưới chúng tôi trình bày một khung công việc chung cho việc tạo một tài liệu điều hành của dự án. Nó mô tả những lĩnh vực chính cần được đề cập tới, và giải thích vì sao từng phần là quan trọng. Ở cuối của tài liệu này, bạn sẽ thấy các đường liên kết tới các tài liệu điều hành ví dụ để minh họa cho một dải các lựa chọn có sẵn cho bạn khi thiết kế mô hình của riêng bạn. Cũng đáng lưu ý rằng OSS Watch là ở đây để hỗ trợ các dự án giáo dục trung học và cao hơn phát triển một mô hình điều hành.

Các phần chính của một tài liệu điều hành điển hình bao gồm:

• Tổng quan
• Các vai trò và trách nhiệm
• Sự hỗ trợ
• Qui trình ra quyết định
• Qui trình đóng góp

Chúng tôi sẽ thảo luận từng trong các phần đó ở bên dưới. Ví dụ, chúng có thể nhìn thế nào, hãy xem ví dụ Mô hình Điều hành của Nhà độc tài Nhân từ (bản dịch tiếng Việt) và Mô hình Điều hành Người tài lãnh đạo (bản dịch tiếng Việt).

Tổng quan

Phần tổng quan của tài liệu điều hành này sẽ cung cấp một tóm tắt ngắn gọn về các mục tiêu của dự án và cách mà nó được quản lý, liên kết hướng tới từng phần riêng rẽ một cách phù hợp. Nó cũng sẽ đưa ra các thông tin chính, như giấy phép bao trùm các kết quả của dự án, người nắm giữ bản quyền, và cách mà những người sử dụng có thể trở nên có liên quan tới sự phát triển của dự án.

Tổng quan sẽ là ngắn gọn, vì mục đích là để trao cho mọi người sự hiểu biết ngay lập tức về những gì được kỳ vọng đối với họ nếu họ mong muốn tham gia vào dự án.

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

Phần này mô tả các vai trò chính thức và sự ủy quyền của chúng trong dự án. Nó cũng sẽ mô tả mức cam kết theo yêu cầu và cách mà một người tìm cách tham gia trong từng vai trò. Mục tiêu của phần này là để làm rõ ai quản lý dự án, ai có thể đóng góp, làm thế nào họ có thể đóng góp và họ sẽ hành xử thế nào nếu họ muốn gây ảnh hưởng trực tiếp tới dự án.

Các vai trò được xác định có thể hoàn toàn chung, như 'người sử dụng', 'người đóng góp', 'người đề xuất' hoặc 'thành viên ban quản lý', 'người quản lý cộng đồng', 'người quản lý sản phẩm', và cứ như thế. Thông thường, càng nhiều chi tiết được cung cấp thì càng có khả năng mọi người sẽ có khả năng xác định được những điều họ có thể làm để đóng góp.

Tuy nhiên, hãy cẩn trọng không hạn chế dạng những đóng góp mà mọi người có thể làm. Ví dụ, ai đó với chức danh 'người quản lý phát hành' có thể cảm thấy rằng không phù hợp cho họ để trợ giúp với việc quản lý các lộ trình của dự án, mà dường như là một phần của vai trò của 'người quản lý sản phẩm'. Vì lý do này, nhiều dự án chọn có nhiều chức danh để mô tả một dải rộng lớn các hoạt động. Ví dụ, các nhiệm vụ của việc quản lý một phát hành và việc quản lý các lộ trình có thể nằm trong một vai trò duy nhất - có lẽ là 'người đề xuất' - và các cá nhân trong vai trò đó sẽ tự chọn các hoạt động mà họ muốn để đóng góp.

Ngược lại, việc không đưa ra các trách nhiệm nhất định cho mọi người có thể gây ra sự thiếu các đóng góp trong một lĩnh vực hoạt động được đưa ra. Điều này cần phải được cân bằng với thực tế là không phải lúc nào cũng có khả năng chỉ dẫn cho các thành viên của một cộng đồng triển khai các nhiệm vụ được xác định, khi họ có thể không được các lãnh đọa dự án sử dụng. Các vai trò được mô tả chi tiết trong một tài liệu riêng rẽ (bản dịch tiếng Việt).

Sự hỗ trợ

Phần này ghi tài liệu các quy trình hỗ trợ trong dự án. Đối với hầu hết các dự án nguồn mở, các kênh hỗ trợ là mối liên hệ chính với những người sử dụng của dự án. Những người sử dụng có thể trở thành những người đóng góp hoặc các khách hàng trong tương lai của các nhà cung cấp hỗ trợ thương mại, và vì thế là mấu chốt cho sự bền vững của một dự án. Một dự án nguồn mở phải chăm sóc những người sử dụng của mình.

Phần hỗ trợ của tài liệu điều hành cũng mô tả các kênh hỗ trợ sẵn sàng và cách mà mỗi kênh được sử dụng. Rủi ro của việc trải ra quá mỏng là nó sẽ ngăn chặn một số đông các hoạt động sống còn xảy ra tại một địa điểm duy nhất. Kết quả là, dạng cộng đồng tự hỗ trợ mà chúng ta tìm cách phát triển để giảm thiểu sự hỗ trợ tổng thể của dự án trở nên gượng gạo, thiếu tự nhiên.

Qui trình ra quyết định

Cách thức theo đó các quyết định được đưa ra là sống còn cho sự thành công của một dự án phát triển mở. Một qui trình là quá mất thời gian có thể gây ra cho các quyết định bị đình hoãn, vì thế làm chậm dự án; còn tệ hơn, qui trình đó có thể bị bỏ qua, vì thế tước đi quyền công dân đối với một phần của cộng đồng. Ngược lại, một qui trình mà không được xác định tốt có thể làm cho những lý lẽ về việc liệu một quyết định có là hợp lệ hay không, một lần nữa gây ra sự chậm trễ và chia rẽ trong cộng đồng.

Tính hiệu lực và minh bạch của qui trình ra quyết định sẽ là trọng tâm chính của phần này của tài liệu điều hành. Chính qui trình này đảm bảo cho những người đóng góp tiềm năng rằng những nỗ lực của họ sẽ được dự án điều hành một cách công bằng và sẽ giữ được giá trị trong tương lai. Các phương pháp để tạo ra cấu trúc kiểm soát cho đúng được phác thảo ở trên.

Qui trình đóng góp

Phần này làm các tài liệu về cách mà mọi người sẽ đóng góp cho dự án. Nó chi tiết hóa các dạng đóng góp khác nhau đang được thấy và các công cụ có sẵn cho việc thực hiện và quản lý các đóng góp đó. Phần này sẽ không đưa ra một mô tả đầy đủ về các công cụ, mà thay vào đó là một giải thích rõ ràng về qui trình mà các công cụ được cung cấp để hỗ trợ.

Các qui trình rõ ràng có liên quan tới sự đóng góp là cần thiết vì 2 lý do chính:

• để chỉ dẫn cho những người đóng góp cho dự án
• đẻ tái đảm bảo cho những người sử dụng tiềm năng rằng sự kiểm soát chất lượng và giám sát pháp lý của tất cả những đóng góp là đủ lành mạnh để sản xuất ra một đầu ra của phần mềm tin cậy và hợp pháp

Phần này của tài liệu điều hành vì thế sẽ mô tả những kỳ vọng mà dự án có với sự tôn trọng quản lý các bản quyền, các giêu chuẩn và tài liệu của việc lập trình. Nó cũng sẽ mô tả những gì sẽ xảy ra một khi sự đóng góp được thực hiện từ một bên thứ 3, bao gồm cả các chi tiết về qui trình được cho phép khi một sự đóng góp được cho rằng không phù hợp với dự án.

Kết luận

Việc áp dụng một mô hình điều hành và xây dựng một tài liệu điều hành dự án càng sớm có thể càng tốt là sống còn cho sự tạo ra một dự án phát triển mở thành công. Không gì sẽ ngăn cản được những người khởi xướng dự án khỏi việc ghi thành tài liệu mô hình của họ ở lúc khởi đầu dự án.

Tuy nhiên, không cần đối với phiên bản đầu tiên của mô hình điều hành dự án sẽ phải được chi tiết hóa đầy đủ; một khung công việc đưa ra quan điểm ban đầu là đủ. Tài liệu điều hành cũng không cần phải tính tới mọi kịch bản có thể trong tương lai. Ý tưởng là để bắt đầu với một mô hình đơn giản và có khả năng quản lý được mà sẽ gửi đi những tín hiệu rõ ràng cho những người đóng góp tiềm năng. Một dự án phát triển mở thành công cần phải chào đón những người có khả năng đóng góp theo một cách thức mà cải thiện được tính bền vững của dự án, trong khi vẫn ngăn chặn được những người với các nhu cầu không tương thích khỏi việc phung phí thời gian của riêng họ và thời gian của đội dự án trong sự tham gia không có hiệu quả với dự án.

Để có hiệu lực, một tài liệu điều hành cần phải ngắn gọn súc tích, có khả năng truy cập được và dễ dàng tham chiếu tới. Nó sẽ tập trung vào các khía cạnh chính của cấu trúc và cơ chế ra quyết định, nhưng cần phải là đủ mềm dẻo để giải quyết sự phức tạp ngày một gia tăng có liên quan tới sự tăng trưởng của cộng đồng và sự tương tác với thế giới bên ngoài của nó.

Các mô hình điều hành có thể trải từ kiểm soát hoàn toàn tập trung cho tới hoàn toàn phi tập trung. Mô hình khởi đầu lý tưởng là mô hình mà nhận thức được cấu trúc ban đầu của dự án và đưa ra được cách thức rõ ràng cho những đóng góp của các bên thứ 3 được thực hiện và được quản lý trong dự án. Các độc giả có thể tìm thấy các mẫu template về Nhà độc tài Nhân từ (bản dịch tiếng Việt) và Chế độ Người tài Lãnh đạo (bản dịch tiếng Việt) là hữu dụng trong việc hình thành một tài liệu ban đầu. OSS Watch cũng vinh hạnh để hỗ trợ cho các nhân sự tại các cơ quan HE và FE để tạo ra tài liệu điều hành phù hợp với các nhu cầu các dự án của họ.

A governance model describes the roles that project participants can take on and the process for decision making within the project. In addition, it describes the ground rules for participation in the project and the processes for communicating and sharing within the project team and community. In other words it is the governance model that prevents an open source project from descending into chaos. This document explains why a governance model is necessary, considers some of the challenges associated with adopting a governance model in open source projects, and looks at the key areas such a model needs to cover. It also describes how to encapsulate your governance model in a governance document.

Why does a project need a governance model?

There are almost as many variations of open source management strategies as there are open source projects. It is therefore critical that a project clearly communicates its policies and strategies to potential users and developers of the project’s outputs. A clear governance model also allows potential contributors to understand how they should engage with the project, what is expected of them and what protections are provided to ensure that their contributions will always be available to them. In addition, it describes the quality control processes that help to assure potential users of the viability of the project. The development and communication of a clear and concise governance model is one of the most important steps a project can take towards sustainability through open development.

Governance models range from centralised control by a single individual or organisation (benevolent dictatorship) to distributed control awarded in recognition of contributions (meritocracy). You can find governance models at any point along this spectrum; it is also possible for a project’s chosen governance model to move along this spectrum as the project matures. Below are some examples of common models and the types of projects in which they may be found. (This table is derived from work presented in Open Source Software: Is It Worth Converting?. Terms such as ‘cathedral’ and ‘bazaar’ are explained in the Wikipedia article on the Cathedral and the Bazaar)

Common governance models

Project type	Objective	Control style	Community structure	Examples
Exploration-oriented	Sharing innovation and knowledge	Cathedral-like central control	Project leader, many readers	Perl, Linux Kernel
Utility-oriented	Satisfying an individual need	Bazaar-like decentralised control	Many peripheral developers, peer support to passive users	GNU/Linux (excluding Kernel)
Service-oriented	Providing stable service	Council-like central control	Core members instead of project leader, many users that develop systems for end users	Apache, PostgreSQL

Governance models in use

Let’s look at some example governance models. First, consider the Ubuntu governance model. This model focuses on describing the structure of the community and the responsibilities associated with each component of that structure. It also outlines the decision-making processes found within the project. The Ubuntu project has opted to separate developer information from the structural information found in their governance document, but the technical management processes are also clearly documented.

The Apache Software Foundation has two sets of governance documents for each project. The first concerns the foundation’s governance, which sets out the structure of the organisation as a whole. The foundation also provides a set of documents on key processes found within its projects, such as decision making. However, since each project is free, within certain constraints, to define its own variations of these processes, many projects have their own governance documentation. See the Apache Forrest governance description for an example.

Our third and final example of a governance model in practice is found in the Taverna project. This is an example of an open source project that has grown within the academic community and so demonstrates a model that has been found to work in the academic environment. The Taverna model, like the Ubuntu and ASF models, focuses on project structure and management processes.

Barriers to adopting a governance model

In spite of the importance of defining a governance model at the outset, many projects fail to do so. There are a number of possible reasons for this. Among the most common are:

• the process is perceived as ‘red tape’
• there is a concern that the project will lose its sense of direction
• it is felt that control of the project’s strategy will be lost
• the project is thought to be too young or to small to attract active users or developers

Although each of the first three concerns is potentially valid, these fears are easily dispelled by using an appropriate governance model. However, the final concern, regarding the age of the project, is never valid. This is because any potential contributor to the project needs to know how to contribute efficiently and effectively, and how their contribution will be handled. Without clear guidance on these matters, most people will walk away rather than join an immature project. But if those early adopters are shown that they can help to guide the project as it matures, they may decide to stay. A single external contributor may well have a major effect on the sustainability of a project, so project initiators can simply not afford to risk losing that contributor as a result of trying to save a small amount of effort in the early stages.

It is helpful to address each of the above concerns as early as possible in the life of the project, so that they do not become a barrier to adopting a clear governance model. Let’s explore them in a little more detail.

Red tape

Some people perceive a governance model to be nothing but red tape. But it is not necessarily true that defining a governance model is an unnecessary bureaucratic exercise: it depends on how carefully the model is drawn up. The goal is to make the model simple but effective. It need not have a rule for handling every situation; indeed, it should not attempt to do so. Instead, the model should provide a lightweight way of guiding the management of the project in a clear and transparent way. This transparency will encourage third parties to join the project. They can see how the project is run and predict how it will react to their contributions before expending any significant effort on that work.

It is important to note that a governance model should make the process of making and evaluating third party contributions easier, not harder. It should remove the uncertainty that can lead to wasted time for everyone involved.

Loss of direction

The fear that a governance model will constrain the project as it adapts to a changing environment may be attributed to the fact that there are many poorly governed open source projects that are indeed limited in their agility. However, the problem is caused by the lack of a clear governance model rather than the provision of one. A good governance model will actually increase the agility of the project, as it defines how new contributors can take the project in unexpected directions without interfering with its core goals. It provides a mechanism for allowing the community as a whole to define the direction they feel the project should take, while ensuring that the core project team does not lose control. The issue of control is discussed in the next section; here we will focus on vision and direction.

Since it is not possible for a project to be all things to all people, the goal of a sustainable project should be to provide as complete a solution as it can for its core stakeholders, while still being of interest to other potential stakeholders. The project must also be ready to accept input from unexpected quarters, and must be able, wherever possible, to accommodate their needs in its future vision and direction. Doing so significantly increases the pool of resources the project can draw upon in its quest to become sustainable. However, trying to be all-encompassing will nearly always result in failure, as effort becomes spread too thinly over the problem domain.

The solution is to adopt a governance model that provides mechanisms for clearly defining and enforcing the boundaries of acceptability within the project. The model should be designed to allow project leaders to avoid unnecessary and wasteful diversions by potentially rogue elements within the community. The model must also ensure that those with aligned strategies can undertake complimentary work in a collaborative and constructive way. This kind of collaboration broadens the scope of the project without significantly increasing the demands on the originating project team.

Loss of control

Perhaps the biggest fear of all is that the governance model will pave the way for third parties to take control of the project. After all, a governance model encourages third-party participation by empowering those parties within the project. However, as with all the concerns addressed here, a well-designed governance model ensures that control remains precisely where the project leadership wants it. This may mean that all decision making is controlled by a central organisation (e.g. MySQL and SugarCRM), or it may mean that all decisions are made by the community as a whole (e.g. Apache HTTPD Server and DoJo ).

When deciding on the level of control required by your project team, consider how the efforts of the team are to be sustained. If, for example, the project is producing a high-profit product that will be exploited commercially, there is some benefit in maintaining control while encouraging collaboration. It is true that choosing a centralised model ensures that product evolution is optimised for the chosen exploitation route. However, it does limit the breadth and depth of contributors likely to take an interest in the project, as their strategic goals may differ.

On the other hand, if the project is producing a component part that, in itself, is of low commercial value, the aim is usually to ensure that the component is as widely used as possible. In those circumstances, the goal would be to maximise participation by allowing all interested and active partners to participate in strategic planning.

When communities split (forking)

One of the strengths of the open source licensing model is that anyone has the right to take the code and develop it independently of the copyright holder. This is called forking. This means that the control exerted by the project leadership is only as strong as the support the community gives that leadership.

Regardless of the contents of the governance document, it is possible for those who fundamentally disagree with the controlling influences to start a new project. It is not the role of a governance model to prevent such forking of the project. Rather, it should clearly define the influence a potential contributor is likely to have over a project’s strategic direction. It is only through careful management of the community that open source project leaders remain ‘in power’. Clearly setting out the rules of the community in this way is an important part of this management process.

The project is too young or too small

Finally, we return to the issue of a project being too young to attract third-party users and contributors and therefore not needing to concern itself with how to manage them. It is very common for projects to feel that a governance model is not yet necessary, but this, in our opinion, is never the case.

It is never too soon to define a suitable governance model. Without one, the chances of third parties wishing to contribute are considerably reduced. This is for a number of reasons:

• potential contributors will not know how to contribute
• they will not be sure what will happen to their contribution
• the project will not look serious about engaging with third parties
• there is no visible assurance that contributions will be managed in such a way that they will remain of value to the original contributor

Since you never know when a contributor might stumble upon your project, it is important to be ready from the earliest possible date. Each missed opportunity to attract contributors damages the sustainability of the project. Remember also that it is the first contact between a project and a contributor that is the most important. For example, a bug fix provided by a third party could result in several people having a better user experience, which could result in more users. This, in turn, would make the project more attractive to users and contributors.

Another common misconception is that there are not enough potential users or contributors to make it worth courting them. Again, we would contend that a single contribution that improves the quality and usability of the product is worth having. The effort involved in creating an adequate governance model is usually less than the effort involved in all but the smallest of contributions.

A final concern that is often raised is that the project is too small to cope with an influx of third-party users and contributors. This illustrates a lack of understanding of how open development works: firstly, even the largest of projects do not attract more than a handful of active developers at any one time. Secondly, a well-managed community will be largely self-supporting. This is particularly true for decentralised communities.

How do open development projects make decisions?

Decision making in an open development project appears, at first sight, to be a complex issue and is central to many of the fears examined in the previous section. Many people know, for example, how difficult it can be for a committee to reach a decision. Documenting the process by which decisions are made is therefore a key part of a governance model, and it is worth taking a little time to explore the various approaches commonly taken to prevent deadlock situations from occurring in open development communities.

Decision making in open development projects can range from fully centralised to fully decentralised. Through necessity and familiarity, nearly all projects will start life with a centralised model, with a small number of initial contributors, perhaps as few as one. As a result, all decisions are made by this small team. For a small team, centralising the decision making is easy, and is akin to what is found in closed projects. However, as a successful project grows, more and more people will be willing to contribute to the objectives of the project. The decision making process may need to evolve accordingly.

Benevolent dictatorships

Project founders who maintain control throughout the entire life of the project are sometimes called benevolent dictators. A benevolent dictator is responsible for determining the general direction of the project and making the final decisions when the community is in disagreement. As more and more members join the community, the benevolent dictator strives to ensure that these decisions are in the best interests of the project, rather than the interests of any particular individual or organisation. A good benevolent dictator needs to be able to balance the conflicting requirements of community members. This is no easy task. Before you set yourself up as a benevolent dictator you should ask: ‘Can I be a good benevolent dictator?’

While the project team is small, and the community of users is small, it is possible for the benevolent dictator to make all decisions in a traditional top-down manner. However, as the community grows, this becomes more and more difficult. Very few people will be able to fully understand all the details of the problem being addressed. Consequently, may feel uncertain about making decisions in areas in which they are less expert. As the project grows in size and scope, these areas of uncertainty will grow, and so the dictator may feel unable to make a decision as frequently as required.

For this reason, an effective benevolent dictator gradually takes on the role of arbitrator and coordinator. They do not, as a rule, take sides in any particular debate. ‘I’d much rather have 15 people arguing about something than 15 people splitting into two camps, each side convinced it’s right and not talking to the other,’ says Linus Torvalds. Here Linus recognises that by taking sides he will influence those who are undecided and thus steer the development of consensus in an unintended way. This is acceptable if he himself has a firm opinion, but in areas where others are more qualified to lead the process, it could result in sub-optimal decisions.

In a medium to large project, it is usually better for leaders to allow discussion to proceed and only indicate a preference in the unlikely event that there is no visible consensus emerging. Thus, the benevolent dictator tries to prevent fruitless debate, but encourages informative debate. In this way, they can be seen as a chairperson rather than a dictator.

When writing the decision making section of a governance document for a centrally controlled project, it is important to indicate that while the decision making power is centralised, the distributed community is expected to inform that decision through debate. Failure to do this may alienate some individuals, who fear that there is little opportunity for them to bring their expertise to the project.

Meritocracies

While some projects maintain tight control over the decision making process, others feel it is more effective to allow the community as a whole to make decisions. In this case, there is an increased need for a formal decision making process, since there is no single person able to break a deadlock.

The membership structure of such communities typically looks flatter than in those led by a benevolent dictator. However, contributors who have earned the respect of the community through frequent and useful contributions tend to have a ‘louder voice’. This means that leadership figures will still emerge and those figures must, like the benevolent dictators, wield their perceived authority with care. This model of earning authority through contribution is often called the meritocratic model.

The meritocratic model tries to ensure that new entrants to the community feel engaged and involved from the very first day. It gives everyone a voice and rewards those who make valuable contributions by providing mechanisms for recognition, such as increased visibility within the project (this is discussed in more detail in our example meritocratic model). As with the benevolent dictator model, decisions are made by listening to the community and eventually taking action based on the consensus that emerges. However, in many cases there is no need for discussion, since the correct path is obvious. In this case, it is sufficient to simply state one’s intentions and allow time for someone to object. In the absence of an objection, it is assumed that the community agrees with the proposed action. This is sometimes called ‘lazy consensus’.

The effect of lazy consensus means that, in practice, most decisions within a meritocracy are made in a way that is very similar to that of projects operating under a benevolent dictator model. That is, once someone has earned the merit to allow them to define a course of action, the use of lazy consensus allows them to just go ahead and take whatever action they want. Just as a benevolent dictator could do. In the case of a disagreement that cannot be resolved by discussion the two models differ. In most meritocracies, a vote is called in order to break these deadlocks; in such votes, all members of the community have a vote, but only those community members who have earned enough merit will have a veto.

How to draw up a governance document

Once you have established which model you will adopt, you need to draw up a governance document that details the process by which decisions are made and contributions are recognised. Below we present a general framework for creating a project governance document. It describes the main areas that need to be addressed, and explains why each section is important. At the end of this document, you will find links to example governance documents that illustrate the range of options available to you when designing your own model. It is also worth noting that OSS Watch is here to assist UK higher and further education projects developing a governance model.

The main sections of a typical governance document include:

• Overview
• Roles and responsibilities
• Support
• Decision making process
• Contribution process

We’ll discuss each of these sections below. For examples of how they might look, see our example Benevolent Dictator Governance Model and Meritocratic Governance Model.

Overview

This overview section of the governance document should provide a brief summary of the project objectives and how it is managed, linking forward to each individual section as appropriate. It should also provide key information, such as the licence covering the project outputs, who the copyright holder is, and how users can become involved with the development of the project.

The overview should be short, as the objective is to give people an immediate understanding of what is expected of them if they wish to engage with the project.

Roles and responsibilities

This section describes the formal roles and their authority within the project. It should also describe the level of commitment required and how one seeks to engage in each role. The goal of this section is to make it clear who manages the project, who can contribute, how they may contribute, and how they should behave if they wish to directly influence the project.

The defined roles may be quite general, such as ‘user’, ‘contributor’, ‘committer’ or ‘project management committee member’, or they may be very specific, such as ‘release manager’, ‘bug manager’, ‘community manager’, ‘product manager’, and so on. Generally, the more detail provided, the more likely it is that people will be able to identify things they can do to contribute. However, be careful not to limit the kind of contributions people can make. For example, someone with the title ‘release manager’ may feel that it is not appropriate for them to assist with managing project roadmaps, which appears to be part of the ‘product manager’ role. For this reason, many projects opt for broad titles that describe a wide range of activities. For example, the tasks of managing a release and managing roadmaps might fall within a single role - perhaps ‘committer’ - and individuals within that role will self-select the activities they wish to contribute to.

Conversely, failing to give specific responsibilities to people can result in a lack of contributions in a given area of activity. This needs to be balanced against the fact that it is not always possible to instruct members of a community to carry out defined tasks, as they may not be in the employ of the project leaders. Roles are described in more detail in a separate document.

Support

This section documents support processes within the project. For most open source projects, the support channels are the main contact with users of the project. These users may become future contributors or customers of commercial support providers, and are therefore key to the sustainability of a project. An open source project must look after its users.

The support section of the governance document also describes the available support channels and how each is used. It also provides a means for preventing support from being spread too thinly across multiple channels. The risk of spreading too thinly is that it prevents a critical mass of activity occurring in a single location. As a result, the kind of self-supporting community we seek to develop in order to reduce the support overhead of the project is inhibited.

Decision making process

The way in which decisions are made is critical to the success of an open development project. A process that is too time consuming may result in decisions being deferred, thus delaying the project; worse still, the process may be ignored, thus disenfranchising part of the community. Conversely, a process that is not well defined may result in arguments about whether a decision is valid or not, again resulting in delays and splits within the community.

The efficiency and transparency of the decision making process should be the main focus of this section of the governance document. It is this process that assures potential contributors that their efforts will be handled fairly by the project and will remain of value in the future. Methods for creating the right control structure are outlined above.

Contribution process

This section documents how people should contribute to the project. It details the various types of contribution being sought and the tools available for making and managing those contributions. This section should not provide a full description of the tools, but rather a clear explanation of the process the tools are provided to support.

Clear processes relating to contribution are necessary for two key reasons:

• to guide contributors to the project
• to reassure potential users that the quality control and legal oversight of all contributions is sufficiently robust to produce a reliable and legally sound software output

This section of the governance document should therefore describe the expectations the project has with respect to copyrights management, coding standards and documentation. It should also describe what happens once a contribution has been made by a third party, including details of the process that is followed when a contribution is deemed unsuitable for the project.

Conclusion

Adopting a governance model and drawing up a project governance document as early as possible are critical for the creation of a successful open development project. Nothing should prevent the project initiators from documenting their model at project inception.

However, there is no need for the first version of the project’s governance model to be fully detailed; a framework setting out the starting position is sufficient. Nor does the governance document need to account for every possible future scenario. The idea is to start with a simple and manageable model that will send clear signals to potential contributors. A successful open development project needs to be welcoming to those who are likely to contribute in a way that improves project sustainability, while preventing those with incompatible needs from wasting their own time and that of the project team in fruitless engagements with the project.

In order to be effective, a governance document needs to be concise, accessible and easy to refer to. It should focus on the main aspects of the decision making structure and mechanism, but needs to be flexible enough to address the increasing complexity associated with the growth of its community and interaction with the external world.

Governance models can range from fully centralised control to fully decentralised. The ideal starting model is one that recognises the initial structure of the project and provides a clear way for third-party contributions to be made and managed within the project. Readers may find our Benevolent dictator and Meritocratic templates helpful in formulating an initial document. OSS Watch is also happy to assist staff in UK HE and FE institutions to create a governance document to suit their projects needs.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com