Các bài học học được cho việc xây dựng công ty mở với sự cộng tác minh bạch

Thứ tư - 06/07/2016 05:06

Lessons learned for building an open company with transparent collaboration

Posted 23 Jun 2016 by Jos Poortvliet

Theo: https://opensource.com/business/16/6/lessons-learned-open-company

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

Trong phần đầu của loạt bài 2 phần này, Việc xây dựng doanh nghiệp theo mô hình nguồn mở cứng cỏi, tôi đã mô tả cách thức doanh nghiệp nguồn mở cần cung cấp nền tảng cơ bản cứng cỏi cho các bên tham gia đóng góp, những người sử dụng, những người đóng góp, các nhân viên, các khách hàng, và các nhà đầu tư vào khóa học. Các quỹ, các giấy phép, và các thương hiệu có thể là hữu dụng trong việc xây dựng hệ sinh thái mở. Các cộng đồng nguồn mở cần hỗ trợ các tổ chức để làm việc minh bạch, nếu khác thì sẽ có các rào cản cho sự đóng góp. Mã nên là công khai, nhưng mã đánh đống (như Google định làm với Android) không luôn tạo thuận lợi cho sự cộng tác. Để khuyến khích sự cộng tác, bạn phải đi một bước xa hơn và chủ động tích cực. Sự phát triển ở một nơi như GitHub hoặc GitLab, và có các cuộc gặp mặt và hộ nghị lên kế hoạch các tính năng mở sẽ giúp hướng tới mục đích đó. Nhưng vẫn còn, các lãnh đạo dự án nguồn mở có thể làm nhiều hơn.

Cộng tác mở

Quy tắc đầu tiên cho các công ty nguồn mở là làm việc càng mở có thể càng tốt - ví dụ, bằng việc làm cho mã nguồn sẵn sàng trên GitHub, có dòng công việc thông qua các yêu cầu trộn công khai trong các kho công khai, và làm cho trình theo dõi lỗi là mở. Các dự án nguồn mở thường có các kênh IRC và các danh sách thư công khai nơi mà các quyết định kỹ thuật được tranh luận và công bố. Công ty và dự án nguồn mở mới của chúng tôi, Nextcloud, sử dụng mô hình cộng tác mở, với đội phát triển được phân tán. Dù truyền thông mặt đối mặt băng rộng cao độ phải diễn ra đôi khi, chúng tôi chắc chắn các kết quả các cuộc họp được chia sẻ công khai.

Hơn nữa, cộng tác mở có thể tốt hơn. Việc rơi vào cái bẫy thảo luận công nghệ bất kỳ ở đâu có chủ đề - thậm chí trong các danh sách thư phát triển nội bộ - là dễ dàng. Vì thế, chúng tôi đã quyết định chỉ có 1 danh sách thư riêng của công ty cho công việc có liên quan tới nhân sự, và đi trước cả các kênh IRC. Thay vào đó, chúng tôi thảo luận tương lai của Nextcloud trên diễn đàn thảo luận. Điều này ép hội thoại dựa vào chủ đề và chắc chắn rằng các thành viên cộng đồng quyết định có ý thức, cho từng chủ đề, để mở hoặc không.

Hãy chủ động tích cực

Tôi đã học được rằng bạn nên đi xa hơn 1 bước. Các cộng đồng nguồn mở có xu hướng giả thiết quá nhiều tri thức. Đối với những người đóng góp hiện hành và trong tương lai, quy trình ra quyết định và vai trò của công ty không luôn là rõ ràng. Việc ghi lại văn hóa cộng đồng và công ty là quan trọng. Văn hóa của cộng đồng nguồn mở xây dựng qua thời gian, nên việc làm tài liệu về lịch sử của cộng đồng giúp mọi người nhận diện và ra nhập. Hơn nữa, các báo cáo chia sẻ thường xuyên về phát triển đòi hỏi nỗ lực đáng kể trong một cộng đồng rộng lớn, nhưng giúp giữ cho dự án là mở.

Việc ra quyết định

Một khía cạnh rõ ràng hơn khác về sự minh bạch là việc ra quyết định. Ví dụ, chỉ nêu rằng các quyết định được sự đồng thuận đưa ra là không đủ. Sự đồng thuận thường được hiểu ngụ ý mọi người trong một nhóm có sự đồng tình về một giải pháp. Thực tế là trong nhóm lớn và đa dạng mọi người, việc đạt được thỏa thuận đầy đủ về bất kỳ vấn đề đủ phức tạp nào cũng là không có khả năng. Sự đồng thuận, thay vào đó, cho phép quyết định sẽ được đưa ra thậm chí đối mặt với sự không đồng thuận.

Bạn có lẽ quen với cụm từ, “Hãy đồng ý hoặc không đồng ý”. Rốt cuộc trong quá trình ra quyết định, sự đồng thuận đòi hỏi vài người tham gia có thiện chí lùi bước và để quyết định thực sự được đưa ra. Bạn có thể thấy cách điều này có thể làm việc tốt trong cộng đồng với nhiều các bên tham gia đóng góp khác nhau, và thường tốt hơn việc biểu quyết, điều có thể gây ra các quyết định bị phân cực hơn.

