Xây dựng một cộng đồng nguồn mở như thế nào

How to build an open source community

By Matthew Mascord, Published: 04 January 2008, Reviewed: 12 March 2012

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

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

Lời người dịch: Sẽ không có phần mềm nguồn mở nếu không có cộng đồng. Vậy phải xây dựng cộng đồng nguồn mở như thế nào? Bài viết này cho chúng ta hiểu về điều đó. “Xây dựng một cộng đồng xung quanh một mẩu phần mềm nguồn mở có thể là công việc chậm chạp, nặng nhọc và sự thành công còn tùy thuộc vào nhiều điều. Dù vậy, không có một cộng đồng, đơn giản sẽ không có dự án. Xây dựng cộng đồng không xảy ra một cách tự động và phải được quản lý một cách thận trọng. Tất cả các cộng đồng bắt đầu từ những người sử dụng, bị cuốn hút bằng việc đóng gói và làm thương hiệu của phần mềm, hoặc những khuyến cáo truyền miệng. Tuy nhiên, một khi chúng tới, thì thách thức sau đó là sống với những kỳ vọng cao đó. Một cộng đồng thịnh vượng các lập trình viên có thể đáp ứng và vượt qua được những kỳ vọng đó, nhưng chỉ nếu lãnh đạo của chúng có thể giữ được cùng nó và đảm bảo cho những người tham gia không tự họ ra đi. Về lâu dài, các cộng đồng cần phải có các cơ chế phát triển mở (bản dịch tiếng Việt) hiện diện để đảm bảo rằng khi những người đóng góp chính, bao gồm cả các nhà sáng lập, chuyển đi, thì các vai trò (bản dịch tiếng Việt) của họ được những người khác đảm nhận”.

Cộng đồng là sống còn đối với một dự án nguồn mở. Một cộng đồng tích cực và đem lại sự giúp đỡ là trái tim của dự án. Tuy nhiên, có một giấy phép nguồn mở là không đủ để mang những người sử dụng và các lập trình viên tới dự án của bạn và xây dựng một cộng đồng. Tài liệu này xem xét những gì tạo nên một cộng đồng nguồn mở thành công.

Vì sao các dự án nguồn mở bắt đầu?

Các dự án phần mềm nguồn mở (PMNM) thực sự khác gì với các dạng dự án phần mềm trong cách mà chúng được khởi xướng. Chúng bắt đầu được hoặc vì ai đó muốn thứ gì đó được xây dựng hoặc, trong trường hợp phát triển sản phẩm, ai đó định đáp ứng các nhu cầu trong tương lai của những người khác. Trong trường hợp đầu, khả năng chia sẻ kết quả cuối cùng có thể thậm chí không bao giờ được cân nhắc tới, trong khi trong trường hợp sau, có ý định nhất định về chia sẻ phần mềm.

Cộng đồng là gì và vì sao các dự án nguồn mở muốn xây dựng chúng?

Các cộng đồng đơn giản là các nhóm cá nhân chia sẻ những lợi ích chung. Các dự án cả nguồn đóng và nguồn mở đều có các cộng đồng những người sử dụng, hầu hết từ những người sẽ khá là thụ động theo nghĩa về các tương tác với những thành viên khác trong cộng đồng. Mặt khác, dạng cộng đồng nào cũng có thể có những thành viên quyết định sẽ nắm các vai trò tích cực hơn thông qua, ví dụ, việc báo cáo các lỗi, giúp những người sử dụng khác, viết tài liệu hoặc đi truyền bá. Các thành viên tích cực nhất thậm chí có thể được tưởng thưởng vì những nỗ lực của họ. Ví dụ, Microsoft thưởng cho những ai trong cộng đồng người sử dụng của họ mà giúp mọi người làm được nhiều nhất về công nghệ của Microsoft thông qua một chương trình Chuyên nghiệp Có giá trị Nhất – MVP (Most Valued Professional). Trong các cộng đồng nguồn mở, các thành viên tích cực có xu hướng sẽ được tưởng thưởng bằng việc được trao sự truy cập bổ sung tới, và kiểm soát, dự án.

