Thứ Ba, 26 tháng 2, 2013

Nguồn mở bền vững

Sustainable open source
By Ross Gardler, Published: 05 August 2008, Reviewed: 15 February 2012
Bài được đưa lên Internet ngày: 15/02/2012
Lời người dịch: Muốn có được sản phẩm phần mềm nguồn mở bền vững cần phải có kế hoạch mục tiêu rõ ràng ngay từ đầu trong việc phát triển, duy trì, quản lý, cấp vốn, xây dựng cộng đồng xung quanh sản phẩm và những công việc phi kỹ thuật khác. Bài viết sẽ chỉ cho bạn nên chọn mô hình nào ngay từ khi khởi xướng một dự án nguồn mở để có được nguồn mở bền vững. Bài viết cũng chỉ ra 4 dạng công ty có khả năng khai thác phần mềm nguồn mở theo cách thương mại.
Nguồn mở bền vững là một dự án nguồn mở hỗ trợ được bản thân nó. Nói đơn giản, dự án có khả năng trang trải các chi phí nó phải gánh chịu, nó có thể là đáng kể thậm chí trong một dự án do những người tình nguyện dẫn dắt. Tài liệu này xem xét một số mô hình theo đó một dự án nguồn mở có thể trở nên bền vững.
Đạt được tính bền vững
Để bền vững thì một dự án phải đáp ứng được các chi phí của riêng nó. Hầu hết các dự án có các chi phí ban đầu của chúng được một sự bơm vốn từ một đơn vị cha hoặc người đỡ đầu trang trải. Tuy nhiên, điều gì sẽ xảy ra khi đám tiền này sẽ hết?
Không chắc là dòng cấp vốn ban đàu sẽ còn là một lựa chọn có thể tồn tại vô hạn định. Ở thời điểm nào đó hoặc doanh thu phải được tạo ra hoặc tiết kiệm chi phí phải được hiện thực hóa. Một dự án nguồn mở bền vững là một dự án trong đó doanh thu hoặc sự tiết kiệm chi phí này vượt xa chi phí hỗ trợ và phát triển đang có.
Thực tế không may của phát triển phần mềm là đại đa số các dự án không trở thành bền vững. Điều này là đúng cả với các dự án phát triển phần mềm nguồn mở và nguồn đóng. Trên thực tế đúng là bất kỳ hoạt động nào cũng đòi hỏi hỗ trợ tài chính để sống sót. Thực tế đó là hầu hết các ý tưởng mới không đạt được tính bền vững, trong khi chỉ một nhúm nhỏ thành công.
Vì thế điều quan trọng để hỏi vì sao các dự án không đạt được tính bền vững. Trong một số trường hợp điều này là vì dự án không đạt được những gì nó đã đặt ra để đạt được. Trong các trường hợp đó một người có thể kỳ vọng dự án sẽ được phép biến mất. Tuy nhiên, trong một số lượng lớn đáng lo ngại các trường hợp thì dự án không đạt được các mục tiêu ban đầu của nó, vẫn tiếp tục thất bại. Điều này đặc biệt đúng trong công việc phát triển được cấp vốn trong khu vực giáo dục trung học (HE) và giáo dục cao hơn (FE). Dạng thất bại này thường do sự thất bại trong việc lên kế hoạch cho thành công gây ra. Đó là, không có kế hoạch sớm về cách mà dự án bản thân nó sẽ bền vững khi việc cấp vốn hạt giống ban đầu tiêu hết, và sau đó không có tài nguyên nào được chỉ định cho việc đạt được tính bền vững nữa cả.
Kết luận vì thế là rõ ràng: để đạt được tính bền vững thì dự án phải tiến hành việc triển khai một kế hoạch về tính bền vững như một trong những mục tiêu ban đầu của nó. Sau đó kế hoạch về tính bền vững đó phải được phát triển ở ngay giai đoạn đầu trong cuộc sống của dự án. Tuy nhiên, để xây dựng kế hoạch này cần phải hiểu được những lựa chọn gì là có sẵn cho bạn.
Không có khả năng để liệt kê tất cả các lựa chọn về tính bền vững trong khung cảnh này, có nhiều mô hình như có nhiều ý tưởng dự án vậy. Tuy nhiên, các phần tiếp sau phác thảo một vài mô hình về tính bền vững chung cho phần mềm nguồn mở (PMNM).
Nên nhận thức được rằng rất ít dự án nằm vuông vức trong một trong các mô hình đó. Hầu hết các dự án bền vững được vì chúng được xây dựng trong một sự kết hợp các yếu tố khác nhau từ từng mô hình; tương tự có các mô hình tương đối chồng chéo lên nhau. Các phần tiếp sau chỉ có ý định đưa ra thực phẩm cho các tư tưởng khi bạn bắt đầu làm việc trong kế hoạch về tính bền vững của riêng bạn. Ý định là chúng sẽ xúc tác cho bạn để tiếp cận các nhà tư vấn, như OSS Watch với một số hiểu biết về các cơ hội đặt ra trước bạn.
Phát triển sản phẩm
Một công ty mà công việc kinh doanh của nó dựa vào các sản phẩm nguồn mở là không khác gì với bất kỳ doanh nghiệp nào khác. Đó là, nó phải đầu tư một số doanh thu của nó và phát triển sản phẩm. Có 4 dạng công ty có khả năng khai thác thương mại phần mềm nguồn mở:
  • các công ty dịch vụ làm cho phần mềm sẵn sàng như nguồn mở để tạo ra thị trường càng lớn càng tốt để trả tiền cho các sản phẩm của họ, như sự hỗ trợ, huấn luyện, tùy biến, các máy tìm kiếm, các hoạt động thương mại điện tử …
  • các công ty phần cứng mà muốn gia tăng thị trường tiềm năng cho phần cứng của họ, như các nhà sản xuất máy in hoặc điện thoại di động
  • các công ty phần mềm mà ứng dụng các thành phần nguồn mở
  • các công ty phần mềm mà có một mô hình cấp phép đôi và phát hành một phiên bản nguồn mở sản phẩm của họ cùng với một phiên bản sở hữu độc quyền sản phẩm của họ
