Hoàn vốn đối với nguồn mở là gì

What's the Return on investment for Open?

October 15, 2010

Theo: http://civiccommons.com/2010/10/roi-of-open/

Bài được đưa lên Internet ngày: 15/10/2010

Lời người dịch: Đâu là sự hoàn vốn và những lợi ích kinh tế trong dự án nguồn mở? Bài viết này có thể mở lối cho các bạn về điều đó.

Chúng ta từng nói về các phòng IT của chính phủ ở nhiều mức về cách sử dụng các công nghệ mở, và cách để đưng các mã nguồn nội bộ của họ cho những cơ quan khác để sử dụng. Trong quá trình này, chúng ta đã làm một đôi phát hiện sâu sắc sau:

Mỗi người có thể thích mở mã nguồn của họ, cũng như nó không có chí phí nào để làm thế.

Điều đó thường được đi theo bằng một ý nghĩ thậm chí còn sâu hơn:

Nhưng tất cả chúng tôi biết rằng có một chi phí đi với nguồn mở. Vì thế câu hỏi thực tế là: đau là lợi ích? Đâu là sự hòa vốn đầu tư của chúng tôi?

Câu trả lời là “Có lẽ đáng kể đấy - nếu bạn làm nó đúng”.

Để giải thích vì sao, tôi sẽ bắt đầu với một ví dụ định lượng, rồi nhìn vào bức tranh khó định lượng đó đằng sau nó.

We’ve been talking to government IT departments at many levels about how to use open technologies, and how to release their in-house code for other jurisdictions to use. In that process, we’ve made a couple of profound discoveries:

Everyone would love to open up their code, as long as it doesn’t cost anything to do so.

That is usually followed by an even more profound thought:

But we all know that there is a cost to going open. So the real question is: what are the benefits? What’s our return on investment going to be?

The answer is “Possibly significant — if you do it right.”

To explain why, I’ll start with a quantitative example, then look at the harder-to-quantify picture behind it.

Một trong những dự án cộng tác mà tôi đã làm việc nhiều nhất là trong Subversion (một hệ thống theo dõi những thay đổi - “các phiên bản” - làm thành các tệp và các thư mục; sau đó là tên). Subversion đã được bắt đầu bởi ông sếp của tôi, CollabNet. Họ cần một hệ thống kiểm tra phiên bản tốt hơn cho các khách hàng của họ, như một phần của dịch vụ cộng tác trực tuyến được host lớn hơn, và đã nhận thức được rằng sự có mặt ở khắp mọi nơi và không có sự khóa trói có thể là những tài sản mạnh. Vì thế CollabNet đã quyết định tung ra Subversion như là phần mềm nguồn mở từ ngay ban đầu, và họ đã biết, từ kinh nghiệm trong quá khứ với các dự án nguồn mở, rằng họ cần phải đưa vào một vài nỗ lực trong việc kéo theo một cộng đồng xung quanh mã nguồn và làm cho nó dễ dàng để cộng tác trong dự án.

Tại những điểm khác nhau trong dự án - lần đầu bắt đầu 3 hoặc 4 năm, nếu tôi nhớ chính xác - nhiều người tại CollabNet đã cố gắng đo đếm “số lượng“ các đóng góp tới từ bên ngoài. Tôi đặt “số lượng” trong ngoặc vì đây là một thứ rất mẹo mực để đong đếm, và trước khi tôi đưa ra con số, tôi muốn đặt một nhãn cảnh báo khổng lồ lên chúng: việc đánh giá hiệu suất phần mềm là khó, ích lợi của bạn có thể khác nhau, hiệu năng trong quá khứ là không đảm bảo giành được trong tương lai, .v.v.

One of the collaborative projects I’ve worked the most on is Subversion (a system for tracking changes — ”versions” — made to files and folders; hence the name). Subversion was started by my employer, CollabNet. They needed a better version control system for their customers, as part of a larger hosted online collaboration service, and realized that ubiquity and clear lack of lock-in would be strong assets. So CollabNet decided to release Subversion as open source software from the very beginning, and they knew, from past experience with open source projects, that they’d need to put some effort into drawing a community around the code and making it easy to collaborate on the project.

At different points in the project — the first time starting three or four years in, if I recall correctly — various people at CollabNet have tried to measure the “amount” of contribution coming from outside. I put “amount” in quotes because this is a very tricky thing to quantify, and before I give the numbers, I want to put a huge warning label on them: evaluating software productivity is hard, your mileage may vary, past performance is no guarantee of future gains, etc.

Nhưng tôi nghĩ những gì họ đã thấy là có ý nghĩa (tôi sẽ giải thích vì sao trong một lúc):

Gần nhất chúng ta có thể nói, 75% các mã nguồn tới từ những người đóng góp mà họ đã không được trả tiền bởi CollabNet; số còn lại 25% tới từ các lập trình viên của riêng CollabNet - bao gồm cả những người mà họ đã bỏ ra những phần thời ian của họ cam kết với cộng đồng phát triển, như việc đánh giá những thay đổi được đóng góp, dành ưu tiên cho các báo cáo lỗi, …

