Mô hình điều hành của nhà độc tài nhân từ

Benevolent dictator governance model

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

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

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

Lời người dịch: Trong thế giới nguồn mở tồn tại 2 mô hình chính điều hành dự án: (1) mô hình nhà độc tài nhân từ và (2) mô hình của những người tài lãnh đạo. Bài viết này nêu chi tiết các vấn đề liên quan tới mô hình quản lý dự án nguồn mở của nhà độc tài nhân từ. “Cấu trúc điều hành của nhà độc tài nhân từ không phải là cấu trúc dễ dàng để quản lý và đòi hỏi một người rất đặc biệt trong vai trò của người lãnh đạo dự án. Tuy nhiên, nó có thể làm việc được cực kỳ tốt vì nó là đơn giản. Mẫu template được cung cấp trong tài liệu này xác định một mô hình có khả năng quản lý được một cách hợp lý, xác định các vai trò, hoạt động và qui trình ra quyết định chính được thực hiện trong một dự án nguồn mở. Khi tạo tài liệu điều hành của một nhà độc tài nhân từ, các dự án cần phải đảm bảo rằng nó đưa ra thông tin cần thiết về các vai trò của người lãnh đạo dự án và những người đóng góp khác, chỉ ra rõ ràng cách mà những người mới tới có thể đóng góp và cách mà những đóng góp đó sẽ được thừa nhận”.

Một dự án của nhà độc tài nhân từ được một lãnh đạo duy nhất chỉ đạo. Có lẽ ví dụ thường được trích dẫn nhất của mô hình nhà độc tài nhân từ là dự án Nhân Linux, nó được quản lý dưới sự lãnh đạo ra quyết định trực tiếp của Linus Torvalds. Là một nhà độc tài nhân từ không phải là một công việc dễ dàng. Nó đòi hỏi thuật ngoại giao và các kỹ năng xây dựng cộng đồng, tri thức sâu về kỹ thuật của tất cả các lĩnh vực của dự án, và các mức độ cam kết và chuyên tâm khác thường. Tuy nhiên, như dự án Nhân Linux minh họa, nó có thể là rất hiệu quả. Mặt khác của phổ 'kiểm soát' là mô hình điều hành của những người tài, trong đó những người tham gia có được ảnh hưởng đối với một dự án trong sự thừa nhận đối với những người đóng góp của họ.

Cái cách mà ở đó một dự án được tổ chức được mô tả trong một tài liệu về đ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 nhà độc tài nhân từ 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 riêng rẽ. Giống như hầu hết các tư liệu, nó là sẵn sàng theo một giấy phép Creative Commons (xem chi tiết ở cuối bài), và vì thế có thể được sử dụng lại và được sửa đổi, miễn là ghi công cho OSS Watch được hiển thị. Đối với 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 về những lợi ích của mô hình này so với mô hình khác, hãy xem tài liệu giới thiệu của chúng tôi trong các mô hình điều hành.

Giới thiệu

Bất chấp những khác biệt rõ ràng về cấu trúc, các mô hình người tài lãnh đạo và nhà độc tài nhân từ góp vào những nguyên tắc y hệt nhau của nguồn mở về chia sẻ mã nguồn và khuyến khích bất kỳ ai đóng góp trở ngược lại cho cộng đồng. Vì thế không ngạc nhiên rằng cả các nhà độc tài nhân từ và các ủy ban quản lý của các dự án người tài lãnh đạo thực thi sức mạnh ra quyết định của họ thông qua lòng trung thành là sự hợp pháp. 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 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ở, khi mà nó đảm bảo rằng những người đã tham gia vào điều hành dự án đấu tranh để đưa ra các quyết định đúng cho cộng đồng, thay vì cho cá nhân hay công ty duy nhất. Tuy nhiên, có những khác biệt đáng chú ý giữa 2 mô hình đó, đặc biệt về cách mà việc ra quyết định trong cộng đồng được triển khai.

Mẫu template cho tài liệu điều hành của nhà độc tài nhân từ

Tổng quan

Dự án này được một nhà độc tài nhân từ dẫn dắt và được cộng đồng quản lý. Đó là, cộng đồng tích cực đóng góp cho sự duy trì hàng ngày của dự án, nhưng đường lối chiến lược chung được nhà độc tài nhân từ thiết kế ra. Trong trường hợp không đồng ý, họ có tiếng nói cuối cùng. Chính công việc của nhà độc tài nhân từ sẽ giải quyết các tranh chấp trong cộng đồng và đảm bảo rằng dự án có khả năng tiến bộ theo một cách thức được điều phối. Đổi lại, chính công việc của cộng đồng sẽ chỉ dẫn cho các quyết định của nhà độc tài nhân từ thông qua sự tham gia và đóng góp tích cực.

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