Một công ty được đưa ra là không bị giới hạn vì bất kỳ hoạt động nào; tương tự, có thể có nhiều hơn một công ty có liên quan trong việc thương mại hóa từng dự án phần mềm nguồn mở.
Đối với các công ty dịch vụ và phần cứng thì dòng lợi nhuận chính không xuất phát từ việc bán bản thân phần mềm. Điều này làm cho nó có khả năng phát hành phần mềm dưới một giấy phép nguồn mở để hưởng lợi từ những đóng góp từ các bên thứ 3.
Trong trường hợp các công ty dựa vào các dịch vụ thì các động lực cho việc mở mã nguồn là rất tương tự. Một công ty bán công việc tư vấn hoặc tùy biến mong muốn đảm bảo rằng các dịch vụ của họ là theo yêu cầu rộng rãi nhất có thể, nên việc phát hành một sản phẩm cốt lõi như nguồn mở là một một cách thức để gieo hạt giống cho thị trường. Hơn nữa, đối với các công ty cung cấp các dịch vụ hướng phần mềm, như các máy tìm kiếm, các dịch vụ web 2.0 hoặc các hoạt động thương mại điện tử có lý do tốt cho các phần phi cạnh tranh của bộ phần mềm là nguồn mở của họ. Điều này cho phép tiết kiệm chi phí trong sự phát triển ban đầu và vận hành cũng như sự duy trì liên tục thông qua các chi phí phát triển được chia sẻ. Ví dụ, Amazon, IBM, Yahoo!, EBay, Facebook và nhiều công ty nữa sử dụng và đóng góp cho máy chủ web Apache HTTPD và GNU/Linux.
Trong trường hợp của các công ty phần cứng thì động lực hướng tới nguồn mở có thể là để mở rộng thì trường cho phần cứng của họ hoặc nó có thể có động lực làm giảm các chi phies phát triển sản phẩm. Ví dụ, một nhà sản xuất máy in có thể mở nguồn phần mềm trình điều khiển của họ để cho phép nó được tùy biến cho những nền tảng khác nhau, vì thế thị trường theo đó họ có thể bán phần cứng được mở rộng. Ví dụ khác là một nhà sản xuất điện thoại di động mà có thể chọn sử dụng phần mềm nguồn mở như là hệ điều hành cốt lõi để chia sẻ các chi phí phát triển các chức năng chung với các nhà sản xuất khác.
Các công ty phần mềm mà kiếm lợi nhuận của họ từ việc bán phần mềm có 2 mô hình có sẵn cho họ. Tuy nhiên, mỗi trong 2 mô hình đó chỉ sẵn sàng theo những giấy phép nguồn mở nhất định. Các công ty đó mong muốn nhúng phần mềm nguồn mở vào trong các sản phẩm sở hữu độc quyền có thể làm thế với cái gọi là các giấy phép nguồn mở 'dễ dãi' (thường được biết tới như là các giấy phép dạng BSD). Ngược lại, các công ty khác chọn một mô hình cấp phép đôi (Bản dịch tiếng Việt) cho các sản phẩm phần mềm của họ bằng việc áp dụng cái gọi là giấy phép 'copyleft' (như GPL) trong khi cũng chào bán phần mềm theo một giấy phép sở hữu độc quyền.
Phát triển mở phi lợi nhuận
Trong nhiều trường hợp phần mềm được một tổ chức phát triển mà, trong bản thân nó, không phải là một phần của dòng doanh thu. Trong trường hợp này nó thường có thể hưởng lợi để phát hành mã như là nguồn mở để trải rộng ra các chi phí của sự phát triển. Trong những tình huống đó có thể đáng cân nhắc sự tạo ra một tổ chức phi lợi nhuận mà sẽ quản lý sự phát triển của phần mềm. Điều này có 2 tác dụng; trước hết nó cho phép nhiều chi phí về hạ tầng và điều hành được tổ chức phi lợi nhuận hấp thụ. Những chi phí đó được hỗ trợ từ đóng góp từ các công ty dùng làm vốn trong các sản phẩm được tổ chức phi lợi nhuận quản lý. Thứ 2, nó khuyến khích nhiều hơn các tổ chức tham gia vào dự án vì họ được đảm bảo rằng các đầu ra của dự án sẽ luôn có sẵn sàng cho họ và sẽ được quản lý theo những lợi ích của tất cả những người đóng góp. Đó là không có những lợi ích thương mại 'can thiệp' vào với chiến lược quản lý của dự án, không có bất kỳ các ghế 'bị mua nào' có khả năng kiểm soát sự phát triển.
Có lẽ ví dụ tốt nhất của tổ chức như vậy là Quỹ Phần mềm Apache - ASF, một tổ chức phi lợi nhuận mà chăm sóc các dự án như máy chủ web Apache (HTTPD) và nhiều dự án lớn dựa vào XML và Java. ASF được hỗ trợ tài chính bằng những đóng góp từ thiện từ các cá nhân và các công ty và đưa ra một hạ tầng cho các lập trình viên làm việc trong các dự án của Apache. Công việc được các cá nhân triển khai mà họ thường được các công ty có sử dụng mã nguồn của Apache thuê như một phần của những phát triển trong nội bộ hoặc đưa ra các phiên bản được tùy biến để bán.
Những ví dụ khác về các quỹ phi lợi nhuận bao gồm:
Ban liên hiệp (Consortia)
Khi một nhóm cốt lõi các tổ chức cộng tác trong một dự án nhất định thì họ có thể hình thành một ban liên hiệp để duy trì phần mềm đó. Điều này là tương tự với việc tạo ra một tổ chức phi lợi nhuận (xem ở trên). Sự khác biệt chính giữa một ban liên hiệp và một tổ chức phi lợi nhuận là các thành viên của ban liên hiệp có sự kiểm soát nhiều hơn đối với đường hướng của dự án so với những người đỡ đầu của một tổ chức phi lợi nhuận thường sẽ có. Trong trường hợp của một tổ chức phi lợi nhuận thì phần mềm đang được quản lý vì sự tốt lành của tất cả, còn trong trường hợp của một ban liên hiệp thì nó đang được quản lý vì sự tốt lành của các thành viên ban liên hiệp (và bất kỳ ai với cùng các lợi ích).
Một trong nhữn điểm mạnh của mô hình ban liên hiệp là ban liên hiệp có khả năng quản lý sát sao hơn đường hướng của dự án bằng việc chỉ định những các tài nguyên (thời gian và tiền bạc) được chi vào. Tuy nhiên, thực tế này có thể làm cho dự án ít cuốn hút hơn đối với những người không phải là một thành viên của nhóm cốt lõi. Điều này là đặc biệt quan trọng khi chúng ta xem xét rằng các lập trình viên của ngày mai là những người sử dụng của ngày hôm nay và vì thế những người sử dụng nên được khuyến khích tham gia từ giai đoạn đầu. Không may, mô hình ban liên hiệp thường làm cho những người sử dụng cảm thấy bị loại trừ vì họ không phải là những thành viên.
Thú vị để lưu ý rằng nhiều dự án bắt đầu với việc cấp vốn hạt giống thường bắt đầu cuộc sống như một nhà độc tài nhân từ (Bản dịch tiếng Việt) hoặc một ban liên hiệp nhưng sau đó phải chuyển đổi sang một số cấu trúc khác khi mà tiền hạt giống đã tiêu hết. Đầy là một sự chuyển đổi rất khó khăn để quản lý.
Dự án DSpace là một ví dụ về một dự án ban liên hiệp thành công trong giáo dục. Những ví dụ khác bao gồm Quỹ Sakai (Sakai Foundation) và Quỹ Kuali (Kuali Foundation). Tuy nhiên, DSpace và Sakai cả 2 đang chuyển sang một mô hình mở hơn.
Những đóng góp để hiện thực hóa sự giảm chi phí
Một tổ chức có thể chọn áp dụng một sản phẩm PMNM vì nhiều lý do. Trong một số trường hợp họ có thể đã làm thế để cho phép các qui trình mới sẽ được triển khai, để làm cho các qui trình đang tồn tại có hiệu quả hơn hoặc để giảm các chi phí cấp phép phần mềm. Việc đã áp dụng một sản phẩm PMNM, một tổ chức cũng có thể chọn đóng góp cho dự án nguồn mở đó để có được những lợi ích tiếp sau. Ví dụ, một tính năng mới có thể được bổ sung để hợp lý hóa tiếp tục các qui trình trong nội bộ, hoặc một lỗi có thể được sửa sao cho các nhân viên có thể vận hành có hiệu quả hơn.
Trong kịch bản này có 2 động lực chính để đóng góp trở ngược lại cho dự án. Trước hết, bằng việc đóng góp ngược lại thì tổ chức đang giúp đảm bảo rằng phần mềm mà họ dựa vào tiếp tục là hoạt động. Thứ 2, bằng việc đóng góp trở ngược lại họ đảm bảo rằng bất kỳ đường hướng nâng cấp nào trong tương lai cũng sẽ trơn tru như có thể, đó là họ sẽ không cần nhân bản những sửa đổi cục bộ y hệt đó sau khi nâng cấp.
Apache Wookie (đang ươm) đưa ra một triển khai của tiêu chuẩn widget của W3C và vì vào Apache Incubator nên dự án được xem như là có quan tâm đáng kể từ các lập trình viên của các bên thứ 3. Ví dụ khác là Hệ thống Quản trị Nội dung – CMS nguồn mở được phát triển để hỗ trợ cho các nhà chức trách địa phương của nước Anh phân phối các dịch vụ trực tuyến.
Giáo dục và việc cấp vốn nghiên cứu
Tại nước Anh, và trong nhiều phần còn lại của thế giới, các cơ sở giáo dục được khuyến khích (Bản dịch tiếng Việt) làm cho các kết quả đầu ra các phần mềm của họ là sẵn sàng theo một giấy phép nguồn mở. Việc cấp vốn cho các dự án nguồn mở trong các trường đại học và cao đẳng có thể tới từ các cơ quan cấp vốn hoặc từ bản thân các trường đại học/cao đẳng đó. Ở những nơi có lợi ích trực tiếp cho cơ sở đó, hoàn toàn có khả năng việc cấp vốn này sẽ tiếp tục, ít nhất là một phần, một cách vô hạn định.
Cơ sở có thể hưởng lợi theo một số cách thức. Có thể những lợi ích đáng kể nhất là chi phí nội bộ giảm và nhận thức về thương hiệu với sự tôn trọng những đóng góp cho cộng đồng giáo dục rộng lớn hơn. Một dự án như vậy là Exim từ Đại học Cambridge. Philip Hazel đã duy trì Exim từ ban đầu của nó trong năm 1995, vẫn còn trong sử dụng của Dịch vụ Điện toán của Đại học Cambridge cho tới khi ông về hưu năm 2007. Ví dụ khác về một dự án như vậy là MailScanner từ Đại học Southampton, ông chủ của Julian Fieldl, người là nhà độc tài nhân từ của dự án MailScanner.
Phát triển mở (Bản dịch tiếng Việt) là một phương pháp cộng tác được chứng minh cho các bên bằng những lợi ích và sự tinh thông đa dạng, đặc biệt khi phát triển phần mềm nguồn mở. Trong khu vực thương mại chúng ta đang thấy lợi ích phạm vi rộng trong khái niệm 'đổi mới mở' (Bản dịch tiếng Việt) như một biện pháp để phát triển các sản phẩm mới và đang tồn tại. Với việc lên kế hoạch và quản lý thận trọng, đổi mới mở cho phép một qui trình được kiểm soát và được quản lý trong đó sự khai thác thương mại hoặc xã hội các kết quả đầu ra được khuyến khích trong khi các đội dự án hàn lâm có thể giữ được tập trung vào các vấn đề bản địa hóa hơn là lên kế hoạch kinh doanh. Ví dụ Apache Wookie (đang được ươm) từng được Đại học Bolton phát triển và bây giờ đang lôi cuốn các lập trình viên từ giới hàn lâm bên ngoài.
Các nhà hảo tâm và các tổ chức cấp vốn khác
Vài cơ sở của các nhà hảo tâm là những người cấp vốn đáng kể của nguồn mở. Các ví dụ bao gồm:
Dù các tổ chức đó không có một cơ sở cung cấp giáo dục thì họ có những động lực tương tự như các cở sở giáo dục trong việc đảm bảo mã được làm sẵn sàng thông qua một giấy phép nguồn mở.
Những người tình nguyện
Có nhiều giá trị giáo dục, không nói cho vui, trong việc tham gia trong các dự án nguồn mở. Kết quả là không phổ biến để tìm được những người đóng góp cho nguồn mở trong thời gian rỗi. Trong khi một dự án sẽ không trở nên bền vững thông qua những đóng góp của chỉ những người tình nguyện (tất cả các dự án chịu các chi phí tài chính cũng như các chi phí về nhân lực), họ có thể có một tác động đáng kể nếu được quản lý và được tưởng thưởng đúng đắn. Nỗ lực của những người tình nguyện có thể được khai thác cùng với bất kỳ mô hình nào ở trên và có thể được thấy trong đa số các dự án nguồn mở.
Những người sử dụng (như những người tình nguyện) cũng là sống còn cho một dự án nguồn mở trong việc nâng cao các yêu cầu và kiểm thử. Miễn là bạn quản lý những kỳ vọng của những người sử dụng với bất kỳ phát hành nào được đưa ra, có khả năng để phát hành phần mềm nguồn mở ở các dạng beta hoặc những người áp dụng sớm cho việc kiểm thử mà có thể giảm đáng kể được các chi phí của bạn trước khi đưa ra một phát hành mới.
Tài liệu của OSS Watch Làm thế nào để xây dựng một cộng đồng nguồn mở (Bản dịch tiếng Việt) đưa ra một tổng quan thực tiễn trong việc xây dựng một cộng đồng bao gồm và đa dạng.
Sustainable open source is an open source project that supports itself. Simply put, the project is able to cover the costs it incurs, which can be significant even in a volunteer driven project. This document examines some of the models by which an open source project can become sustainable.
Reaching sustainability
To be sustainable a project must meet its own costs. Most projects have their initial costs covered by an injection of funding from a parent body or sponsor. However, what happens when this money runs out?
It is unlikely that the original funding stream will remain a viable option indefinitely. At some point either income must be generated or cost savings must be realised. A sustainable open source project is one in which this income or cost saving outstrips the cost of ongoing support and development.
The unfortunate reality of software development is that the vast majority of projects do not become sustainable. This is true of both open source and closed source development projects. In fact it is true of any activity that requires financial support to survive. The reality is that most new ideas fail to reach sustainability, whilst only a small handful succeed.
It is therefore important to ask why projects fail to reach sustainability. In some cases this is because the project fails to achieve what it set out to achieve. In these cases one would expect the project to be allowed to disappear. However, in a worryingly large number of cases the project does reach its initial objectives, yet still fails. This is especially true in funded development work in the HE and FE sector. This kind of failure is usually caused by a failure to plan for success. That is, there is no early plan as to how the project will sustain itself when the initial seed funding runs dry, and consequently no resources are assigned to reaching sustainability.
The conclusion is therefore obvious: to reach sustainability the project must make implementing a sustainability plan one of its initial objectives. It follows that the sustainability plan should be developed at a very early stage of the project’s life. However, in order to draw up this plan it is necessary to understand what options are available to you.
It is not possible to enumerate all sustainability options in this space, there are as many models as there are project ideas. However, the following sections outline some common sustainability models for open source software.
It should be recognised that very few projects fall squarely into one of these models. Most projects are sustainable because they draw on a different combination of factors from each model; similarly there is considerable overlap between models. The following sections are only intended to provide food for thought when you start working on your own sustainability plan. The intention is that they will enable you to approach advisors, such as OSS Watch with some understanding of the opportunities that lie before you.
Product development
A company that bases its business on open source products is no different from any other business. That is, it must invest some of its income in product development. There are four broad types of company able to commercially exploit open source software:
  • services companies who make software available as open source in order to to create as large a market as possible for their paid for products, such as support, training, customisation, search engines, eCommerce operations etc.
  • hardware companies who want to increase the potential market for their hardware, such as printer or mobile phone manufacturers
  • software companies who utilise open source components
  • software companies who have a dual licensing model and release an open source version of their product alongside a proprietary version of their product