Nếu bạn coi những cái đó như là giá trị bề mặt, thì đây là hoàn vốn 4 đến 1 cho việc mở mã nguồn của họ và việc quản lý cộng đồng cần cẩn thận. Không tồi - phòng IT của các công dân kẹt tiền ghi lại! Nhưng chúng ta có nên lấy con số đó như giá trị bề mặt? Liệu những dòng mã lệnh có là thứ hợp lý để đo đếm hay không?

Trong hoàn cảnh này, tôi nghĩ chúng là. Trong khi những dòng mã lệnh là không được khuyến cáo cho việc đo đếm năng suất của các lập trình viên cá nhân riêng rẽ, thì chúng là một cách khá đẻ đo đếm những cố lượng mã lệnh tương đối, trong tổng số, theo một dự án chín muồi. Mã lệnh trong Subversion là khá chính xác vì nó là một dự án nguồn mở tích cực. Không có nhiều dòng không cần thiết trong đó - mọi thứ mà đưa nó vào trong kho mã nguồn và nằm ở đó đã vượt qua được kiểm thử gắt gao của một tập thể các lập trình viên.

Và thực sự, đó là câu chuyện thực tế ở đây. Tỷ lệ đóng góp có thể xác định được số lượng – 3 đến 1, 2 đến 1, 4 đến 1, bất kể là gì - có thể khác nhau dựa vào nhiều yếu tố. “Sự hoàn vốn của mở” thực sự thường chỉ ra bản thân trước khi một mẩu mã nguồn được đưa ra để bỏ vào trong dự án. Nhiều lần một trong số chúng tôi, các lập trình viên được hưởng lương của CollabNet, có thể đưa một đề xuất cho một thiết kế tính năng, hoặc thậm chí đưa một cài đặt triển khai cụ thể, và cộng đồng không phải CollabNet có thể tìm kiếm các lỗi và những cải tiến tiềm tàng trong nó. Họ cũng có thể tự mình đóng góp một số tính năng mới, trong một số trường hợp là những tính năng khá chủ chốt. Họ đã đóng góp tài liệu, và thường truyền đi các ý kiến phản hồi đóng góp của người sử dụng, thường tích hợp nó vào dự án ở dạng các báo cáo lỗi có thể phải sửa. Tất cả những thứ này trực tiếp làm lợi cho phần mềm và cũng phải được tính tới như một phần của hoàn vốn. (Trong thực tế, một sự đo đếm lớn có thể nhìn vào các lập trình viên nào trả lời cho các báo cáo lỗi - nghĩa là, ai có thảo luận cần thiết với người báo cáo ban đầu để biến báo cáo đó thành thứ gì đó hữu dụng - và sau đó tương quan cái đó với những những lỗi thực sự sẽ được sửa. Tôi còn chưa có được cơ hội để tiến hành làm dạng nghiên cứu đó, nhưng gợi ý được giáo dục của tôi là việc vai trò xây dựng của cộng đồng phát triển rộng lớn hơn có thể hiện ra khá lớn).

But I do think what they found is meaningful (I’ll explain why in a moment):

As near as we could tell, 75% of the code came from contributors who were not paid by CollabNet; the remaining 25% came from CollabNet’s own developers — including the ones who spent part of their time on engagement with the development community, e.g., evaluating contributed changes, prioritizing bug reports, etc.

If you take that at face value, it’s a 4-to-1 return on investment for open-sourcing their code and stewarding the community with care. Not bad — cash-strapped civic IT departments take note! But should we take the figure at face value? Are lines of code a reasonable thing to measure here?

In this circumstance, I think they are. While lines of code are not recommended for measuring individual programmer productivity, they are a decent way to measure relative amounts of code, in aggregate, in a mature project. The code in Subversion is pretty well vetted, precisely because it’s an active open source project. There aren’t a lot of unnecessary lines in it — anything that makes it into the codebase and stays there has passed the sniff test of a developer collective.

And actually, that’s the real story here. The quantifiable contribution ratio — 3-to-1, 2-to-1, 4-to-1, whatever — might vary based on a lot of factors. The true “RoI of open” usually shows itself before a given piece of code makes it into the project. Many times one of us, the CollabNet-salaried developers, would post a proposal for a feature design, or even post a concrete implementation, and the non-CollabNet community would find bugs and potential improvements in it. They would also contribute new features themselves, in some cases quite major ones. They contributed documentation, and frequently handled user feedback, often integrating it into the project in the form of actionable bug reports. All of this directly benefitted the software and should be counted as part of the return on investment too. (In fact, a great measurement would be to look at which developers respond to bug reports — that is, who has the necessary conversation with the original reporter to turn the report into something useful — and then correlate that with which bugs actually get fixed. I’ve not yet had a chance to do that kind of study, but my educated guess is that the wider development community’s constructive role would loom pretty large.)