Nhà độc tài nhân từ (lãnh đạo dự án)

Điển hình, nhà độc tài nhân từ, hoặc lãnh đạo dự án, là tự chỉ định. Tuy nhiên, vì cộng đồng luôn có khả năng để rẽ nhánh, con người này chịu trách nhiệm đầy đủ đối với cộng đồng. Vai trò của lãnh đạo dự án là vai trò khó khăn: họ thiết lập các mục tiêu chiến lược của dự án và truyền đạt chúng một cách rõ ràng cho cộng đồng. Họ cũng phải hiểu cộng đồng như một tổng thể và đấu tranh để làm thỏa mãn càng nhiều nhu cầu xung đột càng tốt, trong khi đảm bảo được rằng dự án sống sót về lâu dài.

Theo nhiều cách thức, vai trò của nhà độc tài nhân từ là ít hơn về sự độc tài và nhiều hơn về thuật ngoại giao. Mấu chốt là để đảm bảo rằng, khi dự án mở rộng, những con người đúng sẽ đưa ra được ảnh hưởng đối với dự án và cộng đồng tập hợp lại đằng sau tầm nhìn của lãnh đạo dự án. Công việc của người lãnh đạo sau đó là đảm bảo rằng những người đề xuất (xem bên dưới) đưa ra các quyết định đúng nhân danh dự án. Nói chung, miễn là những người đề xuất được sắp xếp với chiến lược của dự án, thì người lãnh đạo dự án sẽ cho phép họ xử lý như họ mong muốn.

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

Những người đề xuất là những người đóng góp mà họ đã thực hiện vài đóng góp có giá trị cho dự án và bây giờ được tín nhiệm để viết mã nguồn trực tiếp cho kho và giám sát những đóng góp của những người khác. Trong nhiều trường hợp họ là các lập trình viên nhưng cũng có thể là họ đóng góp theo một vai trò khác. Thông thường, một người đề xuất sẽ tập trung vào một khía cạnh đặc thù của dự án, và sẽ mang theo một mức tinh thông và hiểu biết làm cho họ có được sự tôn trọng trong cộng đồng và của người lãnh đạo dự án. Vai trò của người đề xuất không phải là vai trò chính thức, chỉ đơn giản là một vị trí mà các thành viên có ảnh hưởng của cộng đồng sẽ tự thấy khi người lãnh đạo dự án nhìn vào họ vì sự chỉ dẫn và hỗ trợ.

Những người đề xuất không có sự ủy quyền đối với toàn bộ đường hướng của dự án. Tuy nhiên, họ là tai mắt của lãnh đạo dự án. Chính công việc của những người đề xuất sẽ đảm bảo rằng người lãnh đạo nhận thức được về các nhu cầu và các mục tiêu tập thể của cộng đồng, và để giúp phát triển hoặc khơi gợi ra những đóng góp phù hợp cho dự án. Thường thì, những người đề xuất được trao sự kiểm soát không chính thức đối với các lĩnh vực trách nhiệm đặc thù của họ, và được giao các quyền để trực tiếp sửa đổi những lĩnh vực nhất định của mã nguồn. Đó là, dù những người đề xuất không có sự ủy quyền ra quyết định rõ ràng, thì họ sẽ thường thấy rằng những hành động của họ là đồng nghĩa với các quyết định được người lãnh đạo đưa ra.

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

Những người đóng góp là các thành viên cộng đồng mà hoặc không có mong muốn trở thành những người đề xuất, hoặc chưa được nhà độc tài nhân từ trao cơ hội. Họ thực hiện những đóng góp có giá trị, như những người được phác họa trong danh sách bên dưới, nhưng thường không có quyền để thực hiện những thay đổi trực tiếp tới mã nguồn của dự án. Những người đóng góp tham gia với dự án thông qua các công cụ giao tiếp, như các danh sách thư điện tử, và thông qua các báo cáo và các bản vá gắn với các vấn đề trong trình theo dõi vấn đề, như được chi tiết hóa trong tài liệu các công cụ cộng đồng của chúng tôi.

Bất kỳ ai cũng có thể trở thành một người đóng góp. Không có kỳ vọng cam kết với dự án, không có các yêu cầu kỹ năng đặc biệt và không có qui trình lựa chọn nào. Để trở thành một người đóng góp, một thành viên cộng đồng đơn giản phải thực hiện một hoặc nhiều hành động có lợi cho dự án.

Một số người đóng góp sẽ sẵn sàng tham gia với dự án như những người sử dụng, nhưng cũng sẽ tự thấy họ làm được một hoặc nhiều việc trong những việc sau:

• hỗ trợ cho những người sử dụng mới (những người sử dụng hiện hành thường cung cấp sự hỗ trợ có hiệu quả nhất 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ọa và thiết kế website

• lập trình

• hỗ trợ hạ tầng của dự án

• viết tài liệu

• sửa các lỗi

• bổ sung các tính năng

Khi những người đóng góp có được kinh nghiệm và quen với dự án, họ có thể thấy rằng lãnh đạo dự án bắt đầu dựa vào họ ngày càng nhiều hơn. Khi điều này bắt đầu xảy ra, họ dần dần áp dụng vai trò của người đề xuất, như được mô tả ở trên.

Những người sử dụng

Những người sử dụng là những thành viên cộng đồng có 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: không có họ, 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.

Những người sử dụng sẽ được khuyến khích tham gia trong cuộc sống của dự án và cộng đồng càng nhiều có thể càng tốt. Những đóng góp của người sử dụng cho phép đội dự án đảm bảo rằng họ đang làm thỏa mãn cho các nhu cầu của những người sử dụng đó. Các hoạt động chung của những người sử dụng bao gồm (nhưng không bị giới hạn):

• truyền bá về dự án

• thông tn cho những người lập trình của dự án về những điểm mạnh và yếu từ quan điểm của một người sử dụng mới

• đưa ra sự hỗ trợ tinh thần (một 'cảm ơn bạn' đi cùng)

• cung cấp sự hỗ trợ về tài chính

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

Sự hỗ trợ

Tất cả những người tham gia 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 hạ tầng quản lý của dự án. Hỗ trợ này được cung cấp như một cách thức tăng trưởng cộng đồng. Những người tìm kiếm sự hỗ trợ sẽ nhận thức được rằng tất cả hoạt động hỗ trợ bên trong dự án là tự nguyện và vì thế được cung cấp khi thời gian cho phép. Một người sử dụng yêu cầu đảm bảo thời gian hoặc các kết quả trả lời vì thế nên tìm cách mua một hợp đồng hỗ trợ từ một nhà cung cấp. (Tất nhiên, nhà cung cấp đó sẽ là một thành viên tích cực của cộng đồng). Tuy nhiên, đối với những người có thiện chí tham gia với dự án trong những điều khoản của riêng mình, và có thiện chí để giúp hỗ trợ 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 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á. Các cách thức đóng góp khác nhau được mổ tả chi tiết hơn trong tài liệu về các vai trò trong nguồn mở.

Danh sách thư của các lập trình viên là nơi phù hợp nhất cho một người đóng góp để yêu cầu giúp đỡ khi tiến hành sự đóng góp đầu tiên của họ.

Qui trình ra quyết định

Mô hình nhà độc tài nhân từ không cần một qui trình giải quyết xung đột chính thức, vì lời nói của người lãnh đạo dự án là cuối cùng. Nếu cộng đồng chọn để thẩm tra về sự khôn ngoan của những hành động của một người đề xuất, thì lãnh đạo dự án có thể rà soát lại những quyết định của họ bằng việc kiểm tra các lưu trữ thư điện tử, và hoặc lật ngược hoặc ủng hộ chúng.

Kết luận

Cấu trúc điều hành của nhà độc tài nhân từ không phải là cấu trúc dễ dàng để quản lý và đòi hỏi một người rất đặc biệt trong vai trò của người lãnh đạo dự án. Tuy nhiên, nó có thể làm việc được cực kỳ tốt vì nó là đơn giản. Mẫu template được cung cấp trong tài liệu này xác định một mô hình có khả năng quản lý được một cách hợp lý, xác định các vai trò, hoạt động và qui trình ra quyết định chính được thực hiện trong một dự án nguồn mở.

Khi tạo tài liệu điều hành của một nhà độc tài nhân từ, các dự án cần phải đảm bảo rằng nó đưa ra thông tin cần thiết về các vai trò của người lãnh đạo dự án và những người đóng góp khác, chỉ ra rõ ràng cách mà những người mới tới có thể đóng góp và cách mà những đóng góp đó sẽ được thừa nhận.

A benevolent dictator project is steered by a unique leader. Perhaps the most commonly cited example of the benevolent dictator model is the Linux Kernel project, which is run under the direct decision-making leadership of Linus Torvalds. Being a benevolent dictator is not an easy job. It requires diplomacy and community building skills, in-depth technical knowledge of all aspects of the project, and exceptional levels of commitment and dedication. However, as the Linux Kernel project illustrates, it can be very effective. At the other end of the ‘control’ spectrum is the meritocratic governance model, in which participants gain influence over a project in recognition of their contributions.

The way in which a project is organized is described in a governance document. In section 2 we provide a template for projects wishing to adopt the benevolent dictator model and cre-ate their own governance document. This template can be reused in its entirety or modified 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 displayed. For information about the purpose of governance models, or for a discussion of the benefits of one model over another, please see our introductory document on governance models.

Introduction

Despite the apparent structural differences, the meritocratic and benevolent dictator models subscribe to the same open source principles of sharing the code and encouraging everyone to contribute back to the community. It is therefore no surprise that both benevolent dictators and management committees of meritocratic projects exercise their decision-making power through loyalty rather than legality. They all know that members are free to take the code and cre-ate al-ternative projects. In fact, this ability to fork is very important to the health of open source communities, as 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.

Template for a benevolent dictator governance document

Overview

This project is led by a benevolent dictator and managed by the community. That is, the community actively contributes to the day-to-day maintenance of the project, but the general strategic line is drawn by the benevolent dictator. In case of disagreement, they have the last word. It is the benevolent dictator’s job to resolve disputes within the community and to ensure that the project is able to progress in a coordinated way. In turn, it is the community’s job to guide the decisions of the benevolent dictator through active engagement and contribution.

Roles and responsibilities

Benevolent dictator (project lead)

Typically, the benevolent dictator, or project lead, is self-appointed. However, because the community always has the ability to fork, this person is fully answerable to the community. The project lead’s role is a difficult one: they set the strategic objectives of the project and communicate these clearly to the community. They also have to understand the community as a whole and strive to satisfy as many conflicting needs as possible, while ensuring that the project survives in the long term.

In many ways, the role of the benevolent dictator is less about dictatorship and more about diplomacy. The key is to ensure that, as the project expands, the right people are given influence over it and the community rallies behind the vision of the project lead. The lead’s job is then to ensure that the committers (see below) make the right decisions on behalf of the project. Generally speaking, as long as the committers are aligned with the project’s strategy, the project lead will allow them to proceed as they desire.

Committers

Committers are contributors who have made several valuable contributions to the project and are now relied upon to both write code directly to the repository and screen the contributions of others. In many cases they are programmers but it is also possible that they contribute in a different role. Typically, a committer will focus on a specific aspect of the project, and will bring a level of expertise and understanding that earns them the respect of the community and the project lead. The role of committer is not an official one, it is simply a position that influential members of the community will find themselves in as the project lead looks to them for guidance and support.

Committers have no authority over the overall direction of the project. However, they do have the ear of the project lead. It is a committer’s job to ensure that the lead is aware of the community’s needs and collective objectives, and to help develop or elicit appropriate contributions to the project. Often, committers are given informal control over their specific areas of responsibility, and are assigned rights to directly modify certain areas of the source code. That is, although committers do not have explicit decision-making authority, they will often find that their actions are synonymous with the decisions made by the lead.

Contributors

Contributors are community members who either have no desire to become committers, or have not yet been given the opportunity by the benevolent dictator. They make valuable contributions, such as those outlined in the list below, but generally do not have the authority to make direct changes to the project code. Contributors engage with the project through communication tools, such as email lists, and via reports and patches attached to issues in the issue tracker, as detailed in our community tools document.

Anyone can become a contributor. There is no expectation of commitment to the project, no specific skill requirements and no se-lection process. To become a contributor, a community member simply has to perform one or more actions that are beneficial to the project.

Some contributors will already be engaging with the project as users, but will also find themselves doing one or more of the following:

• supporting new users (current users often provide the most effective new user support)

• reporting bugs

• identifying requirements

• supplying graphics and web design

• programming

• assisting with project infrastructure

• writing documentation

• fixing bugs

• adding features

As contributors gain experience and familiarity with the project, they may find that the project lead starts relying on them more and more. When this begins to happen, they gradually adopt the role of committer, as described above.

Users

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

Users should be encouraged to participate in the life of the project and the community as much as possible. User contributions enable the project team to ensure that they are satisfying the needs of those users. Common user activities include (but are not limited to):

• evangelising about the project

• informing developers of project strengths and weaknesses f-rom a new user’s perspective

• providing moral support (a ‘thank you’ goes a long way)

• providing financial support

Users who continue to engage with the project and its community will often find themselves becoming more and more involved. Such users may then go on to become contributors, as described above.

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 f-rom a vendor. (Of course, that vendor should be an active member of the community.) 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 our roles in open source 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

The benevolent dictatorship model does not need a formal conflict resolution process, since the project lead’s word is final. If the community chooses to question the wisdom of the actions of a committer, the project lead can review their decisions by checking the email archives, and either uphold or reverse them.

Conclusion

The benevolent dictator governance structure is not an easy one to manage and requires a very special person in the role of the project lead. However, it can work extremely well because it is simple. The template provided in this document defines a reasonably manageable model that identifies the main roles, activities and decision-making process undertaken in an open source project.

When creating a benevolent dictator governance document, projects need to ensure that it provides the necessary information about the roles of the project lead and the other contributors, clearly indicating how newcomers can contribute and how their contributions will be recognised.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com