Xây dựng một cộng đồng nguồn mở

Posted August 12th, 2008 by Phil Whitehouse

Theo: https://fossbazaar.org/?q=content/building-open-source-community

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

Lời người dịch: Để có một dự án phát triển phần mềm tự do là dễ hay khó? Bài viết này sẽ trả lời cho bạn cách xây dựng một cộng đồng các nhà lập trình phát triển phần mềm tự do nguồn mở. Nếu đây thực sự là một mô hình phát triển phần mềm tiên tiến, thì Việt Nam liệu bao giờ mới có thể tự điều hành được một dự án phát triển phần mềm tự do nguồn mở đây? Bạn có thể tự đánh giá, và so sánh với việc làm một phần mềm nguồn đóng mà các công ty công nghệ thông tin Việt Nam từng làm. Sự khác biết và độ khó có thể là vô cùng lớn chăng?

Có nhiều cuốn sách được xuất bản mà chúng giải thích cách xây dựng các cộng đồng, nhưng không nhiều cuốn giải thích cách xây dựng một cộng đồng các nhà lập trình phát triển, và hầu như không sách nào tập trung vào các cộng đồng nguồn mở. Một số sách có thể nó rằng các cộng đồng nguồn mở “chỉ ngẫu nhiên sinh ra”, và rằng chúng hoạt động theo sự hiểu biết trực giác và các luật lệ xã hội chưa được viết ra, nhưng logic này lại xem xét kỹ tới số luợng đông đảo các dự án nguồn mở mà chúng thất bại.

Đưa ra tầm quan trọng của các cộng đồng xung quanh các phần mềm nguồn mở, điều cơ bản để hiểu dấu hiệu đảm bảo của các cộng đồng nguồn mở thành công khi bắt đầu dự án nguồn mở của riêng bạn. Việc tạo một khung công việc có hiệu quả trong đó cộng đồng có thể hoạt động thường tạo ra sự khác biệt giữa thành công và thất bại.

Việc tiến hành điều này liên quan một cách đúng mức tới suy nghĩ và sự nỗ lực, cả 2 là hàng đầu và sống động. Sẽ tốt cho bạn và tổ chức của bạn nhận thức được về điều này trước khi bạn bắt đầu, hơn là có ảo tưởng rằng khung công việc này sẽ tạo ra và tự quản lý theo một cách nào đó!.

Vì thế ở đây có một vài hướng dẫn để xem xét. Không có đảm bảo chúng sẽ làm việc, nhưng điều này là triển khai được tốt hơn, cơ hội cao hơn mà cộng đồng sẽ kết hợp lại với những lợi ích không nhìn thấy trước được.

There are many books published that explain how to build communities, but not so many explaining how to build a developer community, and hardly any which focus on open source communities. Some might say that open source communities "just happen", and that they operate on intuition and unwritten social rules, but this logic overlooks the vast quantity of open source projects that fail.

Given the importance of the communities around open source software, it's essential to understand the hallmarks of successful open source communities when starting your own open source project. Creating an effective framework in which the community can operate often makes the difference between success and failure.

Doing this properly involves thought and effort, both up front and in life. It's best for you and your organisation to be aware of this before you get started, rather than being under the illusion that the framework will somehow cre-ate and manage itself!

So here are some guidelines to consider. There's no guarantee they'll work, but the better these are implemented, the higher the chance that the community will coalesce with unforeseen benefits.

1. Có lẽ dường như rõ ràng, nhưng để tìm hiểu vì sao bạn đang xây dựng cộng đồng ở vị trí đầu tiên. Liệu có phải chỉ để cải thiện sự áp dụng hay không? Hay cải thiện sự tin cậy? Hay cải thiện chất lượng? Hay phát triển một hệ thống tương trợ về hỗ trợ? Bất kể là gì, sự tìm hiểu này và chắc chắn mỗi người trong đội của bạn biết và đồng ý. Hãy thử treo một vài giá trị sơ bộ ra khỏi các mục tiêu, để bạn có thể theo dõi qui trình và thực hiện những chỉnh sửa cho đúng.

2. Sẵn sàng từ bỏ sự kiểm soát của sản phẩm “của bạn”. Những cộng đồng thành công nhất tạo ra xung quanh những thứ mà họ có thể gây ảnh hưởng và dẫn hướng. Bạn càng bàn giao sự kiểm soát bao nhiêu, thì cơ hội cộng đồng của bạn sẽ hình thành bấy nhiêu, và cơ hội càng nhiều cho ai đó sẽ theo kịp với một ý tưởng mà bạn đã không nghĩ tới bấy nhiêu. Tôi sẽ nói lại một lần nữa: Hãy bỏ đi nhiều công việc bạn có thể điều hành.

