Benevolent
dictator governance model
By Ross Gardler, Gabriel
Hanganu, Published: 15 February 2010, Reviewed: 13 February 2012
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 (bản
dịch tiếng Việt), 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 (bản
dịch tiếng Việt), 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 (bản
dịch tiếng Việt). 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 (bản
dịch tiếng Việt).
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ò (bản
dịch tiếng Việt) 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á (bản
dịch tiếng Việt) 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 (bản
dịch tiếng Việt) 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á
(bản
dịch tiếng Việt). Các cách thức đóng góp khác nhau
được mổ tả chi tiết hơn trong tài liệu về các
vai trò trong nguồn mở (bản
dịch tiếng Việt).
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 create 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.
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 create alternative
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.
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.
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
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
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 selection 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
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 from 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.
All
participants in the community are encouraged to provide support for
new users within the project management infrastructure. This support
is provided as a way of growing the community. Those seeking support
should recognise that all support activity within the project is
voluntary and is therefore provided as and when time allows. A user
requiring guaranteed response times or results should therefore seek
to purchase a support contract from a 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.
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.
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.
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
Không có nhận xét nào:
Đăng nhận xét
Lưu ý: Chỉ thành viên của blog này mới được đăng nhận xét.