Dạng hiệu ứng này là những gì bạn có thể thấy trong hầu hết mọi dự án nguồn mở, cũng bằng đấy nó tích cực và có những người sử dụng. Bạn không thể luôn dễ dàng chỉ ra chính xác bao nhiêu phần trăm mã nguồn đã được đóng góp bởi ai, nhưng bạn có thể thấy, chỉ từ việc theo dõi các nhật ký của dự án và các diễn đàn và cơ sở dữ liệu lỗi, rằng có nhiều người hơn tham gia vào dự án thường có lợi cho tất cả những người tham gia. Và vì các cộng đồng phát triển có xu hướng đẩy các cơ chế cho việc lôi cuốn những giao tiếp của riêng họ ngay từ đầu, nên thường là trong một dự án lành mạnh thì chi phí của sự cộng tác tăng chậm hơn so với những lợi ích có được. Điều này là đúng cho bất kỳ người tham gia nào, không chỉ người khởi tạo công nghệ đó.

Điều này có nghĩa gì đối với một phòng IT dân sự tỉnh táo về ngân sách, tiêu tiền từ thuế cố gắng chỉ ra liệu có đáng để mở ra một số mã nguồn nội bộ hay không?

Nó có nghĩa rằng nếu chứng minh của bạn

• các kế hoạch sử dụng phần mềm lâu dài, và

• vì thế các kế hoạch duy trì phần mềm bằng mọi cách, và

• đôi khi những chứng minh khác cũng có thể cần thiết

… rồi có cơ hội mở ra có thể là một quyết định có trách nhiệm. Chúng tôi không thể nói nó luôn sẽ thế: mỗi dự án có thể có những đặc tính riêng và phải được xem xét theo từng trường hợp một. Nhưng nếu bạn đang xem xét mới ra thứ gì đó, và đang xem xét chi phí để tiến hành, thì có thể ở trên sẽ giúp làm rõ những lợi ích tiềm tàng. Khi ai đó từ những quyền pháp lý khác thấy và sửa một lỗi, những người sử dụng của bạn cũng vẫn hưởng lợi cũng như của họ vậy. Sẽ có những kỹ thuật được thiết lập tốt cho việc hình thành nên những cộng đồng này và chắc chắn rằng những cải tiến về tính năng và những sửa lỗi chảy trong mã cốt lõi và cuối cùng ngược lại ra ngoài tới tất cả những người sử dụng. Một phần của nhiệm vụ công dân chung là phải chắc chắn những kỹ thuật này là được biết rộng rãi và được áp dụng phù hợp cho các dự án công nghệ dân sự.

Trong trường hợp tốt nhất, càng nhiều quyền lực pháp lý sử dụng công nghệ bao nhiêu thì càng nhiều mỗi người trong số họ sẽ giành thắng lợi, khi mà sự duy trì và phát triển được hoàn trả dần qua tất cả họ. Những lợi ích của điều đó có thể là đủ lớn để vượt qua được chi phí được tạo ra bằng việc thiết lập sự hợp tác ngay từ đầu.

Vì thế có thể có sự hoàn vốn thực sự trong việc tung ra mã nguồn của bạn. Với các dự án như Hệ thống Đánh địa chỉ Doanh nghiệp và Bảng tin IT, chúng tôi đang cố gắng chỉ ra chi tiết cách áp dụng sự cộng tác mở đối với những tình huống đặc biệt của các dự án IT dân sự.

Kark Fogel

These sorts of effects are ones you can see in almost every open source project, as long as it’s active and has users. You can’t always easily figure out exactly what percentage of the code was contributed by whom, but you can see, just from watching the project logs and forums and bug database, that having more people join the project usually benefits all the participants. And because development communities tend to evolve mechanisms for absorbing their own communications overhead, it is normal in a healthy project that the costs of collaboration grow more slowly than the benefits do. This is true for every participant, not just the originator of the technology.

What does this mean for a tax-funded, budget-conscious civic IT department trying to figure out whether it’s worthwhile to open up some in-house code?

It means that if your jurisdiction

• plans to use the software for a long time, and

• therefore plans to maintain the software anyway, and

• it’s something other jurisdictions might need too

…then there’s a good chance that opening it up could be a responsible decision. We can’t say it always will: every project can have idiosyncracies and should be looked at on a case-by-case basis. But if you’re considering opening something up, and are examining the costs of doing so, maybe the above will help clarify the potential benefits. When someone from another jurisdiction finds and fixes a bug, your users benefit as well as theirs. There are well-established techniques for forming these development communities and making sure that the bugfixes and feature enhancements flow into the core code and eventually back out to all the users. Part of Civic Commons’ mission is to make sure those techniques are widely known and properly adapted to civic technology projects.

In the best case, the more jurisdictions use the technology, the more each of them wins, as maintenance and development are amortized over all of them. The benefits of that can be great enough to outweigh the costs incurred by setting up the collaboration in the first place.

So there can be real return-on-investment in releasing your code. With projects like the Enterprise Addressing System and the IT Dashboard, we’re trying to show how in detail, and to adapt open collaboration to the particular circumstances of civic IT projects.

-Karl Fogel

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

letrungnghia.foss@gmail.com