Dù có một số phần thưởng trong các dự án nguồn đóng, thì có một sự hạn chế rõ ràng về dạng các đóng góp nhằm kiếm được phần thưởng có thể được các thành viên cộng đồng thực hiện. Vì mã nguồn không mở để cho sự thanh tra kiểm soát, cuối cùng cũng không có cách nào cho những người sử dụng thực sự tiến lên được để sửa các vấn đề hoặc phát triển các tính năng mới hoặc đóng góp mã nguồn trở ngược lại. Ngược lại, khả năng tồn tại trong các cộng đồng nguồn mở cho một dòng chảy thông tin (mã nguồn và tài liệu) từ bất kỳ thành viên nào của cộng đồng lên tới trung ương, dù ở dạng có kiểm duyệt. Quan trọng hơn, đối với bất kỳ vấn đề nào được đưa ra, khả năng tồn tại một số lượng lớn 'những con mắt' sẽ soi xét vào nó, sử dụng sức mạnh trí tuệ của toàn bộ cộng đồng. Trong một dự án nguồn đóng, số lượng tối đa những người soi xét bất kỳ vấn đề gì được đưa ra là luôn bị ràng buộc bởi tổng số các lập trình viên được thuê làm.

Những con đường đặc trưng cho các cộng đồng nguồn mở

Ngay từ lúc khởi đầu của chúng, các cộng đồng nguồn mở có thể là cực kỳ nhỏ, có lẽ với một hoặc hai lập trình viên và hầu như không có bất kỳ người sử dụng nào. Phụ thuộc vào dạng dự án, tình trạng này có thể tiếp diễn trong một khoảng thời gian, thậm chí vài năm, như một 'giai đoạn ươm trồng' trong khoảng thời gian đó đội ban đầu làm việc cật lực để có thứ gì đó chồi lên khỏi mặt đất. Eric Raymond, trong cuốn 'Nhà thờ lớn và Cái chợ' (The Cathedral and the Bazaar), nói rằng một điều kiện tiên quyết cần thiết cho thành công là có 'thứ gì đó chạy được và kiểm thử được để chơi'. Nên được lưu ý rằng 'chạy được' không có nghĩa là tuyệt vời hoặc thậm chí là hoàn chỉnh. 'Phát hành sớm và thường xuyên' là một câu thần chú nổi tiếng của phát triển nguồn mở, không ít hơn vì làm như vậy có thể lôi cuốn được những phản hồi sớm vô giá và xây dựng lòng tin trong dự án. Vì lý do này, các cộng đồng nên không sợ hãi hoặc ngần ngại về việc đưa các tư liệu ra sớm; những lợi ích đáng kể có thể được hiện thực hóa bằng những phát hành sớm miễn là những mong đợi được quản lý rõ ràng và trung thực.

Nếu phần mềm là để cuối cùng thu hút được những người sử dụng, thì sự trình bày và làm thương hiệu phải thuyết phục được những người sử dụng trong tương lai rằng phần mềm đó làm thứ gì đó đáng kể tốt hơn so với sự cạnh tranh. Một khi sự quan tâm đã được đảm bảo, thì rào cản lối vào sau đó phải là thấp: ví dụ, những điều đơn giản, giống như sự cài đặt, thủ tục, cần phải là cực kỳ trơn tru. Việc đăng ký cho những người sử dụng không phải là sự kết thúc của câu chuyện; về lâu dài, các lập trình viên cũng sẽ cần tới, ít nhất để điều hành những đóng góp nhỏ hơn mà có thể cho một lập trình viên đơn độc bị sa lầy. Các lập trình viên có thể nổi lên từ kho những người sử dụng ngay lập tức, nhưng cũng có thể tới từ bất kỳ nơi đâu, được lôi cuốn vào do thách thức kỹ thuật, do tiếng tăm, hoặc cơ hội để cải thiện hoặc quảng cáo các kỹ năng lập trình của họ.

