Chỉ dẫn tham gia trong một cộng đồng phần mềm nguồn mở

A guide to participating in an open source software community

By Stuart Yeates, Published: 01 June 2005, Reviewed: 11 June 2012

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

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

Lời người dịch: Bài viết này sẽ hướng dẫn bạn các cách thức để bạn có thể tham gia vào một dự án phần mềm tự do nguồn mở được dễ dàng, nhất là với các bạn nào có sự ngại ngùng lúc ban đầu. “Đối với hầu hết mọi người, sự đột phá đầu tiên của họ trong một dự án nguồn mở có thể vừa khó vừa sợ. Tuy nhiên, hầu hết những người đó nhanh chóng nhận ra rằng điều đó xứng đáng cho sự nỗ lực. Những phần thưởng là phần mềm chất lượng cao hơn, các chi phí phát triển được giảm và một cơ hội học tập từ những người giỏi nhất. Việc tìm một điểm khởi đầu có thể thường khá khó khăn, nhưng việc học về cấu trúc của một dự án cộng đồng bền vững là một bước hữu dụng hướng tới sự hiểu biết cách mà một người có thể đóng góp cho một dự án cộng đồng”. Xem thêm: Các vai trò trong các dự án nguồn mở (bản dịch tiếng Việt).

Việc tham gia vào một cộng đồng phần mềm nguồn mở (PMNM) ban đầu có thể xem như một triển vọng đáng kinh sợ. Tuy nhiên, các cộng đồng như vậy được tạo nên từ mọi người, với tất cả những ưu và nhược điểm của mọi người ở bất kỳ ở đâu. Những thành kiến nên được tránh. Các cộng đồng PMNM hiếm khi hoàn toàn được gắn vào bằng niềm tự hào của các cá nhân có kỹ thuật cao tự gọi họ là những hackers (cao thủ). Họ cũng không hoàn toàn được tạo nên từ các kỹ sư phần mềm có chứng chỉ. Bạn sẽ biết được tốt hơn chỉ đơn giản bằng việc tham gia vào với cộng đồng như bạn thấy nó, bỏ lại bất kỳ định kiến nào ở ngoài cửa.

Hãy nhớ, các kỹ năng hữu dụng và một chút nỗ lực sẽ luôn được chào đón. Đây là một số mẹo mà có thể làm cho bạn tiến bộ một chút dễ dàng hơn.

Chuẩn bị

Phát huy những điểm mạnh của bạn

Không phải bất kỳ ai cũng có những kỹ năng như nhau, và có nhiều vai trò ngoài việc viết mã trong các dự án nguồn mở. Chúng bao gồm:

• những người viết tài liệu

• những người phiên dịch

• những người thiết kế website

• những người thiết kế giao diện đồ họa cho người sử dụng (GUI), và

• những người làm công việc giao tiếp. Các dự án cũng cần những người duy trì, xây dựng và kiểm thử các máy, những người hỗ trợ những người sử dụng mới, và những người kiểm thử các bản beta. Xem tài liệu riêng biệt của chúng tôi, Các vai trò trong các dự án nguồn mở, để có thêm chi tiết.

Đánh giá cam kết về thời gian của bạn

Hãy quyết định liệu bạn có muốn (và có khả năng) cam kết một số lượng thời gian mỗi ngày hoặc số lượng nhiều hơn đáng kể thời gian theo định kỳ hay không. Hãy thận trọng đưa ra, chỉ nhận càng nhiều càng tốt khi bạn có thể đưa ra một cách thực tế; mọi người tôn trọng công việc hoàn chỉnh nhiều hơn nhiều so với những chào mời trợ giúp trống rỗng. Hãy nghĩ thận trọng về việc lấy đâu ra thời gian cho những nỗ lực của bạn. Nếu bạn đang làm việc trong dự án như một phần của công việc được trả tiền, như hầu hết mọi người đang làm, thì bạn sẽ cần phải chứng minh rằng thời gian đó là cho ông chủ của bạn. Mặt khác, nếu bạn đang bỏ ra một số thời gian của cá nhân vào một dự án, thì hãy chắc chắng cho phép thời gian cho gia đình và bạn bè của bạn.

Kiểm tra hợp đồng thuê làm việc của bạn

