Làm thế nào các dự án nguồn mở sống sót được qua những người độc địa (Và bạn cũng có thể)

Theo: http://dobbscodetalk.com/index.php?option=com_myblog&task=view&id=440&Itemid=85

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

Video này là của Ben và Brian từ cộng đồng lật đổ hiện đang làm việc cho Google Code. Video này không chỉ có nội dung kỹ thuật mà còn tập trung đầy đủ vào khía cạnh con người của một quá trình phát triển nguồn mở và kẻ thù tồi tệ nhất của chúng – những người ác độc. Đây là một trong những thảo luận mở ít ỏi về khía cạnh xã hội của sự phát triển dự án. Tôi chắc nó cũng xảy ra trong thế giới các công ty nhưng chúng ta không thể xác định hoặc nói về chúng. Mặc dù cuối cùng thì họ cũng nhận thức được nhưng hầu hết các cuộc nói chuyện phù hợp với mọi cộng đồng hoặc nhóm dự án trong công ty. Vì thế nó sẽ không làm tổn hại tới thời gian của bạn nếu bạn không nằm trong dự án đó. [Tôi cũng đã không đóng góp cho bất kỳ dự án nào cho tới nay!].

Thảo luận của họ làm cho tôi nhận thức được mỗi dự án có bao nhiêu lịch sử, sự xúc cảm và tầm nhìn đằng sau nó. Ngày hôm nay khi bạn thấy hàng ngàn dự án trong các cộng đồng nguồn mở thành công, chúng ta xem để nắm được mọi thứ được cho là như vậy. Nói chuyện là việc chưng cất kinh nghiệm của họ qua các dự án dài hơn 6 năm, khi mà việc trình bày thông tin là súc tích và chính xác.

This video is by Ben and Brian f-rom Subversion community currently working on Google Code f-rom . This video has not a single second of technical content but focused fully on human side of an open source development process and their worst enemy - poisonous people. This is one of those few open discussions on social side of project development. I am sure it happens in corporate world too but we can't identify or talk about them. Although they acknowledge at the end but most of the talk is relevant to any community or project group in corporate. So it will not hurt your time if you are not in project. [I have also not contributed to any project till now! :(]

Their discussion made me realize that how much each project has history, emotions and vision behind it. Today when you see thousands of projects in successful open source communities, we seem to take things for granted. Talk is distillation of their experience over 6++ yrs project(s), hence information presentation is concise and precise.

Complete presentation is broken down into following for major sections:

Trình bày hoàn chỉnh được chia thành các phần chính sau:

• Nhận thức thấu đáo – duy trì sự chú ý và tập trung

• Củng cố – xây dựng một cộng đồng lành mạnh

• Nhận diện – duy trì sự điềm tĩnh và đứng trên quan điểm của bạn

Các lĩnh vực được thảo luận khác là:

• Comprehend - preserve attention and focus

• Fortify - build a healthy community

• Identify - look for tell-take signs

• Disinfect - maintain calm and stand your ground.

Other discussed areas are:

Documentation:

Tài liệu:

Một thứ quan trọng được chỉ ra bởi Ben và Brian là giá trị của tài liệu. Mặc dù họ đã nhấn mạnh và chỉ ra sự thích hợp của mình với thế giới, nhưng tôi thấy chúng ta có thể học được bao nhiêu từ nó. Các tài liệu dần được bổ sung có thể biến thành một cuốn sách tốt, hoặc những chỉ dẫn chính xách là hữu ích trong việc cung cấp các URL cho những người mới tới .v.v. Những gì tôi muốn học là làm thế nào để người lập trình phát triển nguồn mở có thể duy trì và viết tài liệu cùng với các phần mềm. Vì tôi thấy rằng ngay cả trong thế giới các công ty thì nó cũng dao động giữa 2 cực – quá nhiều hoặc không gì cả!

Những thứ chủ chốt để theo dõi như một phần của lịch sử dự án là:

• Các quyết định về thiết kế

• Sửa lỗi

• Các lỗi

• Thay đổi mã nguồn/ thay đổi nhật ký log

One important thing pointed out by Ben and Brian was the value of documentation. Although they have stressed and pointed out its relevance in terms of world, but I see how much we can learn f-rom it. Incremental documentation can turn into a good book, or precise instructions are useful in providing URL to newcomer etc. What I want to learn is how open source developer is able to maintain and write documentation along with software. Since I see that even in corporate world it fluctuates between two extremes -- too much or none at all!

Key things to track as part of project history are:

• design decisions

• bug fixes

• Mistakes

• change log / code change

On Bus factor:

Yếu tố xe buýt (tạm dịch):

Yếu tố xe buýt xác định có bao nhiêu người bị tác động bởi xe buýt (thay đổi công việc, các vấn đề về sức khoẻ, cưới xin .v.v.) làm cho dự án trệch đường. Đây là vấn đề rất sống còn đối với dự án nguồn mở, khi luôn tập trung vào việc gia tăng yếu tố xe buýt của bạn. Tôi có thể nói rằng điều này cũng là rất sống còn đối với các đội làm phần mềm sở hữu độc quyền.

Bus factor defines how many people it takes to be hit by bus (job change, health issues, marriage etc. etc.) to take project off rail. This is very critical for open source project, hence always focus on increasing your bus-factor. I can say that this is also very critical for commercial software teams.

Some other tidbits of advice:

Một vài mẹo tư vấn:

• Gửi các thư điện tử cam kết, khuyến khích xem lại thư điện tử

• Không chuyển đi những thay đổi lớn

• Không bỏ ra tên tác giả ở đầu khi nó đánh dấu khu vực đó. Hãy để nó đưa ra cảm nhận của cộng đồng.

• Send commit emails, encourages email review.

• Do not submit big changes

• Don't out author name at the top as it marks the territory. Let it give the feel of community.

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

ltnghia@yahoo.com