A
guide to participating in an open source software community
By Stuart Yeates,
Published: 01 June 2005, Reviewed: 11 June 2012
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ở (bản dịch tiếng Việt), để 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 (bản
dịch tiếng Việt). 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 (bản
dịch tiếng Việt).
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
everywhere. 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.
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 where the time for your efforts will come
from. 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.
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 from 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 from time to
time, usually with good intention. We strongly recommend you spend 55
minutes watching ‘How
To Protect Your Open Source Project From 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.
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 from 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.
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 from 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
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.