3. Xét những động cơ của cộng đồng. Hầu hết các nhà lập trình phát triển được định hướng bởi một vài hoặc tất cả những thứ sau: (a) mong muốn sáng tạo, (b) mong muốn chia sẻ, (c) nhu cầu kiếm sống. Hãy nhìn vào những thứ này một cách chi tiết.

• Mong muốn sáng tạo: Xét về tự nhiên của những gì bạn đang bàn giao. Rõ ràng những gì nó phải được sử dụng để làm gì chứ? Hoặc liệu nó có được thiết kế để được sử dụng trong tất cả các cách thú vị hay không? Hãy cố gắng thiết kế các sản phẩm mà có thể được sử dụng theo nhiều cách nhất có thể. Hãy làm cho nó tương hợp được và mở rộng được, sao cho nó có thể kết hợp được với các sản phẩm khác. Các tiêu chuẩn mở là con đường phải đi theo. Chất lượng của tài liệu hỗ trợ cũng tạo ra một sự khác biệt lớn.

• Mong muốn chia sẻ: Các nhà lập trình phát triển nguồn mở tự hào trong việc chia sẻ công việc của họ với những đồng bạn của họ, và điều này là cách mà họ thiết lập lòng tin trong môi trường này. Nếu bạn tạo ra các công cụ cộng đồng, hãy làm cho nó càng dễ dàng càng tốt cho các nhà lập trình phát triển (và những người sử dụng tiềm năng) để chia sẻ công việc của họ và cho những người khác để tìm ra nó. Hãy giúp đỡ các nhà lập trình phát triển để tìm được nhau, và làm việc cùng với nhau, và sau đó hãy đi khỏi con đường đó!

• Nhu cầu kiếm sống. Bằng việc trao cho mọi người một nền tảng để thể hiện tính sáng tạo và kỹ năng của họ, bạn sẽ cải thiện được viễn cảnh được có công việc của họ.

1. Hãy thể hiện sự khiêm tốn. Bạn cần cộng đồng nhiều hơn họ cần bạn. Một ngày nào đó, nếu bạn đối xử đúng cách một thời gian dài, họ sẽ bắt đầu tin tưởng bạn và đối xử với bạn như nhà lãnh đạo tinh thần của họ. Ngay cả sau đó bạn sẽ còn cần tới họ nhiều hơn là họ cần bạn! Bạn là nô bộc của cộng đồng, và việc suy nghĩ theo cách này sẽ dẫn tới mọi dạng hành vi phù hợp. Và nếu bạn kinh qua việc trà xát với cộng đồng tiếp tục theo con đường này, sẽ có một cơ hội tốt để bạn quên đi hướng dẫn này.

2. Hãy chọn cẩn thận ngôn từ của bạn. Tránh việc sử dụng những thuật ngữ như 'quản lý', 'khai thác' hoặc 'sở hữu' cộng đồng. Hãy trừng phạt các đồng nghiệp vì làm như vậy. Hãy tôn trọng những nhu cầu đã ăn sâu trong văn hoá doanh nghiệp của bạn. Một khi bạn đã tạo lập ra khung công việc cho cộng đồng, thứ duy nhất bạn có thể quản lý là quan hệ của bạn với cộng đồng này. Hãy sử dụng các từ như 'ảnh hưởng', 'hỗ trợ' và 'trợ giúp'.

3. Các vòng liên hệ ngược cần được xây dựng trong lõi. Hãy trao cho cộng đồng các công cụ để giao tiếp với bạn, và đảm bảo ai đó có trách nhiệm làm việc với điều này. Các tài nguyên được phân phối cho điều này phải được bảo vệ mạnh mẽ; họ là các đại sứ của bạn. Những người tốt nhất của bạn phải được tham gia. Đây là một trong những ưu tiên hàng đầu của bạn, bất kể liệu bạn có với tới được đông đảo quần chúng hay không. Nếu ai đó có một câu hỏi, bạn sẽ càn phải ở vào vị trí tốt để ngay lập tức nhảy vào cơ hội đó và giúp càng nhiều càng tốt để họ nắm được. Hãy để người của bạn phát triển các mối quan hệ cá nhân với các thành viên cộng đồng. Hãy để họ gặp gỡ trong cuộc sống thực, và sẵn sàng trả tiền bia. Hãy sẵn sàng từ bỏ sự kiểm soát đối với những cán bộ của bạn cũng như sản phẩm của bạn.