Việc mở ra một dự án theo cách này có thể thêm vào toàn bộ các bộ phức tạp mới. Karrl Fogel trong 'Sản xuất Phần mèm Nguồn Mở' (Producing Open Source Software) nói: 'Việc mở ra có nghĩa là việc sắp xếp mã nguồn để có khả năng lĩnh hội được đối với những người lạ hoàn toàn, thiết lập một website phát triển và các danh sách thư, và thường xuyên viết tài liệu cho lần đầu tiên. Tất cả điều này là rất nhiều công việc. Và tất nhiên, nếu bất kỳ lập trình viên nào có quan tâm để thể hiện, sẽ có gánh nặng bổ sung thêm về việc trả lời các câu hỏi trong một khoảng thời gian trước khi thấy được bất kỳ lợi ích nào từ sự thể hiện của họ'. Tuy nhiên nỗ lực phụ thêm ít nhất một phần được tính tới bằng tính sẵn sàng rồi của các công cụ cộng tác như Sourceforge và Google Code. Bổ sung thêm, việc mở ra các dự án không nhất thiết có nghĩa là đánh mất sự kiểm soát. Nhiều dự án, trong những ngày đầu của chúng, được quản lý như là 'các nhà độc tài nhân từ (bản dịch tiếng Việt) với một người duy nhất có trách nhiệm cho việc phát triển chức năng mới chủ chốt và rà soát lại mã nguồn được đóng góp'.

Các nhà độc tài nhân từ không cần sở hữu các kỹ năng kỹ thuật lớn nhất, nhưng họ sẽ, theo Fogel, có 'khả năng nhận biết được thiết kế tốt'. Tuy nhiên, Fogel tiếp tục, để nhấn mạnh rằng trách nhiệm chính của họ là việc đảm bảo cho những người tham gia tiếp tục chia sẻ đức tin rằng họ 'có thể làm được nhiều hơn trong sự phối hợp hơn là theo từng cá nhân riêng rẽ'. Các lập trình viên sẽ chỉ trụ lại nếu lãnh đạo của họ có thể làm cho dự án trở thành nơi mà họ muốn quay lại. Điều này có nghĩa là tưởng thưởng cho công việc vất vả bằng việc trao sự tin cậy ở những nơi cần thiết và, đối với những người muốn nó, trách nhiệm về các mẩu công việc đáng kể hơn. Quản lý các dự án nguồn mở được mô tả như là tích cực, không chính thức và cường độ thấp. Các nhà độc tài nhân từ thành công cũng được nói sẽ 'nói nhẹ nhàng'. Tất cả điều này cần những người có kỹ năng đáng kể và như Raymond gợi ý, 'một ít kỹ năng trong những người quyến rũ'.

Chỉ đạo rõ ràng các cạm bẫy

Đây là trách nhiệm của các nhà lãnh đạo cộng đồng để đảm bảo các điều kiện tiếp tục là đúng cho tiềm năng đầy đủ của nguồn mở sẽ được hiện thực hóa. Điều này không xảy ra một cách tự động và phải được quản lý một cách thận trọng.