Điều này không ngụ ý không có chỗ cho các quy trình chính thống hơn. Khi cộng đồng trở thành lớn, ví dụ, và có các lợi ích xung đột tiềm tàng hơn, thì quy trình phát triển chính thống hơn giúp làm việc với các xung đột. Các nhóm làm việc trực thuộc một quỹ độc lâọp, ví dụ thế, có thể là một giải pháp, điều là thứ gì đó chúng tôi có ý định thiết lập ở Nextcloud, đi theo các ví dụ thành công như OpenStack.

Khi bạn có sự điều hành có cấu trúc được tổ chức tốt, và sự minh bạch và quy trình phát triển mở, thì bạn ở vị thế tốt để xây dựng một cộng đồng lành mạnh xung quanh dự án của bạn. Để tham gia trong quy trình xây dựng Nextcloud, hãy tham gia vào cộng đồng của chúng tôi.


 

In the first part of this two-part series, Building a business on a solid open source model, I described how an open source business needs to provide a solid ground for all stakeholders, users, contributors, employees, customers, and of course investors. Foundations, licenses, and trademarks can be helpful in building an open ecosystem. Open source communities need supporting organizations to work transparently, otherwise there are barriers to contribution. Code might be public, but code dumps (like Google tends to do with Android) don't always facilitate collaboration. To encourage collaboration, you must go one step further and be proactive. Development in a place like GitHub or GitLab, and having open feature planning meetings and conferences help toward that goal. But still, open source project leaders can do more.

Open collaboration

The first rule for open source companies is to work as openly as possible—for example, by making source code available on GitHub, having work flow through public merge requests in public repositories, and making the bug tracker open. Open source projects often have public IRC channels and mailing lists where technical decisions are debated and announced. Our new company and open source project, Nextcloud, uses an open collaboration model, with a distributed development team. Although high-bandwidth face-to-face communication must happen occasionally, we make sure meeting results are shared publicly.

Still, open collaboration could be better. Falling into the trap of discussing technology wherever the subject comes up—even on internal development mailing lists—is easy. Thus, we've decided to have only one company private mailing list for HR-related business, and forego internal IRC channels. Instead, we'll discuss the future of Nextcloud on our discourse forum. This forces a topic-based conversation and makes sure that community members consciously decide, for each subject, to open or not.

Being proactive

I have learned that you need to go one step further. Open source communities have a tendency to assume too much knowledge. For current and future contributors, the decision-making process and the role of the company are not always obvious. Documenting community and company culture is important. An open source community's culture builds over time, so documenting the history of a community helps people identify with and join. Also, regularly sharing reports on development requires significant effort in a large community, but helps keep a project open.

Decision-making

Another more obvious aspect of transparency is decision making. For example, merely stating that decisions are made by consensus is not enough. Consensus is often understood to mean everybody in a group has to agree on a solution. The reality is that in a large and diverse group of people, reaching full agreement on any sufficiently complicated matter is impossible. Consensus, instead, allows a decision to be made even in the face of disagreement.

You're probably familiar with the phrase, "Let's agree to disagree." Eventually in a decision-making process, consensus requires some of the participants to be willing to step out of the way and let a decision actually get made. You can see how this can work well in a community with many different stakeholders, and often better than voting, which can result in more polarized decisions.

This doesn't mean there is no room for more formal processes. When a community grows big, for example, and has more potentially conflicting interests, a more formal development process helps deal with conflicts. Working groups under an independent foundation, for example, might be a solution, which is something we intend to set up in Nextcloud, following successful examples like OpenStack.

When you have the structural governance well organized, and a transparent and open development process, you're in a good position to build a healthy community around your project. To participate in the process of building Nextcloud, join our community.

Creative Commons License

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

 

Tổng số điểm của bài viết là: 0 trong 0 đánh giá

Click để đánh giá bài viết

  Ý kiến bạn đọc

Những tin mới hơn

Những tin cũ hơn

Về Blog này

Blog này được chuyển đổi từ http://blog.yahoo.com/letrungnghia trên Yahoo Blog sang sử dụng NukeViet sau khi Yahoo Blog đóng cửa tại Việt Nam ngày 17/01/2013.Kể từ ngày 07/02/2013, thông tin trên Blog được cập nhật tiếp tục trở lại với sự hỗ trợ kỹ thuật và đặt chỗ hosting của nhóm phát triển...

Bài đọc nhiều nhất trong năm
Thăm dò ý kiến

Bạn quan tâm gì nhất ở mã nguồn mở?

Thống kê truy cập
  • Đang truy cập39
  • Máy chủ tìm kiếm4
  • Khách viếng thăm35
  • Hôm nay3,222
  • Tháng hiện tại104,934
  • Tổng lượt truy cập31,260,406
Bạn đã không sử dụng Site, Bấm vào đây để duy trì trạng thái đăng nhập. Thời gian chờ: 60 giây