4. Hãy trở thành người quan sát. Sự cảm thông được phác hoạ ở trên có thể là trách nhiệm quan trọng nhất khi điều hành một cộng đồng nguồn mở, đặc biệt là trong những ngày đầu. Và nếu bạn là một công ty lớn, và giống nhwu những công ty lớn khác bạn đang chiến đấu để đổi mới, thì mối quan hệ này sẽ đặt bạn vào một vị trí duy nhất. Từ đây, bạn có thể quan sát những gì mọi người đang làm với các công cụ của bạn, vì thế bạn có thẻ cải thiện họ nhanh chóng theo phản ứng. Hãy xây dựng các sản phẩm với 'sự cấu hình lại' nhanh chóng này trong đầu. Và từ vị trí được tán dương này, bạn cũng có thể xác định được các đối tác tiềm năng với những ai bạn có thể đưa công việc kinh doanh của bạn tiến lên phía trước.

Hãy xuất xưởng một sản phẩm chất lượng. Nếu bạn nghĩ cộng đồng những người phát triển đang hoàn tất công việc của bạn cho bạn, thì bạn sẽ có một sự sốc không mong đợi! Đừng sử dụng một phiên bản beta như một lý do để xuất một sản phẩm mà vừa chưa hoàn thiện vừa đầy những lỗi. Nếu bạn làm thế, bạn sẽ đánh mất mọi sự tin tưởng mà bạn có thể có với cộng đồng phát triển, và họ không thể quay lại lần thứ 2. Trong thời đại ngày nay, sẽ không có sự thứ lỗi vì không xây dựng theo chất lượng khi bạn muốn đi xa.

1. Các chi tiết *thực sự* là vấn đề. Nếu bạn định thực hiện một thay đổi cho một sản phẩm, dịch vụ hoặc cộng đồng, dù là nhỏ mấy chăng nữa, hãy chắc chắn là cộng đồng hạnh phúc với điều đó. Không có việc đánh spam các diễn đàn, bạn còn cần phải chắc chắn là những người quan trọng sẽ tìm ra và có thể trả lời. Nếu bạn may mắn, và bạn đã làm một công việc tốt là tạo ra những vòng liên hệ ngược, thì cộng đồng sẽ nói cho bạn những gì họ nghĩ.

2. Khi bạn ra một quyết định, hãy giải thích nó. Sự giải thích của bạn phải đứng trên quan điểm của riêng nó; đừng có chỉ dựa vào một cuộc đối thoại – thực sự nói ra logic và ý kiến phản hồi mà nó dẫn tới quyết định của bạn. Một lần nữa, hãy làm thế trên cùng một diễn đàn như trước đó. Bạn nợ – hàm ơn cộng đồng này nhiều đấy.

3. Đưa ra một vài ý nghĩ như đối với các công cụ phù hợp nhất mà cộng đồng sẽ làm quen – và sử dụng các công cụ đó. Bạn cần từ bỏ sự kiểm soát đối với các tranh luận cũng như bản thân sản phẩm. Sẽ là các công cụ tương xứng tuyệt vời ở đó như getsatisfaction, Google Groups, Facebook, Soureforge, Trac, các phần mềm blog, các danh sách thư điện tử và nhiều thứ khác. Mọi thứ mà có mùi như công ty lớn (BigCo) có thể làm mất các thành viên cộng đồng tiềm năng.

4. Hãy sẵn sàng cung cấp hỗ trợ về tài chính. Rõ ràng, điều này phụ thuộc vò ngân sách và dự án của bạn, nhưng nó không cần phải là đắt giá. Nó đơn giản có thể liên quan tới việc mua cho người đóng góp cho cộng đồng tên Bob chẳng hạn chiếc card Nvidia mới nhất để anh ta có thể viết các trìnhh điều khiển, hoặc trả tiền cho cô Manuela nào đó để dự một hội nghị sao cho cô ta có thể nói về dự án này. Việc có vòng liên hệ ngược được đề cập ở trên phải giúp bạn nắm được các cơ hội để phát triển người đại sứ bên ngoài tổ chức của bạn.

5. Tất nhiên, ngay cả nếu bạn tính tới tất cả các cơ hội này, vẫn không có đảm bảo rằng dự án của bạn sẽ thành công! Nhưng như chúng tôi có thể thấy có rất nhiều thứ mà có thể được thực hiện để cải thiện những xung đột.