Trong các giai đoạn đầu của chúng, mối lo đáng kể nhất đối với các dự án có lẽ là để làm việc được với gánh nặng hỗ trợ không thể tránh khỏi. Xử lý tồi, điều này có thể, tốt nhất, sẽ dẫn tới việc những người sử dụng quay lưng lại và, tệ nhất, có thể dẫn tới việc người sáng lập sẽ bỏ cuộc. Nếu thành công mà đạt được, thì cuối cùng người lãnh đạo phải tìm ra những người triển khai công việc này. Thuê người là một lựa chọn; lựa chọn khác là khuyến khích những người sử dụng giúp đỡ lẫn nhau bằng việc viết tài liệu và sửa các lỗi. Tuy nhiên, nếu điều này xảy ra, sẽ phải có một hạ tầng tồn tại để cho phép họ làm điều này. Những đóng góp cần phải được khuyến khích một cách chủ động tích cực và những người lãnh đạo cũng cần phải đảm bảo rằng những đóng góp là hữu dụng và có chất lượng đầy đủ. Một khi một dự án trở nên được thiết lập tốt, thì những mối nguy hiểm khác sẽ tới. Một mối nguy hiểm là khả năng vĩnh viễn rằng ai đó có thể lấy mã nguồn và thiết lập một dự án cạnh tranh. Cuối cùng thì điều này, được biết như là sự rẽ nhánh, là gây hại vì nó chia tách và làm tiêu hao cộng đồng các lập trình viên. Nó cũng gây lúng túng và làm xói mòn lòng tin của cộng đồng những người sử dụng và dẫn tới sự đúp bản không cần thiết của các nỗ lực. Vì các cộng đồng người sử dụng và lập trình viên là sự sống và máu của bất kỳ dự án nguồn mở nào, thì bất kỳ sự thiệt hại nào cho chúng đều sẽ luôn đe dọa tới toàn bộ tính bền vững của cả 2 đối với các dự án. Sự cấp bách phải rẽ nhánh có thể nảy sinh vì bất kỳ số lượng lý do nào, chúng có thể là về kỹ thuật hoặc chính trị, nhưng chỉ có thể là đáng kể nếu được ai đó triển khai với đủ số người ủng hộ trong cộng đồng. Trong bất kỳ trường hợp nào, những nhược điểm của sự rẽ nhánh không được ghi tốt thành tài liệu đã dẫn tới sức ép mạnh về mặt xã hội chống lại nó khi những người tham gia biết rằng việc chia tách một cộng đồng không bao giờ thực hiện được một cách dễ dàng cả.

Tiến lên

Để xem xét một cách lành mạnh, các cộng đồng nguồn mở phải có năng lực trong bản thân chúng để vượt qua được lợi ích gốc ban đầu của người sáng lập ra chúng nếu chúng dựa vào một nhà độc tài, thì chúng có rủi ro phân mảnh và sụp đổ khi các lãnh đạo của chúng chuyển đi hoặc về hưu.

Trong hầu hết các cộng đồng, thậm chí những cộng đồng được các nhà độc tài điều hành, mọi người không phải là nhà sáng lập sẽ ngày càng trở nên có trách nhiệm về ra các quyết định chủ chốt. Kết quả theo tự nhiên của điều này là một sự dịch chuyển theo dân chủ dựa vào sự đồng thuận. Sự sắp xếp mới này không ngụ ý rằng tất cả các quyết định, dù là nhỏ, sẽ được ủy ban thực hiện. Hầu hết các đề xuất đúng lúc được quyết định trên cơ sở của 'sự đồng thuận lười biếng' nơi mà 'im lặng là đồng ý'. Để làm việc với những đề xuất mà không đạt được sự đồng thuận thì hầu hết các cộng đồng đều đặt ra một số dạng biểu quyết.

Thói quen và các thủ tục đó càng trở nên phức tạp bao nhiêu, thì càng trở nên quan trọng bấy nhiêu để bổ sung thêm những người mới tới với những chỉ định về cách mà họ có thể bắt đầu tham gia và có tiếng nói trong qui trình ra quyết định. Các cộng đồng trẻ có thể rơi trở lại vào cơ thể tri thức được xây dựng và bị kiềm giữ trong các mạch chủ đề của các danh sách thư nhưng điều này không luôn giúp những người mới tới và có thể làm cho họ bị lúng túng. Điều cần thiết là thứ gì đó được viết xuống, một 'mô hình điều hành' (bản dịch tiếng Việt), để nắm lấy sự hiểu biết được chia sẻ này ở một dạng tài liệu ngắn gọn súc tích. Việc chính thức hóa những sắp xếp sẽ giúp đảm bảo cho cộng đồng có được một cuộc sống của riêng nó - độc lập với bất kỳ cá nhân nào - có thể sống sót và thịnh vượng được, miễn là có một nhu cầu bền vững thực sự cho đầu ra của dự án.

Kết luận