Nếu bạn định làm việc trong một dự án như một phần công việc hàng ngày của bạn, thì điều sống còn để kiểm tra hợp đồng thuê làm việc của bạn đối với các câu về các quyền sở hữu trí tuệ - IPR (Intellectual Property Rights) để đảm bảo rằng bạn được phép tham gia trong một dự án nguồn mở. Vì mã phần mềm được bảo vệ bằng bản quyền, chỉ người chủ của mã đó - hoặc một ai đó được người chủ ủy quyền - có thể cấp phép hợp pháp nó cho những người khác sử dụng. Nhiều ông chủ nhận thức được giá trị của việc tham gia của nhân viên trong sự phát triển phần mềm là nó được sử dụng bên trong hãng. Một số ông chủ đã thực hiện bước tiếp theo và đánh dấu nhận thức này trong các chính sách IPR theo pháp luật và/hoặc các hoạt động thuê tuyển. Nếu bạn là một nhà giáo dục có kế hoạch lôi cuốn các sinh viên vào một dự án nguồn mở, thì bạn cũng nên kiểm tra xem thỏa thuận của các sinh viên của họ có cho phép dạng tham gia này hay không và các sinh viên có hiểu được những ảnh hưởng hay không.

Làm quen với cộng đồng

Hiểu cách cộng đồng giao tiếp

Hầu hết các cộng đồng có một cách chấp nhận sự tham gia với cộng đồng. Điều này có thể đơn giản như việc tham gia vào một danh sách thư điện tử của các lập trình viên, và/hoặc áp dụng một mã đặc biệt của vào thức tế. Quan trọng nhất, có lẽ, là để học cách mà các câu hỏi được đưa ra và được trả lời trong cộng đồng phát triển đặc biệt này. Tài liệu Đưa ra các câu hỏi theo cách khôn ngoan như thế nào của Eric Raymong và Rick Moen là một chỉ dẫn tuyệt vời. Đáng bỏ một chút thời gian để làm quen với cộng đồng của bạn trước khi bạn tham gia vào nó.

Hiểu cách cộng đồng được điều hành

Một số cộng đồng, ví dụ, như của nhân Linux, là có tôn ti trật tự với những chuỗi lệnh rõ ràng. Những cộng đồng khác, như cộng đồng xung quanh phát tán Debian, là dân chủ dàn đều. Các dạng cộng đồng khác đòi hỏi các dạng tham gia khác nhau. Hiểu được cách mà các quyết định được đưa ra và các xung đột được giải quyết sẽ giúp bạn hiểu được cách tốt nhất để tham gia với cộng đồng.

Hiểu vai trò của bình luận có tính xây dựng

Văn hóa trong một cộng đồng nguồn mở đặc biệt có thể khác nhau từ cộng đồng này với cộng đồng khác. Cũng hệt như các tổ chức khác nhau vận hành với các văn hóa khác nhau, có những sự khác biệt trong cách những cộng đồng đó giao tiếp. Những thảo luận có thể sống động, trong đó một dải các cá nhân thực sự thể hiện các ý kiến của họ. Mục tiêu cuối cùng là để phát triển xa hơn cộng đồng và phần mềm càng tốt hơn có thể được; điều này chắc chắn đúng cho các cộng đồng chín muồi đã chứng minh được là thành công. Sự bình luận nói chung luôn được hướng tới mục tiêu đó, và không hướng tới con người như một cá nhân. Một ngoại lệ đối với điều này là 'những người độc hại', một hiện tượng được mô tả xa hơn ở bên dưới.

Làm quan với mọi người

Các dự án nguồn mở lớn có một dải rộng lớn những người tham gia và câu trả lời đầu tiên hoặc to tiếng nhất cho câu hỏi luôn không phải là câu trả lời đúng. Bằng việc tuân theo dự án trong khoảng thời gian ngắn bạn có thể có được tri thức hữu dụng về những người có liên quan và các vai trò của họ. Không phải tất cả các cộng đồng nguồn mở hoàn toàn là ảo. Nhiều dự án lớn có những cuộc gặp mặt đối mặt cùng nhau để thảo luận các kế hoạch trong tương lai, hoặc tổ chức các ngày hội mã, và những sự kiện đó có thể được sử dụng để thiết lập các mối quan hệ cá nhân mà sẽ giúp cho thảo luận trực tuyến. Khi được làm tốt, những cuộc gặp mặt vật lý cùng nhau sẽ luôn được phản ánh trong các giao tiếp trực tuyến, như các bài trên twitter, các slide trình chiếu được đưa lên trực tuyến và các biên bản các cuộc gặp.

Hiểu các kênh giao tiếp

Các dự án nguồn mở thường sử dụng các phiên chat (thường là IRC hoặc jabber), các danh sách thư, các website, blog, wiki và các kho kiểm soát phiên bản như những phương tiện giao tiếp ban đầu. hãy làm quen với kiểu giao tiếp của dự án của bạn và các công cụ được ưu tiên.

Học về 'Những người độc hại'

