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

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 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

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ừ. 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 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 quang

• 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ừ và Mô hình Điều hành Người tài lãnh đạo.

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ẽ.

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ừ và Chế độ Người tài Lãnh đạo 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ọ.

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

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