Xây dựng một cộng đồng xung quanh một mẩu phần mềm nguồn mở có thể là công việc chậm chạm, nặng nhọc và sự thành công còn tùy thuộc vào nhiều điều. Dù vậy, không có một cộng đồng, đơn giản sẽ không có dự án. Xây dựng cộng đồng không xảy ra một cách tự động và phải được quản lý một cách thận trọng. Tất cả các cộng đồng bắt đầu bằng những người sử dụng, bị cuốn hút bằng việc đóng gói và làm thương hiệu của phần mềm, hoặc những khuyến cáo truyền miệng. Tuy nhiên, một khi chúng tới, thì thách thức sau đó là sống với những kỳ vọng cao đó. Một cộng đồng thịnh vượng các lập trình viên có thể đáp ứng và vượt qua được những kỳ vọng đó, nhưng chỉ nếu lãnh đạo của chúng có thể giữ được cùng nó và đảm bảo cho những người tham gia không tự họ ra đi. Về lâu dài, các cộng đồng cần phải có các cơ chế phát triển mở (bản dịch tiếng Việt) hiện diện để đảm bảo rằng khi những người đóng góp chính, bao gồm cả các nhà sáng lập, chuyển đi, thì các vai trò (bản dịch tiếng Việt) của họ được những người khác đảm nhận.

Community is vital to an open source project. An active and supportive community is the heart of the project. However, having an open source licence is not enough to bring users and developers to your project and build a community. This document looks at what makes a successful open source community.

Why do open source projects begin?

Open source software projects are not really any different from other kinds of software projects in how they are initiated. They start out either because someone wants something built or, in the case of product development, someone intends to meet the future needs of others. In the former case, the possibility of sharing the end-result may never even be considered whilst in the latter case, there is the specific intention of sharing the software.

What is a community and why do open source projects want to build them?

Communities are simply groups of individuals sharing common interests. Both closed and open source projects have communities of users, most of whom will be relatively passive in terms of their interactions with other community members. On the other hand, either type of community may have members who decide to take on more active roles through, for example, reporting bugs, helping other users, writing documentation or evangelising. The most active members may even be rewarded for their efforts. Microsoft, for example, rewards those in their user community who help people make the most of Microsoft technology through a Most Valued Professional (MVP) programme. In open source communities, active members tend to be rewarded by being granted additional access to, and control over, the project.

Although there are some rewards in closed-source projects, there is a clear limit on the types of reward-earning contributions that can be made by community members. Because the code is not open to inspection, there is ultimately no way for users to actually go ahead and fix problems or develop new features and contribute code back. By contrast, the possibility exists in open source communities for a flow of information (code and documentation) from any member of the community into the centre, albeit in a moderated form. More importantly, for any given problem, the possibility exists for a large number of ‘eyeballs’ to be looking at it, harnessing the brainpower of the entire community. In a closed-source project, the maximum number of people looking at any given problem is always bounded by the total number of employed developers.

Typical paths for open source communities

At their outset, open source communities may be extremely small, perhaps with one or two developers and hardly any users. Depending on the type of project, this situation may go on for some time, even years, as an ‘incubation period’ during which the initial team works hard to get something that works off the ground. Eric Raymond, in The Cathedral and the Bazaar, states that a necessary pre-condition for success is having ‘something runnable and testable to play with’. It should be noted that ‘runnable’ does not mean perfect or even complete. ‘Release early and often’ is a well-known mantra of open source development, not least because doing so can attract invaluable early feedback and build confidence in the project. For this reason, communities should not be fearful or hesitant about putting out materials early; significant benefits can be realised by early releases provided expectations are managed clearly and truthfully.

If the software is to eventually attract users, the presentation and branding must convince prospective users that the software does something significantly better than the competition. Once interest has been secured, the barrier to entry must then be low: for example, simple things, like the installation procedure, need to be extremely slick. Signing up users is not the end of the story though; in the long run, developers are needed too, at least to handle the smaller contributions that may bog down a lone developer. Developers might emerge from the immediate user-base but may also come from elsewhere, drawn in by the technical challenge, kudos, or opportunity to improve or publicise their programming skills.