1. Might seem obvious, but figure out why you're building the community in the first place. Is it just to improve adoption? Improve credibility? Improve quality? Develop an ecosystem of support? Whatever it is, figure this out and make sure everyone on your team knows and agrees. Try and hang some rudimentary metrics off the targets, so you can track progress and make course corrections.

2. Get ready to relinquish control of “your” product. The most successful communities form around things they can influence and drive. The more control you hand over, the more chance your community will form, and the more chance someone will come up with an idea you haven't thought of. I'll say it again: Give away as much as your business can handle.

3. Consider the motivations of the community. Most developers are driven by some or all of the following: (a) a desire to be creative, (b) a desire to share, (c) the need to make a living. Let's look at these in more detail.

3a. The desire to be creative. Consider the nature of what you're handing over. Is it obvious what it should be used for? Or has it been designed to be used in all sorts of interesting ways? Try to design products that can be used in as many ways as possible. Make it interoperable and extendable, so it can be combined with other products. Open standards are the way forward. The quality of the supporting documentation can also make a big difference.

3b. The desire to share. Open source developers take pride in sharing their work with their peers, and this is how they establish credibility in this space. If you're creating community tools, make it as easy as possible for developers (and potential users) to share their work and for others to find it. Help developers to find each other, and work together, and then get out of the way!

3c. The need to make a living. By giving people a platform to demonstrate their creativity and skill, you improve their employment prospects.

4. Demonstrate humility. You need the community more than they need you. Someday, if you behave the right way for a long period of time, they will start to trust you and treat you as their moral leader. Even then you'll still need them more than they need you! You are the servant of the community, and thinking this way will drive all sorts of appropriate behaviour. And if you're experiencing friction with the community further down the path, there's a good chance you've forgotten this guideline.

5. Choose your language carefully. Avoid using terminology such as 'managing', 'exploiting' or 'owning' the community. Chastise your colleagues for doing so. Respect needs to be ingrained in your corporate culture. Once you've established the community framework, the only thing you can manage is your relationship with the community. Use words like 'influence', 'support' and 'help'.

6. Feedback loops need to be built into the core. Give the community tools for communicating with you, and make sure someone is responsible for dealing with this. Resources allocated to this must be fiercely protected; they are your ambassadors. Your best people should be involved. It is one of your top priorities, regardless of whether you've hit critical mass or not. If someone has a question, you'll need to be well positioned to immediately jump on the opportunity to give as much help as they'll take. Let your people develop personal relationships with community members. Let them meet in real life, and be ready to pay for the beer. Be ready to relinquish control over your staff as well as your product.

7. Be observant. The responsiveness outlined above is perhaps the most important responsibility when running an open source community, especially so in the early days. And if you're a large company, and like many large companies you're struggling to innovate, this relationship puts you in a unique position. F-rom here, you can observe what people are doing with your tools, so you can improve them quickly in response. Build the products with this quick 'reconfigurability' in mind. And f-rom this vaunted position, you can also identify potential partners with whom you could move your business forward.

8. Ship a quality product. If you think the developer community is going to finish your job for you, you're in for an unpleasant shock! Don't use a beta release as a reason to ship a product that's either incomplete or full of bugs. If you do this, you'll lose any credibility you may have with the developer community, and they mightn't come back a second time. In this day and age, there is no excuse for not building in quality as you go along.

9. Details *really* matter. If you're about to make a change to a product, service or community, no matter how small, make sure the community is happy with this. Without spamming forums, you still need to be sure the important people find out and can respond. If you're lucky, and you've done a good job creating the feedback loops, the community will tell you what they think.

10. When you've made a decision, explain it. Your explanation should stand on it's own; don't just point at a conversation - actually spell out the logic and the feedback that has led to your decision. Again, do so on the same forums as before. You owe the community that much.

11. Give some thought as to the most appropriate tools that the community will be familiar with – and use those tools. You need to relinquish control over the conversation as well as the product itself. There are perfectly adequate tools out there such as getsatisfaction, Google Groups, Facebook, Soureforge, Trac, blogging software, simple mailing lists and so on. Anything that smells like BigCo might put off potential community members.

12. Be ready to provide financial support. Obviously, this depends on your budget and project, but it needn't be expensive. It could simply involve buying community contributor Bob the latest Nvidia card so he can write drivers, or paying for Manuela to attend a conference so she can talk about the project. Having the feedback loops mentioned above should help you spot these opportunities to develop ambassadors outside your organisation.

Of course, even if you take account of all of these opportunities, there's still no guarantee that your project will be a success! But as we can see there's an awful lot of things that can be done to improve the odds.

Dịch tài liệu: Lê Trung Nghĩa

letrungnghia.foss@gmail.com