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

What'sthe Return on investment for Open?

October 15, 2010

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

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

Lờingười dịch: Đâu là sự hoàn vốn và những lợi íchkinh 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ồnnộ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ệnsâ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âutrả 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’vebeen talking to government IT departments at many levels about how touse open technologies, and how to release their in-house code forother jurisdictions to use. In that process, we’ve made a couple ofprofound discoveries:

Everyonewould love to open up their code, as long as it doesn’t costanything to do so.

Thatis usually followed by an even more profound thought:

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

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

Toexplain why, I’ll start with a quantitative example, then look atthe 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à trongSubversion (một hệ thống theo dõi những thay đổi - “cácphiê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ủatôi, CollabNet. Họ cần một hệ thống kiểm tra phiên bảntốt hơn cho các khách hàng của họ, như một phần củadị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ọinơi và không có sự khóa trói có thể là những tài sảnmạnh. Vì thế CollabNet đã quyết định tung ra Subversionnhư 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ồnmở, rằng họ cần phải đưa vào một vài nỗ lực trongviệc kéo theo một cộng đồng xung quanh mã nguồn và làmcho nó dễ dàng để cộng tác trong dự án.

Tại những điểmkhá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ì đâylà một thứ rất mẹo mực để đong đếm, và trướckhi tôi đưa ra con số, tôi muốn đặt một nhãn cảnh báokhổng lồ lên chúng: việc đánh giá hiệu suất phần mềmlà khó, ích lợi của bạn có thể khác nhau, hiệu năngtrong quá khứ là không đảm bảo giành được trong tươnglai, .v.v.

Oneof the collaborative projects I’ve worked the most on is Subversion(a system for tracking changes — ”versions” — madeto files and folders; hence the name). Subversion was started by myemployer, CollabNet. They neededa better version control system for their customers, as part of alarger hosted online collaboration service, and realized thatubiquity and clear lack of lock-in would be strong assets. SoCollabNet decided to release Subversion as open source software f-romthe very beginning, and they knew, f-rom past experience with opensource projects, that they’d need to put some effort into drawing acommunity around the code and making it easy to collaborate on theproject.

Atdifferent points in the project — the first time startingthree or four years in, if I recall correctly — variouspeople at CollabNet have tried to measure the “amount” ofcontribution coming f-rom outside. I put “amount” in quotesbecause this is a verytricky thing to quantify, and before I give the numbers, I want toput a huge warning label on them: evaluating software productivity ishard, your mileage may vary, past performance is no guarantee offuture gains, etc.

Nhưng tôi nghĩ nhữnggì 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 tacó thể nói, 75% các mã nguồn tới từ những người đónggó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êngCollabNet - bao gồm cả những người mà họ đã bỏ ranhững phần thời ian của họ cam kết với cộng đồngphá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ếubạn coi những cái đó như là giá trị bề mặt, thì đâylà 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úngta có nên lấy con số đó như giá trị bề mặt? Liệunhững dòng mã lệnh có là thứ hợp lý để đo đếm haykhông?

Tronghoà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ăngsuấ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ínmuồ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òngkhông cần thiết trong đó - mọi thứ mà đưa nó vàotrong kho mã nguồn và nằm ở đó đã vượt qua đượckiểm thử gắt gao của một tập thể các lập trìnhviê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 đến1, 2 đến 1, 4 đến 1, bất kể là gì - có thể khác nhaudựa vào nhiều yếu tố. “Sự hoàn vốn của mở” thựcsự 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ầnmột trong số chúng tôi, các lập trình viên được hưởnglương của CollabNet, có thể đưa một đề xuất cho mộtthiết kế tính năng, hoặc thậm chí đưa một cài đặttriển khai cụ thể, và cộng đồng không phải CollabNetcó thể tìm kiếm các lỗi và những cải tiến tiềm tàngtrong 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ínhnă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ủangườ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ữngthứ 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ựctế, một sự đo đếm lớn có thể nhìn vào các lậptrì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 ý đượcgiá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).

ButI do think what they found is meaningful (I’ll explain why in amoment):

Asnear as we could tell, 75% of the code came f-rom contributors whowere not paid by CollabNet; the remaining 25% came f-rom CollabNet’sown developers — including the ones who spent part oftheir time on engagement with the development community, e.g.,evaluating contributed changes, prioritizing bug reports, etc.