Opening up a project in this way can add whole new sets of complexities. Karl Fogel in Producing Open Source Software states, ‘Opening up means arranging the code to be comprehensible to complete strangers, setting up a development web site and email lists, and often writing documentation for the first time. All this is a lot of work. And of course, if any interested developers do show up, there is the added burden of answering their questions for a while before seeing any benefit from their presence.’ However the extra effort is at least partly countered by the ready availability of collaboration tools like Sourceforge and Google Code. In addition, opening up projects does not necessarily mean losing control. Many projects, in their early days, are run as ‘benevolent dictatorships with a single person responsible for developing major new functionality and reviewing contributed code.

Benevolent dictators need not possess the greatest technical skills, but they will, according to Fogel, have ‘the ability to recognise good design’. Fogel goes on, however, to make the point that their main responsibility is ensuring participants continue to share the belief that they ‘can do more in concert than individually’. Developers will only remain if their leader can make the project a place they want to keep coming back to. This means rewarding hard work by giving credit where it is due and, for those that want it, responsibility for more significant pieces of work. Management of open source projects has been described as active, informal, and low-key. Successful benevolent dictators are also said to ‘speak softly’. All of this requires considerable people skills and as Raymond suggests, ‘a little skill at charming people’.

Steering clear of the pitfalls

It is the responsibility of community leaders to ensure conditions continue to be right for the full potential of open source to be realised. This does not happen automatically and has to be carefully managed.

In their early stages, the most significant concern for projects is likely to be dealing with the inevitable support burden. Handled badly, this might, at best, lead to users turning away and, at worst, might lead to the founder giving up. If success is to be achieved, the leader ultimately has to find people to carry out this work. Employing people is one option; another is encouraging users to help out each other by writing documentation and fixing bugs. However, if this is to happen, there must be an infrastructure in place to allow them to do this. Contributions need to be proactively encouraged and leaders also need to ensure that contributions are helpful and of a sufficient quality.

Once a project becomes well established, other dangers come into play. One is the ever-present possibility that someone might take the code and set up a competing project. This eventuality, known as a fork, is damaging because it divides and dissipates the developer community. It also confuses and undermines the trust of the user community and leads to needless duplication of effort. As the user and developer communities are the life-blood of any open source project, any damage to these will always threaten the overall sustainability of both projects. The urge to fork might arise for any number of reasons, be they technical or political, but it is only likely to be significant if carried out by someone with enough of a following within the community. In any case, the well-documented disadvantages of forking have led to strong social pressure against it as particpants know that splitting a community should never be undertaken lightly.

Letting go

In order to be considered healthy, open source communities must have the capacity to outlive their founder’s original interest in them If they rely heavily on a dictator, they risk fragmenting and falling apart when their leaders move on or retire.

In most communities, even those governed by dictatorships, people other than the founder will increasingly become responsible for making key decisions. The natural outcome of this is a move towards consensus-based democracy. This new arrangement does not imply that all decisions, however minor, are made by committee. Most of the time propsals are decided on the basis of ‘lazy consensus’ where ‘silence gives assent’. To deal with proposals that don’t reach consensus most communities institue some form of voting.

The more complicated these habits and procedures become, the more important it becomes to aid newcomers with instructions on how they can begin to take part and have a say in the decision making process. Young communities might fall back on the body of knowledge built up and captured in mailing list threads but this does not always help newcomers and can leave them confused. What is needed is something written down, a ‘governance model’, to capture this shared understanding in a concise documentary form. Formalising arrangements helps ensure the community has a life of its own - independent of any one individual - that can survive and flourish for as long as there is a genuine sustained need for the project’s outputs.

Conclusion

Building a community around a piece of open source software can be slow, hard work and success is contingent on many things. Nevertheless, without a community, there simply is no project. Community building does not happen automatically and has to be carefully managed. All communities start with users, attracted by the software’s packaging and branding, or word-of-mouth recommendations. Once they arrive, however, the challenge then is living up to these high expectations. A thriving developer community can meet and exceed these expectations, but only if their leader can keep it together and ensure participants do not go off on their own. In the long run, communities need to have open development mechanisms in place to ensure that when key contributors, including the founders, move on, their roles are adopted by others.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com