A given company is not limited to any one of these activities; similarly, there can be more than one company involved in commercialising each open source software project.
For services and hardware companies the main profit line does not derive from selling the software itself. This makes it possible to release the software under an open source licence in order to benefit from contributions from third parties.
In the case of service based companies the motivations for open sourcing code are very similar. A company selling consultancy or customisation work wishes to ensure that their services are in the widest possible demand, so releasing a core product as open source is a way to seed the market. Furthermore, for companies providing services that are software driven, such as search engines, web 2.0 services or eCommerce operations there is good reason for the non-competitive parts of their software suite to be open source. This allows cost savings on initial and operational development as well as ongoing maintenance through shared development costs. For example, Amazon, IBM, Yahoo!, EBay, Facebook and many more companies use and contribute to the Apache HTTPD web server and GNU/Linux.
In the case of the hardware companies the drive towards open source may be to expand the market for their hardware or it may be to drive down costs of product development. For example, a printer manufacturer may open source their driver software in order to allow it to be customised for different platforms, thus the market to which they can sell the hardware is expanded. Another example is a mobile phone manufacturer who may opt to use open source software as the core operating system in order to share development costs of common functionality with other manufacturers.
Software companies who make their profits from selling software have two models available to them. However, each of these models is only available under certain open source licences. Those companies wishing to embed open source software within proprietary products can do so with the so called ‘permissive’ open source licences (commonly known as the BSD-style licences). Conversely, other companies adopt a dual licensing model for their software products by adopting a so-called ‘copyleft’ licence (such as the GPL) whilst also offering to sell the software under a proprietary licence.
Non-profit open development
In many cases software developed by an organisation is, in itself, not part of the revenue stream. In this case it can often be beneficial to release the code as open source in order to spread the costs of development. In these circumstances it may be worth considering the creation of a non-profit organisation that will manage the software development. This has two effects; firstly it allows many of the infrastructure and governance costs to be absorbed by the non-profit organisation. These costs are supported by contributions from those companies capitalising on the products managed by the non-profit organisation. Secondly, it encourages more organisations to participate in the project since they are assured that the project outputs will always be available to them and will be managed in the interests of all contributors. That is there are no commercial interests ‘interfering’ with project management strategy, nor are there any ‘bought’ seats able to control development.
Perhaps the best example of such an organisation is The Apache Software Foundation (ASF), a non-profit organisation that shepherds projects such as the Apache web server (HTTPD) and a great many XML and Java based projects. The ASF is supported financially by charitable contributions from individuals and companies and provides an infrastructure for developers working on Apache projects. The work is carried out by individuals who are often employed by companies using the Apache code as part of in-house developments or offering customised versions for sale.
Other examples of non-profit foundations include:
Consortia
When a core group of organisations collaborate on a given project they may form a consortium to maintain that software. This is similar to creating a non-profit organisation (see above). The key differentiator between a consortium and a non-profit organisation is that consortium members have more control over the direction of the project than sponsors of a non-profit organisation will typically have. In the case of a non-profit organisation the software is being managed for the good of all, in the case of a consortium it is being managed for the good of the consortium members (and anyone with aligned interests).
One of the strengths of the consortium model is that the consortium is able to more closely manage the direction of the project by dictating what the resources (time and money) are spent on. However, this very fact may make the project less attractive to those who are not a member of the core group. This is particularly important when we consider that tomorrow’s developers are today’s users and therefore users should be encouraged to participate from an early stage. Unfortunately, the consortium model often make users feel excluded because they are not members.
It is interesting to note that many projects that start with seed funding often start life as a benevolent dictatorship or a consortium but then have to migrate to some other structure as the seed money runs out. This is a very difficult migration to manage.
The DSpace project is an example of a successful consortium project within education. Other examples of consortia include Sakai Foundation and the Kuali Foundation. However, DSpace and Sakai are both moving towards a more open model.
Contributions to realize cost reduction
An organisation may choose to adopt an open source software product for many reasons. In some cases they may have done so in order to enable new processes to be implemented, to make existing processes more efficient or to reduce software licensing costs. Having adopted an open source software product an organisation may also choose to contribute to that open source project in order to gain further benefits. For example, a new feature may be added in order to further streamline internal processes, or a bug may be fixed so that the employees can operate more efficiently.
In this scenario there are two key incentives to contribute back to the project. Firstly, by contributing back the organisation is helping to ensure that the software they depend upon continues to be active. Secondly, by contributing back they ensure that any future upgrade path will be as smooth as possible, that is they will not need to replicate those same local modifications after upgrading.
Apache Wookie (incubating) provides an implementation of the W3C widget standard and since entering the Apache Incubator the project has seen significant interest from 3rd party developers. Another example is the APLAWS open source Content Management System developed to assist UK local authorities deliver services online.
Education and research funding
In the UK, and in much of the rest of the world, educational institutions are encouraged to make their software outputs available under an open source licence. Funding for open source projects within universities and colleges may come from funding bodies or from the university/college itself. Where there is a direct benefit to the institution, it is quite possible this funding will continue, at least in part, indefinitely.
The institution may benefit in a number of ways. Perhaps the most significant benefits are internal cost reductions and brand recognition with respect to contributions to the wider educational community. One such project is Exim from the University of Cambridge. Philip Hazel maintained Exim since its inception in 1995, remaining in the employ of the University of Cambridge’s Computing Service until his retirement in 2007. Another example of such a project is MailScanner from the University of Southampton, the employer of Julian Field who is the benevolent dictator of the MailScanner project.
Open development is a proven method of collaboration for parties with diverse interests and expertise, especially when developing open source software. In the commercial sector we are seeing large scale interest in the concept of ‘open innovation’ as a means to develop new and exciting products. With careful planning and management open innovation enables a controlled and managed process in which commercial or social exploitation of outputs is encouraged whilst the academic project teams can remain focused on the localised problem rather than business planning. For example Apache Wookie (incubating) was developed by the University of Bolton and is now attracting developers from outside academia.
Philanthropists and other funding organisations
Several philanthropic institutions are significant funders of open source. Examples include:
Although these organisations do not have an educational remit they have similar motivations to educational institutions in ensuring that code is made available via an open source licence.
Volunteers
There is a great deal of educational value, not to mention fun, in participating in open source projects. As a result it is not uncommon to find people contributing to open source in their spare time. Whilst a project will not become sustainable through volunteer contributions alone (all projects incur financial costs as well as human resource costs), they can have a significant impact if managed and rewarded correctly. Volunteer effort can be harnessed alongside any of the above models and can be found in the majority of open source projects.
Users (as volunteers) are also critical to an open source project with respect to raising requirements and testing. As long as you manage user expectations with any given release it is possible to release open source software in beta or early adopter forms for testing which can considerably reduce your costs before a stable release.
The OSS Watch document How to build an open source community provides a practical overview in building an inclusive and diverse community.
Dịch: Lê Trung Nghĩa
Người đăng: vào lúc
Nhãn:

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.

Đăng ký: Đăng Nhận xét (Atom)