Một số hành vi trong các cộng đồng nguồn mở được xem như là các kiểu chống lại (anti-patterns), theo đó chúng làm tắc hoạt động có tính xây dựng. Hầu hết mọi người sẽ tình cờ tham gia trong mọt hoặc nhiều hoạt động đó lúc này lúc khác, thường với ý định tốt. Chúng tôi khuyến cáo mạnh mẽ bạn bỏ ra 55 phút xem 'Làm thế nào để bảo vệ dự án nguồn mở của bạn khỏi những người độc hại' của Ben Collins-Sussman và Brain W.Fitzpatrick. Video này sẽ không chỉ đưa ra cho bạn các hoạt động nào là không có tính xây dựng, mà còn giúp bạn hiểu được cách để hạn chế tác động của chúng khi bạn thấy chúng trong các hoạt động khác.

Cam kết

Giao tiếp những gì bạn đang làm

Nếu bạn làm việc hoàn toàn cho riêng bạn để tái phát triển một phần của dự án, thì vào thời điểm bạn kết thúc, hầu hết ai đó nhất định sẽ hoặc đúp bản nỗ lực của bạn hoặc dự án có thể đã thực hiện những thay đổi khác rồi mà làm cho công việc của bạn trở nên lỗi thời. Hệ quả tất yếu của sự thiếu hụt việc lên kế hoạch và phối hợp tập trung trong các dự án nguồn mở là một nhu cầu cho mỗi người để mang theo ít nhất một phần gánh nặng của cộng đồng.

Thừa nhận các tài nguyên bạn sử dụng và những người sáng tạo của chúng

Điều quan trọng phải thừa nhận các tài nguyên bạn sử dụng. Điều này làm gia tăng khả năng những người khác cũng sẽ thấy tài nguyên đó, và đưa ra ý kiến phản hồi tích cực cho những người sáng tạo, khuyến khích họ duy trì các tài nguyên hiện hành và phát triển các tài nguyên mới.

Trao ngược lại

Một cộng đồng lành mạnh phụ thuộc vào nguyên tắc của các cá nhân trao ngược lại cho cộng đồng đó. Vì thế, nếu bạn đã nhận được sự hỗ trợ từ cộng đồng, thì cách tốt nhất để chắc chắn tình trạng đó tiếp tục là đền đáp lại bằng việc hỗ trợ cho thành viên khác của cộng đồng khi bạn có thể.

Lên kế hoạch cho chiến lược thoát ra

Có một kế hoạch cho những gì xảy ra cho những đóng góp của bạn cho dự án nguồn mở khi sự cam kết của bạn đối với dự án thay đổi. Nếu bạn là một nhà giáo dục có kế hoạch lôi kéo các sinh viên vào một dự án nguồn mở, hãy có một kế hoạch ở cuối của quá trình đó, khi các sinh viên đi tiếp. Các sửa lỗi, các module được tích hợp tốt, các bản dịch bổ sung, tài liệu và các tư liệu công khai có xu hướng để sống sót được khi các nhà sáng tạo đi khỏi cộng đồng. Phần cứng cục bộ, việc tái cấu trúc hoàn toàn, và các module tích hợp tồi cũng không có xu hướng sống sót được.

Ra đi một cách tranh nhã

Nếu sự tham gia nguồn mở của bạn đang yếu ớt vì công việc, gia đình hoặc các cam kết khác, hãy thông báo cho các thành viên khác của cộng đồng về vấn đề đó, sao cho họ có thể biết được sự uể oải đó và/hoặc tiến hành các bước để giảm dần tải công việc của bạn.

Tóm tắt

Đối với hầu hết mọi người, sự đột phá đầu tiên của họ trong một dự án nguồn mở có thể vừa khó vừa sợ. Tuy nhiên, hầu hết những người đó nhanh chóng nhận ra rằng điều đó xứng đáng cho sự nỗ lực. Những phần thưởng là phần mềm chất lượng cao hơn, các chi phí phát triển được giảm và một cơ hội học tập từ những người giỏi nhất. Việc tìm một điểm khởi đầu có thể thường khá khó khăn, nhưng việc học về cấu trúc của một dự án cộng đồng bền vững là một bước hữu dụng hướng tới sự hiểu biết cách mà một người có thể đóng góp cho một dự án cộng đồng.

Participating in an open source software community can initially seem an intimidating prospect. However, such communities are ultimately composed of people, with all the virtues and foibles of people everywhe-re. Preconceptions should be avoided. Open source software communities are rarely populated entirely by highly technical individuals proud to call themselves hackers. Nor are they composed entirely of certified software engineers. You will get along better by simply engaging with the community as you find it, leaving any preconceptions at the door.

Remember, useful skills and a bit of effort will always be welcome. Here are some tips that may make your progress a little easier.

Prepare

Play to your strengths

Not everyone has the same skills, and there are many roles outside writing code in open source projects. These include:

• documentation writers

• translators

• website designers

• GUI designers, and

• communications people Projects also need people to maintain the build and test machines, people to support new users, and beta-testers. See our separate document, Roles in open source projects, for more details.

Estimate your time commitment