Ifyou take that at face value, it’s a 4-to-1 return on investment foropen-sourcing their code and stewarding the community with care. Notbad — cash-strapped civic IT departments take note! Butshould we take the figure at face value? Are lines of code areasonable thing to measure here?

Inthis circumstance, I think they are. While lines of code are notrecommended for measuring individual programmer productivity, theyare 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’ta lot of unnecessary lines in it — anything that makes itinto the codebase and stays there has passed the sniff test of adeveloper collective.

Andactually, that’sthe real story here. The quantifiable contribution ratio — 3-to-1,2-to-1, 4-to-1, whatever — might vary based on a lot offactors. The true “RoI of open” usually shows itself before agiven piece of code makes it into the project. Many times one of us,the CollabNet-salaried developers, would post a proposal for afeature design, or even post a concrete implementation, and thenon-CollabNet community would find bugs and potential improvements init. They would also contribute new features themselves, in some casesquite major ones. They contributed documentation, and frequentlyhandled user feedback, often integrating it into the project in theform of actionable bug reports. All of this directly benefitted thesoftware and should be counted as part of the return on investmenttoo. (In fact, a great measurement would be to look at whichdevelopers respond to bug reports — that is, who has thenecessary conversation with the original reporter to turn the reportinto something useful — and then correlate that withwhich bugs actually get fixed. I’ve not yet had a chance to do thatkind of study, but my educated guess is that the wider developmentcommunity’s constructive role would loom pretty large.)

Dạng hiệu ứng nàylà 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ữngngười sử dụng. Bạn không thể luôn dễ dàng chỉ rachính xác bao nhiêu phần trăm mã nguồn đã được đónggóp bởi ai, nhưng bạn có thể thấy, chỉ từ việc theodõ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ànhmạnh thì chi phí của sự cộng tác tăng chậm hơn so vớinhững lợi ích có được. Điều này là đúng cho bấtkỳ người tham gia nào, không chỉ người khởi tạo côngnghệ đó.

Điều này có nghĩagì đối với một phòng IT dân sự tỉnh táo về ngânsá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ếuchứ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ộimở ra có thể là một quyết định có trách nhiệm. Chúngtô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 theotừng trường hợp một. Nhưng nếu bạn đang xem xét mớira 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ềmtà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ẫnhưở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ênnhững cộng đồng này và chắc chắn rằng những cảitiến về tính năng và những sửa lỗi chảy trong mã cốtlõi và cuối cùng ngược lại ra ngoài tới tất cả nhữngngười sử dụng. Một phần của nhiệm vụ công dânchung là phải chắc chắn những kỹ thuật này là đượcbiế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ốtnhấ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 đượchoà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ủabạ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ớinhững tình huống đặc biệt của các dự án IT dân sự.

Kark Fogel

Thesesorts of effects are ones you can see in almost every open sourceproject, as long as it’s active and has users. You can’t alwayseasily figure out exactly what percentage of the code was contributedby whom, but you can see, just f-rom watching the project logs andforums and bug database, that having more people join the projectusually benefits all the participants. And because developmentcommunities tend to evolve mechanisms for absorbing their owncommunications overhead, it is normal in a healthy project that thecosts of collaboration grow more slowly than the benefits do.This is true for every participant, not just the originator of thetechnology.

Whatdoes this mean for a tax-funded, budget-conscious civic IT departmenttrying to figure out whether it’s worthwhile to open up somein-house code?

Itmeans 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

…thenthere’s a good chance that opening it up could be a responsibledecision. We can’t say it always will: every project can haveidiosyncracies and should be looked at on a case-by-case basis. Butif you’re considering opening something up, and are examining thecosts of doing so, maybe the above will help clarify the potentialbenefits. When someone f-rom another jurisdiction finds and fixes abug, yourusers benefit as well as theirs. There are well-establishedtechniques for forming these development communities and making surethat the bugfixes and feature enhancements flow into the core codeand eventually back out to all the users. Part of Civic Commons’mission is to make sure those techniques are widely known andproperly adapted to civic technology projects.

Inthe best case, the more jurisdictions use the technology, the moreeach of them wins, as maintenance and development are amortized overall of them. The benefits of that can be great enough to outweigh thecosts incurred by setting up the collaboration in the first place.

Sothere can be real return-on-investment in releasing your code. Withprojects like the EnterpriseAddressing System and the ITDashboard, we’re trying to show how in detail, and to adaptopen collaboration to the particular circumstances of civic ITprojects.

-KarlFogel

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

letrungnghia.foss@gmail.com