Decide whether you want (and are able) to commit a small amount of time every day or a more substantial amount of time periodically. Be careful to offer to take on only as much as you can realistically deliver; people respect completed work far more than hollow offers of help. Think carefully about whe-re the time for your efforts will come f-rom. If you are working on the project as part of paid work, as most people do, you’ll need to justify that time to your boss. On the other hand, if you are spending some personal time on a project, be sure to allow time for your family and friends.

Check your employment contract

If you intend to work on a project as part of your day job, it is vital to check your employment contract for intellectual property rights (IPR) clauses to ensure that you are permitted to participate in an open source project. Since software code is copyright protected, only the owner of that code - or someone authorised by the owner - may legally license it for others to use. Many employers recognize the value of staff participating in the development of software that is used within the firm. Some employers have taken the next step and mark this recognition within institutional IPR policies and/or employment contracts. If you are an educator planning to involve students in an open source project, you should also check that their student agreement permits this type of involvement and that the students understand the implications.

Get to know your community

Understand how the community communicates

Most communities have an accepted way of engaging with the community. This can be as simple as joining a developers’ email list, and/or adopting a particular code of practice. Most important, perhaps, is to learn how questions are asked and answered in this particular development community. The paper How To Ask Questions The Smart Way by Eric Raymond and Rick Moen is an excellent guide. It is worth spending some time getting to know your community before you participate in it.

Understand how the community is governed

Some communities, for example, that of the Linux kernel, are hierarchies with clear chains of command. Others, such as the community around the Debian distribution, are flat democracies. These different types of communities require different styles of participation. Understanding how decisions are made and conflicts resolved will help you understand how to best engage with the community.

Understand the role of constructive criticism

The culture in a particular open source community may vary f-rom that in other communities. Just as different organisations operate with different cultures, there are differences in how these communities communicate. Discussions can be lively, in which a range of individuals frankly express their opinions. The end goal is to further the development of the software and community as well as possible; this is certainly true for mature communities that have proven to be successful. Critisism is in general always directed towards that goal, and not to the person as an individual. An exception to this are the ‘poisonous people’, a phenomenon that is further described below.

Get to know the people

Large open source projects have a wide range of participants and the first or loudest answer to a query is not always the correct answer. By following the project for a short time you can gain useful knowledge of the people involved and their roles. Not all open source communities are wholly virtual. Many of the big projects have face-to-face get togethers to discuss future plans, or run code fests, and these events can be used to establish personal relationships which will aid online discussion. When done well, these physical get togethers will always be reflected in online communications, such as tweets, slides posted online, and meeting minutes.

Understand the communications channels

Open source projects typically use chat sessions (typically IRC or jabber), mailing lists, websites, blogs, wikis, and version control repositories as their primary means of communication. Get to know your project’s communication style and preferred tools.

Learn about ‘Poisonous People’

Some behaviours in open source communities are seen as anti-patterns1 in that they obstruct constructive activity. Most people will inadvertently engage in one or more of these activities f-rom time to time, usually with good intention. We strongly recommend you spend 55 minutes watching ‘How To Protect Your Open Source Project F-rom Poisonous People’ by Ben Collins-Sussman and Brain W. Fitzpatrick. This video will not only show you which activities are not constructive, but also help you understand how to limit their impact when you see them in others.

Engage

Communicate what you are working on

If you work completely on your own to re-develop part of a project, by the time you finish, someone will almost certainly have either duplicated your effort or the project may have made other changes that render your work obsolete. A corollary of the lack of central planning and coordination in open source projects is a need for everyone to bear at least a portion of the burden of communication.

Acknowledge resources you use and their creators

It is important to acknowledge the resources you use. This increases the likelihood that others will also find the resource, and provides positive feedback to the creators, encouraging them to maintain existing resources and develop new ones.

Give back

A healthy community depends on the principle of individuals giving back to that community. So, if you have received support f-rom the community, the best way to make sure that situation continues is to reciprocate by providing support to another community member when you can.

Plan an exit strategy

Have a plan for what happens to your contributions to the open source project when your commitment to the project changes. If you are a educator planning to involve students in an open source project, have a plan for the end of the course, when the students move on. Bug fixes, well-integrated modules, additional translations, generic documentation and publicity material tend to survive when the creators leave the community. Local hardware, radical restructuring, and poorly integrated modules tend not to.

Retire gracefully

If your open source participation is waning due to work, family or other commitments, inform other community members of the problem, so that they can take up the slack and/or take steps to lower your workload.

Summary

For most people, their first foray into an open source project can be both difficult and scary. However, most quickly realise that it is well worth the effort. The rewards are higher quality software, reduced costs of development and an opportunity to learn f-rom the best. Finding a starting point can often be quite hard, but learning about the structure of a sustainable community project is a useful step towards understanding how one can contribute to a community.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com