Bạn có thể đóng góp mã nguồn cho một dự án nguồn mở?

Can you contribute code to an open source project?

By Randy Metcalfe, Published: 03 July 2006, Reviewed: 15 February 2012

Theo: http://www.oss-watch.ac.uk/resources/contributing

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

Lời người dịch: Khi bạn, dù là cá nhân hay là một tổ chức, ví dụ như một trường cao đẳng hay đại học, tham gia vào cộng đồng phát triển phần mềm nguồn mở của một dự án nguồn mở cụ thể nào đó, ví dụ Moodle chẳng hạn, thì bạn sẽ rất cần quan tâm tới việc những đóng góp mã có bản quyền của bạn sẽ được quản lý như thế nào trong dự án đó. Rất có thể bạn sẽ nên ký một thỏa thuận giấy phép của người đóng góp (bản dịch tiếng Việt) trước khi thực hiện việc đóng góp mã của mình vào dự án đó. Hơn nữa, thực tế cũng sẽ chỉ ra rằng, ngoài vấn đề đó ra, thì sự đóng góp cho dự án là đứng sau tính bền vững của dự án, mà trước hết để thực hiện được nó, bạn sẽ thấy cần phải chuyển sang một mô hình phát triển mở.

Vì bạn đã viết một số mã

Bạn đã viết một số mã cho một dự án mà bạn từng đôi lúc đi theo. Bạn đang tham gia trong danh sách thảo luận thư điện tử của những người sử dụng. Bạn từng âm thầm đi theo trong danh sách thảo luận thư điện tử của các lập trình viên. Bạn đã tải về mã nguồn được thấy trong kho được xây dựng vào ban đêm, và bạn đã viết bản vá đầu tiên của bạn cho một vài tính năng của mã mà bạn nghĩ cần vọc.

Phần mềm là một tác phẩm có bản quyền

Mã nguồn đối với các ứng dụng phần mềm là một tác phẩm có bản quyền. Bản quyền nảy sinh ngay khi các ý tưởng được đặt vào trong một số vật trung gian cố định, nó có thể là giấy hay điện tử. Không gì đặc biệt cần phải được thực hiện cho mã để được bảo vệ bằng bản quyền.

Những người nắm giữ bản quyền có quyền bố trí tư liệu bản quyền của họ theo ý của họ. Điều này bao gồm việc cấp phép nó để được sử dụng theo những cách thức khác nhau.

Các dự án phần mềm nguồn mở (PMNM) phát hành mã nguồn theo các giấy phép được OSI chứng thực. Để bản vá của bạn được sử dụng trong dự án, nó cũng có thể cần phải được cấp phép theo cùng giấy phép đó. Bạn có thể hoàn tất điều đó hoặc bằng các cách sau:

• kỹ về bản quyền trong mã cho dự án; hoặc
• cấp phép cho mã để sử dụng trong dự án theo một giấy phép phù hợp

Một số dự án khăng khăng chỉ định bản quyền. Điều đó nhất định làm cho mọi điều dễ dàng hơn cho họ sau này khi họ cần làm việc với các vấn đề về cấp phép. Đó chỉ là một trong một số khả năng.

Hầu hết các dự án chỉ yêu cầu rằng bạn cấp phép mã mà bạn muốn đóng góp theo một giấy phép tương thích với giấy phép của dự án.

Trong cả 2 trường hợp, ràng buộc y hệt áp dụng; chỉ người nắm giữ bản quyền có sức mạnh hoặc tái chí định quyền của họ hoặc cấp phép cho tư liệu bản quyền của họ.

Bạn có quyền cấp phép cho tư liệu bản quyền này không?

Bạn có phải là người nắm giữ bản quyền không?

Hầu hết các nhân viên trong thực tế không phải là những người nắm giữ bản quyền đối với tư liệu có bản quyền được sinh ra như một phần công việc của họ. Điều này sẽ khác từ cơ quan này tới cơ quan khác, và có thể giữa các vai trò công việc trong một cơ quan. Xin lưu ý: đã viết mã này ở nhà sẽ không, bản thân nó, chỉ ra rằng bạn nắm giữ bản quyền về nó; bạn vẫn cần kiểm tra các điều khoản làm việc của bạn.

Liệu bạn có là người nắm giữ bản quyền đối với tư liệu như vậy hay không nên được nói ra theo các điều khoản làm việc của bạn. Nếu bạn không thể thấy bất kỳ thứ gì ở đó, thì bạn có thể muốn kiểm tra bất kỳ chính sách nào của cơ quan, như một chính sách các Quyền Sở hữu Trí tuệ, nó được tham chiếu trong hợp đồng làm việc của bạn.

Bạn phải thiết lập xem ai là người nắm giữ bản quyền trước khi bạn đi bất kỳ đâu xa hơn (và lý tưởng trước khi bạn thậm chí có điều này xa hơn).

Trên thực tế bạn có phải là người nắm giữ bản quyền không?

Nếu bạn là người nắm giữ bản quyền

Nếu bạn trong thực tế là người nắm giữ bản quyền đối với tư liệu có bản quyền mà bạn đã tạo ra, thì xin chúc mừng! Bạn có thể làm gì bạn muốn với sở hữu trí tuệ của riêng bạn. Điều này bao gồm việc cấp phép nó để được sử dụng trong một dự án nguồn mở. Bạn có thể thậm chí muốn chỉ định bản quyền của bạn cho dự án theo yêu cầu, hoặc cho tổ chức bảo trợ (như Quỹ Phần mềm Tự do – FSF) mà đang đỡ đầu cho dự án.

Bạn thậm chí có quyền cấp phép đôi cho mã nguồn của bạn nếu bạn muốn. Điều này có thể xảy ra nếu bạn định cấp phép cho nó cho một người hoặc nhóm theo một giấy phép này và cấp phép nó cùng một lúc cho người khác hoặc nhóm khác theo một giấy phép khác. Điều này là có khả năng vì người nắm giữ bản quyền có thể làm bất kỳ điều gì mà họ muốn với từ liệu có bản quyền của họ.

Nếu bạn không phải là người nắm giữ bản quyền

Nếu bạn không phải là người nắm giữ bản quyền thì bạn phải có được sự đồng ý của người nắm giữ bản quyền đối với bất kỳ điều gì bạn muốn làm với tư liệu có bản quyền. Thường thì điều này được nói ra trong các điều khoản làm việc của bạn.

Để đóng góp bản vá của bạn cho dự án nguồn mở trong trường hợp ví dụ của chúng tôi, người nắm giữ bản quyền cần phải đồng ý rõ ràng cho sự đóng góp của bạn đối về sở hữu trí tuệ của nó. Hơn nữa, đáng lưu ý là điều này không có hiệu ứng nào lên bản thân bản quyền cả.

Mã được đóng góp cho các dự án nguồn mở thường giữ lại bản quyền của người nắm giữ bản quyền gốc ban đầu. Để đăng ký bản quyền tác giả của bạn cho cơ quan của bạn, một qui trình chính thống hơn nhiều có thể cần thiết để được bắt đầu. Thường thì điều này có liên quan tới các tài liệu pháp lý cần thiết phải được thay đổi, truyền bản quyền từ bên này sang bên khác. Điều này có thể là một qui trình phiền hà. Kết quả là nó rất hãn hữu trong thiết lập ở các trường cao đẳng và đại học.

Nhưng thậm chí nếu bản quyền không được tái chỉ định, thì sự đồng ý phải giành được trước khi mã có thể được đóng góp cho dự án. Hơn nữa, trong một dự án được quản lý tốt thì bạn sẽ được yêu cầu cung cấp sự đồng ý này ở dạng của một thỏa thuận giấy phép của người đóng góp (bản dịch tiếng Việt).

Làm thế nào bạn có được sự đồng ý của đại học và cao đẳng của bạn để đóng góp tư liệu có bản quyền của họ cho một dự án nguồn mở?

Đi đâu trước: lãnh đạo phòng của bạn

Hầu như chắc chắn con đường của bạn sẽ đưa bạn qua bất kể sự giám sát sở hữu trí tuệ nào đối với tổ chức của bạn. Ví dụ nếu bạn làm việc ở UK HE, có khả năng sẽ là các dịch vụ pháp lý, các dịch vụ nghiên cứu, và có khả năng là đơn vị chuyển giao công nghệ của cơ quan bạn. Nhưng nơi đầu tiên để bắt đầu là với lãnh đạo hoặc người đứng đầu phòng của bạn.

Nếu bạn may mắn, thì người quản lý của bạn hoặc người lãnh đạo phòng bạn sẽ từng được ủy quyền sức mạnh để quyết định những vấn đề như vậy. Có một ví dụ tốt về điều này xảy ra tại đơn vị các Dịch vụ Điện toán Đại học Oxford.

Nếu bạn không được may mắn cho lắm, thì người quản lý bạn hoặc người đứng đầu phòng của bạn có thể không có được ủy quyền này nhưng ít nhất sẽ biết tập các bước chính thức phải được thực hiện trong tổ chức của bạn để đạt được sự đồng ý của nó để đóng góp bản vá của bạn cho một dự án nguồn mở.

Điều này có thể sẽ có nghĩa là việc tiếp cận phòng các dịch vụ pháp lý tổ chức của bạn. Họ có thể thường cần một sự xác minh từ một vài đơn vị độc lập, như đơn vị chuyển giao công nghệ, như đối với giá trị có thể của sở hữu trí tuệ theo yêu cầu và bất kỳ trách nhiệm pháp lý nào mà cơ quan đó có thể chịu như là kết quả của sự phát hành này đối với IPR của nó.

Đáng tiếc là các bước có liên quan có thể là vô số, và hầu như không thể tránh khỏi là dị thường đối với tổ chức của bạn. Họ cũng không đảm bảo rằng sự đồng ý sẽ sớm đến.

Cách thức tốt hơn

Các tổ chức có suy nghĩ sớm nhận thức được rằng những đóng góp mã, dù ở dạng các bản vá hay thậm chí ở dạng các module đáng kể hơn, là một phần của những gì được đi theo bằng sự tham gia mang nặng tính cơ quan với nguồn mở. Nhưng làm thế nào họ tạo thuận lợi nhất cho qui trình này?

Ví dụ, khi Đại học Mở từng bắt tay vào lựa chọn Moodle như là môi trường học ảo (VLe) trong tương lai của mình, nó cũng đã thiết lập cách mà nó có thể tham gia với sự phát triển đang diễn ra của Moodle. Kết quả là một đầu tư đáng kể, nhưng có định lượng và bao hàm trong sự phát triển nguồn mở. Sự đóng góp của Đại học Mở về sở hữu trí tuệ của nó cho dự án Moodle không chỉ làm cho Moodle mạnh hơn. Nó đứng ra như một ví dụ về thực tiễn tốt trong sự cam kết của viện trường với cộng đồng nguồn mở.

Một ví dụ khác là cách mà Đại học Cambridge bắt đầu tham gia vào chương trình đối tác của Sakai. Trong những giai đoạn đầu của Sakai, trọng tâm chính là về việc tạo ra một khung hành chính cho nhóm các viện trường giáo dục có liên quan trong dự án. Mục tiêu chính là để đảm bảo rằng các phát hành phần mềm được sản xuất đúng thời điểm và tuân theo danh sách các ưu tiên được đồng thuận. Tuy nhiên trong một số dự án thí điểm của Sakai thì đã trở nên rõ ràng rằng sự đóng góp có điều phối của các viện trường cho sự phát triển mã chỉ là thứ yếu so với tính bền vững tổng thể của dự án. Cambridge và các đối tác khác đã hiểu được rằng việc xây dựng một cộng đồng xung quanh mã được chia sẻ thực sự là quan trọng hơn, và như là kết quả của những nỗ lực của họ theo đường hướng này, dự án đã chuyển sang một mô hình phát triển mở (bản dịch tiếng Việt) nhiều hơn.

Có những ví dụ khác về sự tham gia của các viện trường tương tự đang diễn ra trong các trường cao đẳng và đại học khắp nước Anh. Chúng tôi vui mừng để bổ sung ví dụ của bạn vào bài viết này. Xin hãy viết cho chúng tôi theo info@oss-watch.ac.uk và nói cho chúng tôi biết về điều đó.

So you’ve written some code

You’ve written some code for a project that you’ve been following for some time. You are participating on the users email discussion list. You have been quietly following the developers email discussion list. You have downloaded the source code found in the nightly build repository, and you have written your first patch for some feature of the code that you think needs tweaking.

Can you contribute this patch to the project?

Software is a copyright work

Source code for software applications is a copyright work. The copyright arises as soon as the ideas are placed in some fixed medium, which could be paper or electronic. Nothing special needs to be done for the code to be protected by copyright.

Copyright holders have the right to dispose of their copyright material as they see fit. This includes licensing it to be used in a variety of ways.

Open source software projects release their source code under OSI-certified licences. In order for your patch to be used in the project, it too would need to be licenseable under the same licence. You could accomplish that by either:

• signing over the copyright in the code to the project; or
• licensing the code for use in the project under an appropriate licence

Some projects insist upon the assignment of copyright. That certainly makes things easier for them later when they need to deal with licensing matters. That is just one of a number of possibilities.

Most projects merely require that you license the code you wish to contribute under a licence compatible with the project’s licence.

In either case, the same constraint applies: only the copyright holder has the power to either reassign their copyright or license their copyright material.

Do you have the right to license this copyright material?

Are you the copyright holder?

Most employees are not in fact the copyright holders for copyright material that is generated as part of their work. This will vary from institution to institution, and possibly between job roles within an institution. Please note: having written this code at home will not, by itself, indicate that you hold the copyright on it; you still need to check your terms of employment.

Whether you are the copyright holder for such material should be spelled out in your terms of employment. If you cannot find anything there, you may want to check any institutional policies, such as an Intellectual Property Rights policy, that are referenced by your employment contract.

You must establish who the copyright holder is before you go any further (and ideally before you’ve even got this far).

Are you in fact the copyright holder?

If you are the copyright holder

If you are in fact the copyright holder for the copyright material that you have generated, congratulations! You can do what you wish with your own intellectual property. This includes licensing it to be used in an open source project. You may even wish to assign your copyright to the project in question, or to the umbrella organisation (such as the Free Software Foundation) that is sponsoring the project.

You even have the right to dual license your code should you wish. This would occur if you were to license it to one person or group under one licence and license it at the same time to another person or group under a different licence. This is possible because the copyright holder can do anything they wish with their copyright material.

If you are not the copyright holder

If you are not the copyright holder then you must have the consent of the copyright holder for anything you wish to do with their copyright material. Often this is spelled out in your terms of employment.

In order to contribute your patch to the open source project in our example case, the copyright holder needs to explicitly consent to your contribution of its intellectual property. Moreover, it is worth noting that this has no effect upon the copyright itself.

Code contributed to open source projects often remains the copyright of the original copyright holder. In order to sign over your institution’s copyright, a much more formal process would need to be started. This usually involves legal documents needing to be exchanged, passing the copyright from one party to another. This can be an onerous process. As a result it is much more rare in the college and university setting.

But even if copyright is not being reassigned, consent must be obtained before the code can be contributed to the project. Furthermore, in a well managed project you will be required to provide this consent in the form of a contributor licence agreement.

How do you get the consent of your college or university to contribute their copyright material to an open source project?

Where to go first: the head of your department

Almost certainly your route is going to take you through whoever oversees intellectual property for your organisation. For example if you work in UK HE, that is likely to be legal services, research services, and possibly your institution’s technology transfer unit. But the first place to start is with your manager or department head.

If you are in luck, your manager or department head will have been delegated the power to decide such matters. There is a good example of this occurring at Oxford University Computing Services.

If you are slightly less lucky, your manager or department head may not have this delegated authority but at least will know the official set of steps that must be taken within your organisation in order to achieve its consent to contribute your patch to an open source project.

This will probably mean approaching your organisation’s legal services department. They would usually need a determination from some independent body, such as the technology transfer unit, as to the probable value of the intellectual property in question and any liability that the institution may be incurring as a result of this release of its IPR.

Regrettably the steps involved may be numerous, and are almost inevitably peculiar to your organisation. Nor do they guarantee that consent will be forthcoming.

A better way

Forward thinking institutions recognise that contributions of code, whether in the form of patches or even more substantial modules, are part of what is entailed by robust institutional engagement with open source. But how can they best facilitate this process?

For example, when the The Open University embarked upon the choice of Moodle as its future virtual learning environment (VLE), it also established how it would engage with Moodle’s ongoing development. The result is a substantial, but quantified and contained, investment in open source development. The Open University’s contribution of its intellectual property to the Moodle project doesn’t merely make Moodle stronger. It stands as an example of good practice in institutional engagement with the open source community.

Another example is the way University of Cambridge became involved in the Sakai partnership program. In the early stages of Sakai the main focus was on creating an administrative framework for the consortium of educational institutions involved in the project. The main aim was to ensure that the software releases were produced on time and according to an agreed list of priorities. However during a number of Sakai pilots it became evident that coordinating institutional contribution to the development of the code was only secondary to the overall sustainability of the project. Cambridge and other partners understood that building a community around the shared code was actually more important, and as a result of their efforts in this direction the project moved to a more open development model.

There are other examples of similar institutional engagement taking place in colleges and universities across the UK. We would love to add your example to this article. Please write to us at info@oss-watch.ac.uk and tell us about it.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Thành phố Munich khẳng định tính toán của mình: nguồn mở tiết kiệm hàng triệu

City of Munich stands by its calculation: open source saves millions

Submitted by Gijs Hillenius on February 14, 2013

Theo: https://joinup.ec.europa.eu/news/city-munich-stands-its-calculation-open-source-saves-millions

Bài được đưa lên Internet ngày: 14/02/2013

Thành phố Munich khẳng định những ước tính chi phí của mình trong tháng 11/2012, nó đã kết luận rằng việc sử dụng phần mềm tự do nguồn mở cho các máy để bàn và bộ phần mềm văn phòng cho 15.500 máy tính cá nhân là hơn 11 triệu euro là rẻ hơn, so với các lựa chọn thay thế sở hữu độc quyền có ở khắp nơi. “Không có lý do để chỉnh cho đúng thông tin này”, các bình luận của phòng CNTT thành phố hôm 11/02 yêu cầu nói điều ngược lại.

The City of Munich stands by its November 2012 cost estimates, which concluded that using free and open source software for desktops and office productivity for its 15,500 PCs is over 11 million euro cheaper, compared to the ubiquitous proprietary alternative. "There is no reason to correct this information", the city's IT department comments on 11 February to claims to the contrary.

Lời người dịch: Microsoft nói trong khảo sát không được làm cho công khai của mình rằng việc chuyển đổi các máy tính để bàn của thành phố Munich sang một giải pháp hoàn toàn nguồn mở, cả hệ điều hành và bộ phần mềm văn phòng, là tiêu tốn của thành phố nhiều triệu euro. Tuy nhiên, phòng CNTT của thành phố Munich đã khẳng định điều ngược lại, rằng thành phố tiết kiệm được 11 triệu euro sau khi chuyển đổi xong hơn 13.000 máy tính cá nhân trong tổng số 15.500 máy tính cá nhân của chính quyền thành phố. Đây là lần thứ 2 thành phố khẳng định như vậy và nêu ra những điểm sai lầm trong báo cáo tóm tắt mà hãng này đưa ra công khai vào cuối tháng 1 vừa qua. Xem thêm: Thành phố Munich bác bỏ tin đồn lan truyền về chi phí sử dụng nguồn mở.

Viết trên website của mình, phòng CNTT lần thứ 2 từ chối những yêu sách được một báo cáo của nhà cung cấp phần mềm sở hữu độc quyền thực hiện. Theo sau sự giận dữ trong báo chí thương mại về CNTT về những lưu ý của tác giả báo cáo không được công bố, cho rằng sự chuyển đổi đã tiêu tốn của thành phố nhiều triệu euro, hãng này vào cuối tháng 1 đã làm cho sẵn sàng một tổng kết.

Phòng CNTT từ chối những yêu sách của nhà cung cấp. “Chúng tôi đã vừa xem tóm tắt ngắn gọn, làm cho không có khả năng để so sánh. Đặc biệt trong lĩnh vực các chi phí thì báo cáo có chứa những giả thiết và tuyên bố của tác giả rằng, vì thiếu thông tin chi tiết, có thể không chứng minh được”.

Phòng CNTT của thành phố chỉ ra vài lỗi trong tóm tắt được xuất bản. Sự chuyển đổi sang phần mềm tự do đã không đòi hỏi 1.000 nhân viên CNTT, đó là tổng các nhân lực CNTT làm việc cho thành phố. Hãng đó cũng làm quấy quá các chi phí hỗ trợ CNTT, giả thiết không đúng rằng thành phố của Đức đã bắt đầu với 12.000 máy tính để bàn nguồn mở. “Số lượng các máy tính cá nhân nguồn mở đã tăng dần dần qua các năm, tới con số hiện hành là hơn 13.000”.

Ngược với các yêu sách của hãng, sử dụng nguồn mở làm giảm các chi phí cho phần cứng máy tính, phòng CNTT viết. Hãng đó cũng đã thất bại để phân biệt sự khác nhau giữa một sự chuyển đổi phần mềm và sự duy trì phần mềm thông thường, Munich viết. “Họ đánh giá những cập nhật thường xuyên của hệ điều hành như những sự chuyển đổi”.

“Thành phố đồng ý đánh giá của Giáo sư Tiến sĩ Helmut Krcmar của Đại học Công nghệ Munich, rằng nghiên cứu của các hàng 'trên cơ sở văn bản hiện hành... không được gọi là có khoa học được'”.

Writing on its web site, the IT department for the second time refutes claims made in a report for the vendor of the proprietary software. Following furore in the IT trade press over remarks by the author of the unpublished report, alleging that the switch had cost the city millions of euro, the firm in late January made available a summary.

The IT department rejects the vendor's claims. "We've only seen a brief summary, making impossible a sound comparison. Particularly in the area of ​​costs the report contains assumptions and statements by the author that, due to lack of detailed information, can not be verified."

The city's IT department points out several errors in the published summary. The migration to free software did not require a thousand IT workers, that is the total of IT staffers working for the city. The firm also fudged the IT support costs, assuming incorrectly that the German city started out with 12,000 open source desktops. "The number of open source PCs rose gradually over the years, to its current number of over 13,000."

Contrary to the firms claims, the use of open source reduces the costs for computer hardware, writes the IT department. The firm also failed to distinguish the difference between a software migration and normal software maintenance, Munich writes. "They evaluate regular updates of the operating system as migrations."

"The city agrees to the assessment by Prof. Dr. Helmut Krcmar of the Technical University of Munich, that the firms study 'on the basis of the present text ... can not be called scientific'".

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Người tài lãnh đạo, kẻ phá bĩnh và phương pháp phát triển mở: cuộc phỏng vấn với Justin Erenkrantz

Meritocrats, cluebats and the open development method: an interview with Justin Erenkrantz

By Paul Anderson, Intelligent Content, Published: 06 January 2009, Reviewed: 15 February 2012

Theo: http://www.oss-watch.ac.uk/resources/erenkrantz

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

Lời người dịch: Ngoài những đoạn hội thoại lòng thòng của tác giả với nhân vật chính, bài viết cho chúng ta biết những khái niệm cơ bản của 'nguồn mở' và 'phương pháp phát triển mở' và lịch sử đi lên của Quỹ Phần mềm Apache từ lúc bắt đầu cho tới sự thành công ngày nay. Một tham khảo rất tốt cho những ai quan tâm tới việc xây dựng các cộng đồng nguồn mở.

Nếu bạn đang đọc điều này trên Web thì thậm chí là tốt hơn có một cơ hội các trang được phân phối cho bạn có sử dụng máy chủ web Apache, một trong những dự án nguồn mở nổi tiếng nhất nền công nghiệp máy tính. Kể từ khi tái phát hành của nó từ tro tàn của công việc phát triển web trước đó tại Trung tâm Quốc gia về các Ứng dụng Siêu máy tính – NCSA (National Center for Supercomputer Applications) tại Illinois, Dự án Máy chủ HTTP của Apache (để đưa ra cái tên đầy đủ) đã thường xuyên định giờ cho các số liệu thị phần giữa 60%-70%và nó từ lâu được xem như là đầu cầu cho sự chấp nhận rộng rãi hơn của phần mềm nguồn mở (PMNM) trong các tập đoàn doanh nghiệp và các tổ chức nhà nước.

Tình trạng đáng kính đó có nghĩa là những ai có liên quan tới sự phát triển mã nguồn của Apache và quỹ phi lợi nhuận đó mà bây giờ giám sát nó được nằm trong sự tôn trọng cao. Có lẽ không nhiều hơn so với Justin Erenkrantz, chủ tịch của Quỹ Phần mềm Apache. Mặc dù sự thoải mái, kiểu cá nhân của người ở Nam California, Erenkrantz thật bận rộn như một trong những người của các máy chủ siêu thông hơi nhất của Quỹ, xoay xở để kết hợp các nhiệm vụ tự nguyện của Quỹ với công việc như một nhà thiết kế phần mềm tại công ty khởi nghiệp về TV trực tuyến của châu Âu Jooost, và làm Tiến sĩ khoa học tại Đại học California, Irvine (UCI), cộng với một sự trợ giúp nhỏ cho sự phát triển nguồn mở tại Google. Như ông âm thầm nói bớt đi: 'Tôi có một vài cái mũ khác nhau'.

Bất chấp nhịp độ điên rồ này (ông đã bay tới châu Âu 12 lần vào năm ngoái) ông vẫn tìm được thời gian để tới Oxford và giúp OSS Watch với một dự án giám sát giáo dục. Trong khi ông ở đó, tôi đã vồ được ông cho một cuộc phỏng vấn 1-1 về Apache và tầm quan trọng của phương pháp phát triển cộng đồng mở của nó.

Tất cả đã bắt đầu từ cuối những năm 2000, khi Justin kết thúc các nghiên cứu của học sinh chưa tốt nghiệp đại học tại Đại học California, Irvine, một cao đẳng với một nền tảng mạnh trong nghiên cứu phần mềm liên quan tới Internet. Justin nói: 'Tôi đã đi qua một ông gọi là Roy Fielding. Roy từng hoàn thành luận án Tiến sĩ của ông ta tại UCI và ông ta đã vừa mới bắt đầu làm việc cho một công ty gọi là e-Build'. Chúng tôi giữ liên hệ với nhau. Tôi đã bắt đầu làm việc cho các khách hàng khác nhau và Roy từng là một trong những lãnh đạo kỹ thuật và nói: “Ô, chúng ta sẽ làm một module của Apache”. Và điều này từng là sự giới thiệu chính thức của tôi cho máy chủ web Apache. Nó từng là sự kết thúc của qui trình phát triển của phiên bản v2.0 - nó vẫn làm việc nhưng đã không được trơn tru cho lắm. Justin đã tham gia vào việc viết các bản vá cho máy chủ, làm việc với các danh sách thư có liên quan và tương tác với các lập trình viên chủ chốt của Apache. Điều này đã phục vụ như là sự giới thiệu của ông cho cộng đồng phát triển và đã dẫn dắt tới một cam kết sâu đậm hơn, và, cuối cùng, cho vị trí hiện hành của ông.

Phương pháp phát triển mở

Quỹ Phần mềm Apache - ASF (Apache Software Foundation) là một tổ chức bảo trợ và hỗ trợ cho Dự án Máy chủ HTTP và một số lượng ngày một gia tăng các dự án phát triển nguồn mở khác. Nó vận hành thông qua một số Ủy ban Quản lý Dự án – PMC (Project Management Committees), mỗi ủy ban quản lý các dự án hiện đang được phát triển. Cuối cùng thì mỗi PMC báo cáo cho Ban quản trị, nó triển khai sự quản lý và giám sát chung và chịu trách nhiệm về tư cách thành viên và cộng đồng rộng lớn hơn của ASF như là một tổng thể. Cấu trúc của ASF được thiết kế để càng mở có thể càng tốt, với khá nhiều mọi thứ đi ra công khai, và manh mối cho sự hiểu biết vì sao điều rất quan trọng này nằm trong lịch sử cách mà ASF ra đời.

Gốc gác của ASF, sản phẩm lá cờ đầu là máy chủ web, một mẩu phần mềm điều khiển sự tương tác giữa một trình duyệt máy trạm và máy chủ có lưu trữ các trang web. Mã nguồn của Apache dựa vào công việc gốc từng được thực hiện trên một daemon HTTPd dựa vào Unix từng được Rob McCool phát triển vào giữa những năm 1993-1994 tại NCSA. Điều này là trong những ngày khó khăn ban đầu của web, và McCool đã sớm ra để lại công việc với Netscape mới được thành lập. Điều này có nghĩa là máy chủ web từng được để lại không có sự hỗ trợ cho tới khi một nhóm những người sử dụng có quan tâm, bao gồm cả Brian Behlendorf và Roy Fielding đã bắt đầu chính thức chia sẻ các vấn đề và sửa các lỗi bằng thư điện tử. Justin nói: 'Họ đã bắt đầu trao đổi các bản vá và mọi thứ. Một cách độc lập tất cả những người này đã cố duy trì dạng quả bóng bùn này, Vì thế họ nói hãy làm việc cùng nhau sao cho chúng ta có thể làm thứ gì đó tốt hơn so với từng người một trong chúng ta có thể tự làm'. Những sửa đổi của họ từng được biết tới như 'các bản vá' và từng được chơi chữ thành 'apache' khi nhóm liền thành một cấu trúc chính thức hơn.

Vì thế động lực cho cách thức làm việc này đã tới, một phần, từ hoàn cảnh của sự khởi đầu của tổ chức. Justin nhớ lại: 'Nếu bạn nhìn vào cách mà nó đã bắt đầu thì bạn đã có 8 người đã đóng góp mã nguồn vì những người từng duy trì nó đã đi khỏi. Họ từng là dạng có động lực không thấy điều này xảy ra một lần nữa. Đây chính là sức mạnh của nguồn mở'.

Nhưng nó không phải chỉ là nguồn mở, mà còn là một phương pháp phát triển mở đã giúp cho sự thành công của dự án. Các quyết định đã và tiếp tục được thực hiện công khai và được xem là rất quan trọng mà các dự án và các PMC của chúng, những người có trách nhiệm cho những hành động của riêng họ, nên tiếp tục truyền thống này. Justin lưu ý rằng: 'Apache là sự phát triển mở. Chúng tôi rất hăng hái về điều đó, chắn chắn điều đó là nhất quán xuyên khắp tất cả các dự án của Apache'. Mặc dù nó không thường xảy ra thì Justin cam kết rằng: 'Mỗi một lần trong một thời gian một trong các dự án bắt đầu làm những việc theo sự riêng tư và chúng tôi giống như nói “Ôi không không không!” Và chúng tôi tới đó với kẻ phá bĩnh [và nói] không, bạn sẽ phải làm mọi thứ công khai và chúng tôi sẽ không chống lại vì điều đó!'.

Nguồn mở so với sự phát triển mở

Justin tin tưởng sự phát triển mở là quan trọng sống còn cho thành công lâu dài và lưu ý rằng 2 'vị ngon' của nguồn mở đang nổi lên. Ông nói: 'Chúng tôi đang thấy sự khác biệt giữa nguồn mở và phát triển mở. Vì thế những gì chúng tôi đang thấy là một số dự án và thực thể, những người đang nói đây là mã nguồn, thì nó là theo giấy phép Apache hoặc GPL hoặc bất kể thứ gì ngoại trừ những quyết định về cách mà mã nguồn mà trạng thái là đằng sau một số bức tường - nó không là công khai'. Điều này có nghĩa là một lập trình viên có tất cả các quyền cần thiết để soạn thảo, sửa đổi và phân phối lại mã nguồn, nhưng không có bất kỳ sự hiểu biết thực tế nào bằng cách nào và vì sao mã nguồn được phát triển theo cách đó ngay từ đầu. Justin nói: 'Vì thế bạn bạn gặp một số lỗi và bạn đang nói vì sao mã nguồn lại theo cách này? Không có ngữ cảnh lịch sử hay việc lưu trữ hay lý do cơ bản... Vì thế, [với phương pháp phát triển mở] những gì chúng ta đang thấy là, điều bổ sung thêm cho “đây là mã nguồn” chúng ta đang thấy “đây là tất cả các quyết định đang được làm công khai”'.

Sức mạnh khác của phương pháp phát triển mở là cách như doanh nghiệp mà ASF phát triển phần mềm và các qui trình rà soát lại ngang hàng đang diễn ra. Như Justin lưu ý, 'Chúng tôi thấy ở đây với sự thành lập của ASF, tất cả công việc được thực hiện trong một cách thức mở, mọi thứ được rà soát lại ngang hành và điều này đã dẫn tới chất lượng rất cao'. Sự tập trung này vào công việc của lập trình viên và nhu cầu thực hiện tới các tiêu chuẩn cao nhất, một cách công khai, được phản ánh trong cấu trúc của tổ chức.

Ngay giai đoạn đầu tiên cho một lập trình viên trong mô hình phát triển của Apache sẽ là một 'Người sử dụng' đơn giản - sử dụng các phần mềm và đưa ra các phản hồi, các báo cáo lỗi và các ý tưởng. Sự tiến hóa sang giai đoạn tiếp sau là bằng việc chứng minh giá trị của bạn và có được sự tham gia nhiều hơn trong qui trình phát triển đó. Justin mô tả nó như là: 'Việc chứng minh qua thời gian. Có khả năng để nói bạn có thể làm việc với cộng đồng, bạn có thể giử vào các bản vá, bạn có thể bổ sung tài liệu hoặc bất kỳ thứ gì có'. Mọi người ở mức này được biết như là 'các lập trình viên' và họ có thể gợi ý những sửa đổi cho mã nguồn. Tuy nhiên, họ không thể sửa trực tiếp mã nguồn của lõi trong kho phần mềm, một công việc mà được phân bổ cho những người với kinh nghiệm nhiều hơn, họ được biết như những 'người đề xuất' (committer). Cuối cùng, sau khi được những người khác bầu chọn, bạn có thể trở thành một 'thành viên'. Điều này kéo theo việc trở thành một 'cổ đông' của quỹ từ thiện ASF phi lợi nhuận và có các quyền biểu quyết về các thành viên mới và Ban Giám đốc.

Như một cách thức cung cấp một số ý tưởng về phạm vi của tổ chức, Justin nói: 'Có khoảng 260 thành viên của Quỹ và 1.700 người đề xuất mà họ có thể đóng góp trực tiếp cho một số phần của kho mã nguồn. Nếu những người đó gắn với nó thì sau đó tại thời điểm nào đó họ sẽ trở thành các thành viên'.

Lòng tin, tài năng và lao động cật lực là những nét cốt lõi của Apache và website của ASF gần đây từng tái gắn nhãn với khẩu hiệu Chế độ nhân tài trong Hành động (Meritocracy in Action). Trong thực tế, khái niệm 'chế độ nhân tài' ban đầu được nhà lý thuyết xã hội học người Anh là Michael Young đưa ra trong cuốn sách nổi tiếng, Sự nổi lên của chế độ nhân tài (The Rise of the Meritocracy). Tầm nhìn của ông về một xã hội dựa thuần túy vào giá trị từng thực sự là một cảnh báo đen tối. Khi tôi chỉ ra điều này, Justin cười to và nói: 'Tôi tin vào Roy Fielding, người từng là một trong những chủ tịch đầu tiên của Apache, có một nền tảng trong khoa học xã hội và sắc sảo nhận thức được về điều đó. 'Justin viện lý rằng khái niệm đó tóm tắt gọn gàng toàn bộ tiếp cận của họ, nói: 'Thực sự đây là một đại diện tốt và về cơ bản nói”Nếu bạn muốn làm thứ gì đó và bạn đã trình bày cho cộng đồng mà bạn tin tưởng và bạn có được giá trị đó thì bạn sẽ cố gắng và trao cho bạn môi trường để bản làm những điều mà bạn muốn làm”'.

Nguồn mở thực dụng

Sự khác biệt khác giữa nguồn mở và phát triển mở tới khi Justin nói về phần mềm sở hữu độc quyền. Điều này động chạm tới xương cốt được tranh luận gay gắt về sự bất hòa giữa 'tự do' (như được minh họa từ Richard Stallman và Quỹ Phần mềm Tự do, hoặc FSF) và phong trào phần mềm nguồn 'mở', và bản thân tuyên ngôn trong các tiếp cận khác nhau được đưa ra cho sự phát triển mã nguồn.

Ví dụ, FSF hoàn toàn rõ ràng rằng phần mềm 'tự do' tôn trọng sự tự do của một người sử dụng cá nhân. Một chương trình chỉ có thể được phân loại như phần mềm tự do nếu giấy phép của nó đưa ra cho người sử dụng với 4 quyền tự do cơ bản: tự do chạy chương trình khi họ muốn; tự do nghiên cứu cách chương trình làm việc và tùy biến nó; tự do phân phối lại các bản sao; tự do cải tiến chương trình và phân phối lại các cải tiến cho công chúng. Tuy nhiên, giấy phép Apache License Version 2.0 làm nó rõ rằng mã nguồn có thể được sửa đổi và sau đó được kết hợp vào một sản phẩm sở hữu độc quyền. Điều này có nghĩa là trong khi mã nguồn được cấp phép Apache đủ phẩm chất như là phần mềm tự do, thì các sản phẩm được xây dựng có sử dụng mã nguồn đó có thể không phải là phần mềm tự do.

Justin viện lý rằng điều này đơn giản là thực dụng và phản ánh những gì các lập trình viên muốn, và nói: 'Phần lớn bạn sẽ thấy rằng các dự án của Apache có xu hướng sẽ được tập trung vào các lập trình viên. Các lập trình viên đó ban đầu là khán thính phòng đích của chúng tôi. Một trong những điều với quan điểm của Richard Stallman là ông muốn những người sử dụng sẽ được tự do. Thái độ của chúng tôi trong Apache là chúng tôi đang tìm kiếm các lập trình viên sẽ có sự tự do. Họ đang nói: “Bạn biết không, nếu bạn muốn biến điều này thành một thứ nguồn đóng hoặc nếu bạn muốn làm cho nó thành một thứ nguồn mở thì điều đó là tốt thôi”'. Và ông bổ sung: 'Chúng tôi thực sự không nhất thiết quan tâm làm thế nào và ở đâu bạn sử dụng nó, miễn là bạn tuân thủ giấy phép của chúng tôi, rằng bạn trao cho chúng tôi lòng tin, …Nhưng chúng tôi không nhất thiết sẽ nói “này bạn phải sử dụng nó trong một sản phẩm tự do và nguồn mở”'.

Một số khác biệt tập trung xung quanh vai trò của các bằng sáng chế phần mềm, một vấn đề vẫn còn gây tranh cãi trong giới công nghiệp phần mềm. Justin nói rằng 'FSF nói “chúng tôi thậm chí không nói về các bằng sáng chế”. Apache License Version 2.0 có dạng tập hợp tiêu chuẩn theo nhiều cách thức cho cách mà bạn nghĩ về bảo vệ bằng sáng chế và dạng những thứ đó. Quan điểm của chúng tôi là các bằng sáng chế đang có ở đây và chúng tôi phải làm việc với chúng và chúng tôi phải thực dụng. Nó là thứ gì đó mà một số các giấy phép khác đã làm, nhưng tôi nghĩ rằng khi mà một quỹ nguồn mở lớn [có quan tâm] thì chúng tôi từng có hiểu biết sâu sắc bằng việc nói rằng chúng tôi sẽ đối phó được với điều này'.

Cũng từng có nhiều thảo luận trong cộng đồng phát triển phần mềm về việc gia tăng sử dụng các dịch vụ phần mềm dạng Web 2.0, còn được biết tới như là Phần mềm như một dịch vụ (SaaS) hoặc 'Đám mây dịch vụ'. FSF đã trả lời cho các quan ngại về cách mà một người đi xung quanh việc cấp phép mã nguồn mở khi nó đang chạy trong một máy chủ ở xa và cung cấp một dịch vụ thông qua một máy trạm có trình duyệt, bằng cách làm việc về một giấy phép mới, gọi là Affero.

Justin liên kết điều này với các cách thức khác trong đó ASF và FSF xem xét sự phân phối: 'Nó nằm trong câu hỏi “sự phân phối là gì”. Thách thức là: liệu tôi có trao cho bạn phần mềm bằng việc phơi nó ra trên một website hay không? Và ngoại lệ của Affero, hoặc dù nó có câu cho tới nay... [nói rằng] đặt nó lên một website là việc phân phối và vì thế bạn cần trao nguồn'. Điều này nhất định là cách mà Richard Stallman nhìn nó, nhưng Justin nói: 'Điều đó thường không có xu thế sẽ là cách mà hầu hết mọi người nhìn nhận sự phân phối. Họ có dạng nhận thức, “Ồ tôi đang chạy mã nguồn trên Google Docs nhưng nó không nhất thiết có nghĩa là tôi nhận được phần mềm, tôi chỉ sử dụng nó”'. Apache vì thế không có các kế hoạch làm việc trong một giấy phép dạng Affero.

Nguồn mở trong giáo dục

Sự thực dụng như vậy cũng tuyên ngôn cho bản thân nó trong quan điểm của Justin đối với vai trò của PMNM trong các cơ sở giáo dục như các trường học và cao đẳng. Ngược lại với Stallman, người tin tưởng các trường học và cao đẳng nên chống lại việc sử dụng phần mềm sở hữu độc quyền, Justin nói: 'Các trường học nên sử dụng phần mềm phù hợp cho nhiệm vụ. Hy vọng của chúng tôi, mong muốn của chúng tôi, là nguồn mở phù hợp các mục tiêu đó nhưng có thể không phải là trường hợp như vậy'. Justin cảm thấy rằng điều quan trọng hơn là các trường học và cao đẳng thể hiện cho các sinh viên một dải rộng lớn các hệ thống khác nhau, cả đóng và mở, nói: 'Một trong những điều về đại học là nó được cho là mở ra cho mọi người tới các ý tưởng khác nhau. Nó không nên chỉ là làm cái hộp cho chim bồ câu nên nó nói, “Ồ mọi người ở đây sẽ sử dụng Microsoft” và nó trở thành mặc định. Mở ra cho sinh viên tới những lựa chọn thay thế. Hãy nghĩ tới bên ngoài cái hộp'.

Tương lai

Cuối cùng, chúng tôi hướng tới tương lai và nơi kế tiếp cho Apache, Justin phác thảo công việc của vườn ươm Apache (Apache incubator), một qui trình chính thức cho việc thiết lập và kết hợp các ý tưởng và dự án mới. Ông xem công việc này là rất quan trọng cho sự phát triển dài hạn của Quỹ và một ví dụ về khái niệm phát triển cộng đồng là quan trọng thế nào. Ông nói: 'Chúng tôi gọi điều đó [các dự án phôi thai], và sau một thời gian họ tốt nghiệp và làm nở và trở thành các dự án hàng đầu. Có 20-30 dự án xếp hàng. Chúng có thể không phải tất cả đều thành công, chúng có thể không phải tất cả đều lôi cuốn được cộng đồng, nhưng điều này là cách mà các dự án tới Apache'.

Và luận án Tiến sĩ của ông là gì? Ông viện lý rằng công việc nghiên cứu là phù hợp cho sự phát triển dài hạn của Apache về web khi ông đang xem xét các mô hình theo khái niệm mà có thể mô tả cách thức các thực thể khác nhau (máy trạm, máy chủ...) giao tiếp và tương tác trên web. Ông đang được Giáo sư Richard Taylor dẫn dất (Giám đốc Viện Nghiên cứu Phần mềm), người cũng đã dẫn dắt luận án tiến sĩ nổi tiếng của Roy Fielding, lần đầu tiên đã trình bày kiểu kiến trúc Truyền Trạng thái Đại diện (còn được biết như là REST). Điều này tập trung vào việc mô tả, theo cách thức chính thống, cách thức trong đó tài liệu dựa trên web phân phối các công việc thông qua qui trình của HTTP và URIs.

Tuy nhiên, web ngày nay có một sự thừa thãi các công nghệ đang nổi lên và sử dụng những gì có thể được mô tả như là các cách thức làm việc tính toán nhiều hơn, liên quan tới các script như AJAX, Web 2.0, mashup dữ liệu và các dịch vụ web. Những gì Justin đang làm việc là thứ gì đó ông gọi là CREST - REST tính toán - nó liên quan tới sự tới với các cách thức mới của việc mô tả một cách chính thức cách thức làm việc mới này trên web mà sẽ mở rộng phạm vi được. Theo Justin: 'Dạng của REST được nói tới này là những gì web đang có. Nó từng có từ 10 năm nay và điều này sẽ nói những gì web sẽ tới trong 10 năm tới'.

Trên tất cả, đây là một sự pha trộn và Justin thừa nhận ông rất bận rộn. Việc hướng dẫn và phát triển các cộng đồng phần mềm là một nhiệm vụ mất thời gian và ông lưu ý: 'Khi Quỹ Apache đã phát triển từ 5 hoặc 6 dự án lên thành 70 dự án hàng đầu hoặc tương tự, thì việc quản lý nó mất nhiều nỗ lực'. Một trong những ưu thế của hệ thống người tài của Apache là có nhiều người tài đẻ thiết kế và Justin thừa nhận rằng ông gần đây đã biết ơn vì những chào mời giúp đại diện cho một số vai trò của ông. 'Nó thực sự là về việc sử dụng năng lượng', ông nói.

Cuối ngày, dù, những gì tiếp tục dẫn dắt ông là cách mà ở đó các ý tưởng về cách thức mà web nên làm việc có thể được kết hợp, với tốc độ tốt, trong mã nguồn của Apache và tương tự được làm cho sẵn sàng cho khoảng 60%-70% các máy chủ web. Để quay lại điều này ông nhớ tới một câu chuyện khôi hài về bằng tiến sĩ của Roy Fielding, trong đó ứng viên từng được hỏi làm thế nào ông biết rằng đồ của ông đã làm việc. Câu trả lời quay về: 'The World Wide Web'. Các giám khảo đã nghĩ một lúc và sau đó trả lời: 'OK, chúng tôi chấp nhận điều đó'. Đối với Justin, việc tiếp tục cố thử vượt qua những phương pháp mà sẽ điều khiển dạng mở rộng phạm vi này là một thách thức giữ cho ông tiến lên. Như ông nói: 'Đây là khía cạnh hay trong sự liên quan của tôi với nguồn mở'.

If you are reading this on the Web then there is a better than evens chance that the pages were delivered to you using an Apache web server, one of the computer industry’s most famous open source projects. Since its re-launch from the ashes of earlier web development work at the National Center for Supercomputer Applications (NCSA) in Illinois, the Apache HTTP Server Project (to give it its full name) has regularly clocked up market share figures in the order of between 60% and 70% and it has long been regarded as a bridge head for the wider acceptance of open source software within corporate businesses and public organisations.

This venerable status means that those associated with Apache code development and the not-for-profit foundation that now oversees it are held in high regard. Perhaps none more so than Justin Erenkrantz, who is the Apache Software Foundation’s president1. Despite a laid-back, southern Californian personal style, Erenkrantz is as busy as one of the Foundation’s most hyperventilating servers, managing to combine his voluntary Foundation duties with work as a software designer at European online TV start-up Joost, and undertaking a PhD at the University of California, Irvine (UCI), plus a stint helping open source development at Google. As he quietly understates: ‘I have a number of different hats.’

Despite this frantic pace (he flew to Europe twelve times last year) he still found time to come to Oxford and help OSS Watch with an educational mentoring project. While he was here I caught up with him for a one-to-one interview on Apache and the importance of its open community development method.

It all began back in late 2000, when Justin was finishing his undergraduate studies at the University of California, Irvine, a college with a strong background in Internet-related software research. Justin says: ‘I ran across a guy called Roy Fielding. Roy was completing his PhD at UCI and he had just started working for a company called e-Built. We kept in touch. I kind of got started working for different clients and Roy was one of the technical leaders and said: “Oh we are going to do an Apache module.” And this was my formal introduction to the Apache web server. It was [the] tail-end of the Version 2.0 development process—it kind of worked but didn’t have that coat of polish.’ Justin got involved in writing patches for the server, working the associated mailing-lists and interacting with the key Apache developers. This served as his introduction to the development community and led to a deeper commitment, and, eventually, to his current position.

The open development method

The Apache Software Foundation (ASF) is an umbrella organisation that supports the HTTP Server Project and a growing number of other open source development projects. It operates through a number of Project Management Committees (PMC), each of which manages the projects that are currently in development. Ultimately each PMC reports to the Board, which carries out general management and oversight and is answerable to the membership and the wider ASF community as a whole. The ASF’s structure is designed to be as open as it possibly can be, with pretty much everything going on in public, and the clue to understanding why this is so important lies in the history of how the ASF came about.

The ASF’s original, flagship product is the web server, a piece of software that handles the interaction between a client’s browser and the server that stores the webpages. The Apache code is based on original work that was undertaken on a Unix-based HTTPd daemon which was developed by Rob McCool between 1993 and 1994 at the NCSA. This was during the heady days of the early web, and McCool soon left to work with the newly founded Netscape. This meant that the web server was left unsupported until a group of concerned users including Brian Behlendorf and Roy Fielding began to informally share problems and fix bugs by e-mail. Justin says: ‘They started trading patches and stuff. Independently all these guys were trying to maintain this kind of ball of mud. So they said let’s work together so that we can make something better than each one of us individually could make on our own’. Their modifications were known as ‘patches’ and was punned to ‘apache’ as the group coalesced into a more formal structure.

So the motivation for this way of working came, in part, from the circumstances of the organisation’s inception. Justin recalls: ‘If you look at how it started you had these eight guys who had the code dropped in their lap because the guys who were maintaining it had walked away. They were kind of motivated to not see this happen again. This was the strength of open source.’

But it was not only open source, but also an open development method that helped with the success of the project. Decisions were and continue to be made in public and it is seen as very important that projects and their PMCs, who are responsible for their own actions, should continue this tradition. Justin notes that: ‘Apache is open development. We are very aggressive on that, making sure it is consistent across all the Apache projects.’ Although it doesn’t happen very often Justin admits that: ‘every once in a while one of the projects starts to do things in private and we are like “Oh no no no!” And we kind of go in there with the cluebat2 [and say] no, you’re going to do everything in public and we will not stand for this!’

Open source versus open development

Justin believes open development is crucially important for long-term success and notes that two ‘flavours’ of open source are emerging. He says: ‘We are seeing a difference between open source and open development. So what we are seeing is some projects and entities who are saying here is the source code, it is under Apache licence or GPL or whatever but the decisions about how the code got to that state are behind some wall—it is not in public’. This means that a developer has all the requisite rights to edit, modify and redistribute the code, but doesn’t have any real understanding as to how or why the code developed that way in the first place. Justin says: ‘So you run into some bug and you are saying why is the code this way? There is no historical context or archiving or rationale…So, [with the open development method] what we are seeing is, that in addition to “here is the code” we are seeing “here are all the decisions being made in public”.’

The other strength of the open development method is the business-like way the ASF develops software and the peer review processes that are in place. As Justin notes, ‘We see here with the establishment of the ASF, all the work [is] done in the open, everything is peer-reviewed and this [has] led to very high quality’. This focus on the work of the developer and the need to perform to the very highest standards, in public, is reflected in the structure of the organisation.

The very first stage for a developer in the Apache development model is to be a simple ‘User’—making use of the software and offering feedback, bug reports and ideas. Evolution to the next stage is by proving your worth and getting more involved in the development process. Justin describes it as: ‘Proving over time. Being able to say you can work with the community, you can send in patches, you can add to the documentation or whatever it is.’ People at this level are known as ‘developers’ and they can suggest modifications to the code. They cannot, however, directly edit the core code in the software repository, a job that is allocated to those with more experience who are known as ‘committers’. Finally, after having been elected by others, you can become a ‘member’. This entails becoming a ‘shareholder’ of the not-for-profit ASF charitable foundation and acquiring voting rights on new members and the Board of Directors.

As a way of providing some idea of the scale of the organisation Justin says: ‘There are around 260 or so members of the Foundation and 1,700 committers who can contribute directly to some part of the code base3. If these guys stick with it then at some point they will become members.’

Loyalty, talent and sheer hard work are core Apache traits and the ASF website was recently retagged with the slogan Meritocracy in Action. In actual fact, the term ‘meritocracy’ was originally coined by British social theorist Michael Young in a famous book, The Rise of the Meritocracy. His vision of a society based purely on merit was actually a dystopian warning. When I point this out, Justin laughs loudly and says: ‘I believe Roy Fielding, who was one of the first chairs of Apache, has a background in social science and was keenly aware of that.’ Justin argues that the term neatly sums up their overall approach, saying: ‘Actually it is a good representative and [is] basically saying “If you want to do something and you have demonstrated to the community that you are trustworthy and you have this merit then we will try and give you the environment to let you do the things you want to do”.’

Pragmatic open source

Another distinction between open source and open development comes to light when Justin talks about proprietary software. This touches on a hotly debated bone of contention between the ‘free’ (as exemplified by Richard Stallman and the Free Software Foundation, or FSF) and ‘open’ software movements, and manifests itself in the different approaches taken to the development of code.

For example, the FSF is quite clear that ‘free’ software respects an individual user’s freedom. A program can only be classified as free software if its licence provides the user with four essential freedoms: the freedom to run the program as they wish; the freedom to study how the program works and adapt it; the freedom to redistribute copies; the freedom to improve the program and release improvements to the public. The Apache License Version 2.0, however, makes it clear that the source code can be modified and then incorporated into a proprietary product. This means that while Apache-licensed code qualifies as free software, products built using that code may not be free software.

Justin argues that this is simply being pragmatic and reflects what the developers want, and says: ‘By and large you’ll see that Apache projects tend to be focused on developers. These developers are primarily our target audience. One of the things with Richard Stallman’s view is that he wants the users to be free. Our attitude within Apache is that we are looking for the developers to have the freedom. They are saying: “You know what, if you want to make this into a closed source thing or if you want to make it into an open source thing then that’s fine”.’ And he adds: ‘We don’t really care necessarily how or where you use it as long as you abide by our licence, that you give us credit etc. But we are not necessarily going to say “hey you have to use it in a free and open source product”.’

Some of these differences centre around the role of software patents, an issue that remains controversial in the software industry. Justin says that ‘the FSF said “we don’t even talk about patents”. Apache License Version 2.0 has kind of set the standard in a lot of ways for how you think about patent protection and that kind of stuff. Our attitude is patents are going to be here and we have to deal with them and we have to be pragmatic. It was something that some of the other licences had done, but I think that as far as a large open source foundation [is concerned] we were very much on the cutting edge by saying that we are going to deal with this.’

There has also been much discussion in the software development community over the increasing use of Web 2.0-style software services, otherwise known as Software as a Service (SaaS) or the ‘Service Cloud’. The Free Software Foundation has responded to concerns over how one goes about licensing open source code when it is running on a remote server and providing a service through a browser client, by working on a new licence, called Affero.

Justin links this to the different ways in which the ASF and FSF view distribution: ‘It gets into [the question of] “what is distribution”. The challenge is: am I giving you the software by exposing it on a website? And the Affero exception, or however it gets phrased nowadays … [says that] putting it on a website is distributing and so you need to give the source.’ This is certainly how Richard Stallman sees it, but Justin says: ‘That doesn’t generally tend to be the way most people view distribution. They kind of realise, “Oh I am running the code on Google Docs but it doesn’t necessarily mean that I receive the software, I’m just using it.”’ Apache therefore has no plans to work on an Affero-style licence.

Open source in education

Such pragmatism also manifests itself in Justin’s attitude to the role of open source software in educational settings like schools and colleges. In contrast to Stallman, who believes schools and colleges should resist using proprietary software, Justin says: ‘Schools should use the software that is appropriate for the task. Our hope, our wish, is that open source fits those goals but that might not be the case.’ Justin feels that what is more important is that schools and colleges expose students to a wide range of different systems, both closed and open, saying: ‘One of the things about university is that it is supposed to expose people to different ideas. It shouldn’t be just pigeon-holed so that it is said, “Oh everyone here will use Microsoft” and it becomes the default. Expose students to the alternatives. Think outside the box.’

The future

Finally, we turn to the future and where next for Apache. Justin outlines the work of the Apache incubator, a formal process for setting up and incorporating new ideas and projects. He views this work as very important to the long-term development of the Foundation and an example of how important the concept of a developing community is. He says: ‘We call these [embryonic projects] podlings, and after a time they graduate and hatch and become top-level projects. There are 20 or 30 in the pipeline. They may not all succeed, they may not all attract the community, but this is how projects come into Apache.’

And what of his PhD? He argues that the research work is relevant to Apache’s long-term development of the web as he is looking at conceptual models that can describe the way different entities (clients, servers etc.) communicate and interact on the web. He is being supervised by Professor Richard Taylor(Director of the Institute for Software Research) who also supervised Roy Fielding’s well-known PhD, which first presented the Representational State Transfer (also known as REST) architectural style. This focuses on describing, in a formal way, the manner in which web-based document delivery works through the process of HTTP and URIs.

Today’s web, however, has an abundance of emerging technologies and uses what might be described as more computational ways of working, involving scripts such as AJAX, Web 2.0, data mash-ups and Web Services. What Justin is working on is something he calls CREST – Computational REST – which involves coming up with new ways of formally describing this new way of working on the web that will scale. According to Justin: ‘REST kind of said this is what the web is. It’s been that way for 10 years and this [mine] will say what the web is going to be in another 10 years.’

All in all, it’s a heady mix and Justin admits he’s very busy. The mentoring and development of software communities is a time-consuming task and he notes: ‘As Apache [Foundation] has grown from five or six projects to 70 top-level projects or so, running [it] takes a lot more [effort].’ One of the advantages of Apache’s meritocractic system is that there are plenty of talented people to draw on and Justin admits that he has recently been grateful for offers of help to delegate some of his role. ‘It is really about harnessing the energy’, he says.

At the end of the day, though, what continues to drive him is the way in which ideas about the way the web should work can be incorporated, at great speed, into the Apache code and so be made available to perhaps 60% or 70% of the servers on the web. To back this up he recounts an anecdote about Roy Fielding’s PhD viva, in which the candidate was asked how he knew that his stuff worked. The answer came back: ‘The World Wide Web.’ The examiners thought for a moment and then replied: ‘OK, we’ll accept that.’ For Justin, continuing to try to come up with methods that will handle this kind of scaling is the nub of the challenge that keeps him going. As he says: ‘This is the nice aspect of my involvement with open source.’

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Vì sao bạn nên trả tiền cho phần mềm nguồn mở

Why you should pay for Open Source software

If you're using open source software in an enterprise capacity there are sound reasons to pay

By Paul Rubens | CIO US | Published 14:44, 15 February 13

Theo: http://www.computerworlduk.com/news/open-source/3426616/why-you-should-pay-for-open-source-software/

Bài được đưa lên Internet ngày: 13/02/2013

Lời người dịch: Kinh doanh trong thế giới phần mềm nguồn mở khác với trong thế giới phần mềm nguồn đóng - sở hữu độc quyền. Với phần mềm nguồn mở (PMNM), bạn không trả tiền cho giấy phép để sử dụng phần mềm, mà trả tiền cho các sản phẩm là các dịch vụ xung quanh PMNM đó như (1) Trợ giúp chuyên nghiệp từ công ty; (2) Đầu vào cho các tính năng mới bạn muốn; (3) Kiểm thử sản phẩm, sửa lỗi nhanh và vòng đời được biết trước theo ý của bạn; (4) Bổ sung chức năng mới; (5) Một giải pháp với phần cứng và phần mềm được tích hợp, thay vì chỉ là phần mềm; (6) Các nền tảng chi phí thấp cho các sản phẩm sở hữu độc quyền; Tất cả những điều trên sẽ nằm trong cái gọi là: GÓI THƯƠNG MẠI, chính là thứ mà bạn sẽ trả tiền.

Red Hat đã công bố vào năm ngoái rằng hãng có kế hoạch chào OpenStack trên cơ sở thuê bao như một sản phẩm thương mại, mức độ chuyên nghiệp. OpenStack là một dự án phần mềm nguồn mở cho việc xây dựng các đám mây riêng và công cộng.

Các kỹ sư của Red Hat đóng góp cho dự án OpenStack, và công ty là một người cũ trong việc thương mại hóa các dự án nguồn mở và chào chúng trên cơ sở thuê bao. Có lẽ nổi tiếng nhất là Red Hat Enterprise Linux (RHEL), một phiên bản thương mại hóa của hệ điều hành Fedora Linux nguồn mở, cũng như phần mềm trung gian JBoss Enterprise của công ty, dựa vào các dự án của cộng đồng JBoss.

Các công ty như Red Hat kiếm tiền bằng việc bán các sản phẩm dựa vào các dự án nguồn mở. Nhưng nếu phần mềm nằm bên dưới là tự do, thì bạn chính xác đang trả tiền cho cái gì và khi nào bạn thuê bao các sản phẩm đó?

1. Hỗ trợ cấp độ chuyên nghiệp

Nếu công ty của bạn sử dụng phần mềm nguồn mở (PMNM) trong các lĩnh vực sống còn thì bạn có lẽ cần ai đó cung cấp hỗ trợ khi phần mềm không làm việc như được kỳ vọng.

Với phần mềm sở hữu độc quyền, tính sẵn sàng của sự hỗ trợ được đưa ra, nhưng khi bạn tải về và chạy một dự án nguồn mở bạn có thể phải dựa vào sự trợ giúp và hỗ trợ của cộng đồng các lập trình viên của dự án. Sự trợ giúp có thể tới, nhưng một lần nữa nó có thể không: Hỗ trợ của cộng đồng tới mà không có đảm bảo ở mức độ dịch vụ và đường điện thoại hỗ trợ 24x7 không được cung cấp.

Các công ty là bên thứ 3 đưa ra sự hỗ trợ cho một số PMNM trên cơ sở thương m ại, nhưng Gordon Haff, một người quản lý cao cấp ở Red Hat, nói, các công ty như Red Hat mà đỡ đầu và thương mại hóa các dự án nguồn mở ở trong vị thế tốt nhất để cung cấp cho bạn với sự hỗ trợ hơn là các công ty bên thứ 3 đó.

“Một mẩu chính của giá trị là đối với hầu hết các công nghệ cốt lõi mà chúng tôi chào thông qua thuê bao, chúng tôi tuyển dụng các chuyên gia mà, trong thực tế, là những người đóng góp chính cho phần mềm đó”, ông nói. “Quan trọng hơn, họ là phần chủ chốt của cộng đồng lập trình viên, và có thể thực hiện các thay đổi và sửa lỗi cho bạn khi họ được yêu cầu”, ông bổ sung.

Red Hat announced last year that it plans to offer OpenStack on a subscription basis as a commercial, enterprise-grade product. OpenStack is an open source software project for building private and public clouds.

Red Hat's engineers contribute to the OpenStack project, and the company is an old-hand at productizing open source projects and offering them on a subscription basis. It is probably best known for Red Hat Enterprise Linux (RHEL), a productized version of the open source Fedora Linux operating system, as well its JBoss Enterprise Middleware, based on JBoss community projects.

Companies such as Red Hat make a lot of money selling products based on open source projects. But if the underlying software is free, what exactly are you paying for when you subscribe to these products?

1. Enterprise-Grade Support

If your company uses open source software in mission critical areas then you'll probably need someone to provide support when the software doesn't work as expected.

With proprietary software, the availability of support is a given, but when you download and run an open source project you may have to rely on the help and support of the project's developer community. That help may arrive, but then again it may not: Community support comes with no service-level guarantee and a 24x7 telephone support line is not provided.

Third-party companies offer support for some open source software on a commercial basis, but Gordon Haff, a senior manager at Red Hat, says, companies like Red Hat that sponsor and productise open source projects are in a better position to provide you with support than these third-party companies.

"One key piece of value is that for most of the core software technology that we offer through subscription, we employ the experts who are, in fact, the key contributors to that software," he says. "More importantly, they are a key part of the developer community, and can put in changes or fixes for you when they are required," he adds.

2. Đầu vào trong các tính năng mới

Lợi ích khác của việc trả tiền cho thuê bao là trong nhiều trường hợp nó có thể cho bạn một tiếng nói trong lộ trình của sản phẩm, theo Haff. Điều này rõ ràng không thể nếu bạn đơn giản tải về và chạy PMNM.

Vì thế, nếu có những tính năng nhất định mà bạn muốn, thì việc trả tiền một thuê bao có thể là cách có hiệu quả về chi phisi của việc có được chúng được kết hợp vào trong sản phẩm.

Thật trớ trêu, các khách hàng trả tiền phải chờ lâu hơn cho các tính năng mới so với những người sử dụng khác vì các tính năng mới được phát hành trong các dự án nguồn mở “ngược lên dòng trên” trước khi chúng được đưa vào các phiên bản được thương mại hóa của phần mềm. Nói cách khác, Fedora là phần mềm “hiện đại” hơn so với RHEL.

3. Các sản phẩm được kiểm thử, ổn định, các sửa lỗi nhanh và các vòng đời có thể biết trước

Các công ty như Red Hat triển khai việc kiểm thử, tinh chỉnh và xử lý sự cố khắp một dải rộng lớn các phần cứng, các cấu hihf và ứng dụng trước khi nó cho phép bất kỳ mã mới nào từ các dự án nguồn mở đi xuống vào trong các sản phẩm thuê bao của chúng, Haff giải thích.

Điều này đòi hỏi nguồn nhân lực đáng kể của tập đoàn, các qui trình, các hệ thống và hạ tầng - và còn gây tranh cãi chính tính ổn định và độ tin cậy gây ra từ điều này, hơn là bất kỳ thứ gì khác, mà bạn đang trả tiền với sự thuê bao của bạn.

Hiệu ứng của việc đi xuống chậm của công nghệ ngày là việc phiên bản hiện hành của RHEL thường vài phiên bản sau Fedora, và vì cộng đồng phát triển Fedora không cung cấp các bản sửa lỗi cho các gói đã lỗi thời, nên Red Hat đưa ra ác wuar lỗi hoặc an ninh tạm thời cho các gói của RHEL như một phần của sự thuê bao. Các tính năng mới xuất hiện trong phiên bản mới nhất của Fedora cũng có thể được chuyển ngược lên dòng trên cho RHEL, Haff nói.

Các sản phẩm thuê bao cũng có xu hướng có một vòng đời được xác định mà chỉ định khoảng thời gian chúng sẽ nhận được những cải tiến, sửa lỗ và cập nhật an ninh, không giống như các dự án nguồn mở. Điều này cho phép bạn lên kế hoạch cho các bản nâng cấp của b ạn và mang những phần cứng mới vào làm việc được với các bản nâng cấp ở những nơi cần thiết.

2. Input Into New Features

Another benefit of paying a subscription is that in many cases it can give you a say in the product's roadmap, according to Haff. This is clearly not possible if you simply download and run the open source software.

Therefore, if there are certain features you want, paying a subscription can be a cost effective way of getting them incorporated into the product.

Ironically, paying customers have to wait longer for new features than other users do because new features are released in the "upstream" open source projects before they make it to the productised versions of the software. In other words, Fedora is more "cutting edge" software than RHEL.

3. Tested, Stable Products, Rapid Bugs Fixes and Predictable Lifecycles

Companies like Red Hat carry out testing, tuning and troubleshooting across a wide range of hardware, configurations and applications before it allows any new code from open source projects to trickle down into their subscription products, Haff explains.

This requires considerable corporate resource--people, processes, systems and infrastructure--and arguably it's the stability and reliability that results from this, more than anything else, that you are paying for with your subscription.

The effect of this slow trickle down of technology is that the current version of RHEL is usually several releases behind Fedora, and since the Fedora development community doesn't provide fixes to outdated packages, Red Hat provides interim security or bug fixes to RHEL packages as part of the subscription. New features that appear in the latest releases of Fedora may also be back ported to the RHEL, Haff says.

Subscription products also tend to have a defined lifecycle that specifies the length of time they will receive enhancements, bug fixes and security updates, unlike open source projects. This allows you to plan your upgrades and bring hardware refreshes into line with upgrades where necessary.

4. Chức năng bổ sung thêm

Trong nhiều trường hợp có ý nghĩa để trả tiền cho một sản phẩm có các tính năng bổ sung mà việc chào nguồn mở nằm bên dưới còn thiếu. Ví dụ, Big Switch Networks là người đỡ đầu của dự án trình kiểm soát mạng nguồn mở gọi là Floodlight, và sản phẩm Big Network Controller (BNC) của nó được xây dựng xung quanh dự án đó. Lợi ích của việc trả tiền cho BNC là chức năng bổ sung thêm mà BNC cung cấp để cải tiến trình kiểm soát Floodlight.

“BNC sử dụng Floodlight như cốt lõi của nó, nhưng nó cũng đưa vào các module bổ dung cho việc theo dõi, thống kê, mở rộng phạm vi thực thi và những thứ khác. Những module bổ sung thêm đó không phải là nguồn mở”, Andrew Harding, một giám đốc cao cấp tại Big Switch Networks, nói. BNC cũng chào khả năng triển khai nhiều nút - một tính năng mà hầu hết các doanh nghiệp tìm kiếm trong một trình kiểm soát mạng để cho phép khả năng chịu lổi (failover), nhưng nó lại không có trong trình điều khiển mạng Floodlight.

5. Giải pháp phần mềm và phần cứng được tích hợp

Việc trả tiền thường đáng giá cho một gói phần cứng và phần mềm được đưa vào trong PMNM để đảm bảo bạn có được một giải pháp được đảm bảo cho công việc. Ví dụ, Digium là nhà sáng tạo, duy trì và hỗ trợ của Asterisk, một dự án phần mềm điện thoại PBX nguồn mở.

Bổ sung thêm vào việc chào hỗ trợ Asterisk dựa vào SLA, công ty này bán phần cứng được thiết kế để cải tiến phần mềm theo cách y hệt mà Big Switch Networks chào các module phần mềm trả tiền bổ sung để cải tiến Floodlight.

Phần cứng bao gồm các thiết bị dự phòng được thiết kế để cho phép chịu lỗi đối với các lớp vật lý của các kết nối điện thoại, sao cho trong trường hộp một phần cứng hoặc phần mềm hỏng trên một máy chủ chạy Asterisk, thì các kết nối được tự động chuyển tới một máy chủ sao lưu Asterisk.

Digium cũng chào một dãy các điện thoại IP với các tính năng đặc thù Asterisk như khả năng được hỗ trợ và được thiết lập cấu hình từ xa, và các thẻ giao diện PSTN mà được bán với sự hỗ trợ để làm việc trong một môi trường Asterisk.

Vì thế trong khi bạn khắt khe không trả tiền cho phần mềm, thì bạn đang trả tiền cho một giải pháp được xây dựng trên nó. “Nhiều công ty không chỉ muốn Asterisk, họ muốn mua một giải pháp điện thoại hoàn chỉnh mà bao gồm cả phần mềm, sự hỗ trợ, các điện thoại và các khả năng chịu lỗi”, David Dufett, giám đốc cộng đồng Asterisk, nói.

4. Extra Functionality

In many cases it makes sense to pay for a product that has additional features that the underlying open source offering lacks. For example, Big Switch Networks is the sponsor of an open source network controller project called Floodlight, and its Big Network Controller (BNC) product is built around it. The benefit of paying for BNC is the extra functionality BNC provides to enhance the Floodlight controller.

"BNC uses Floodlight at its core, but it also includes additional modules for tracing, statistics, performance scalability and so on. These extra modules are not open source," says Andrew Harding, a senior director at Big Switch Networks. BNC also offers a multiple node deployment capability--a feature which most enterprises look for in a network controller to allow for failover, but which is absent in the Floodlight network controller.

5. Integrated Hardware and Software Solution

It's often worth paying for a hardware and software package that includes open source software to ensure you get a solution that is guaranteed to work. For example, Digium is the creator, maintainer and sponsor of Asterisk, an open source PBX telephony software project.

In additoin to offering SLA-backed support for Asterisk, the company sells hardware designed to enhance the software in the same way that Big Switch Networks offers additional paid-for software modules to enhance Floodlight.

The hardware includes redundancy appliances designed to enable physical-layer failover of telephone connections, so that in the event of a hardware or software failure on a server running Asterisk, communications are automatically switched to a backup Asterisk server.

Digium also offers a range of IP phones with Asterisk-specific features such as the capability to be supported and configured remotely, and PSTN interface cards that are sold with support to work in an Asterisk environment.

So while you are not strictly paying for the software, you are paying for a solution built on it. "Many companies don't just want Asterisk, they want to buy a complete telephony solution which includes software, support, phones and failover capabilities," says David Duffett, Asterisk's community director.

6. Các nền tảng chi phí thấp cho các sản phẩm sở hữu độc quyền

Digium là không bình thường trong việc phân phối Asterisk theo giấy phép nguồn mở GPLv2, nó cũng làm phần mềm sẵn sàng với một giấy phép thương mại chi phí thấp. Điều này cung cấp mọt lý do cuối cùng để trả tiền cho PMNM: nếu bạn trả tiền cho một giấy phép thương mại, thì bạn có thể sửa đổi phần mềm mà không có bổn phận cung cấp mã kết quả cho cộng đồng phát triển gốc theo giấy phép GPLv2. Điều này có thể là hữu dụng nếu bạn muốn kết hợp mã được sửa đổi vào các sản phẩm thương mại của riêng bạn.

Đó là một sự đóng gói (thương mại)

Những gì bạn thường trả tiền là với một thuê bao tới một sản phẩm dựa vào nguồn mở là một sự gói lại thương mại để đặt xung quanh mã nguồn mở. Sự gói lại đó bao gồm sự hỗ trợ, kiểm thử, chứng thực phần cứng và các vòng đời sản phẩm có thể biết trước được.

“Bằng việc trả tiền cho một thuê bao, bạn có kinh nghiệm y hệt như bạn làm với phần mềm sở hữu độc quyền, chỉ với ít tiền hơn nhiều”, Haff kết luận.

6. Low-Cost Platforms for Proprietary Products

Digium is unusual in that in addition to distributing Asterisk under the open source GPLv2 license, it also makes the software available with a low-cost commercial license. This provides one final reason to pay for open source software: If you pay for a commercial license, you can modify the software without the obligation of providing the resulting code to the original development community under the GPLv2 license. This can be useful if you want to incorporate the modified code into your own commercial products.

That's a (Commercial) Wrap

What you are generally paying for with a subscription to an open source-based product is a commercial wrap to put around the open source code. That wrap includes support, testing, hardware certification and predictable product lifecycles.

"By paying a subscription you get the same experience as you do with proprietary software, only for far less money," concludes Haff.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Nguồn mở bền vững

Sustainable open source

By Ross Gardler, Published: 05 August 2008, Reviewed: 15 February 2012

Theo: http://www.oss-watch.ac.uk/resources/sustainableopensource

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:

• Quỹ Phần mềm tự do - FSF (Free Software Foundation)
• Quỹ Eclipse (Eclipse Foundation) (đây từng ban đầu là một ban liên hiệp, xem bên dưới)
• Quỹ Gnome (Gnome Foundation)
• Quỹ Mozilla (Mozilla Foundation)
• Quỹ Python (Python Foundation)

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:

• Quỹ Mellon (Mellon Foundation) - cấp vốn cho công việc đáng kể đặc biệt trong thế giới các thư viện
• Google Summer of Code - một chương trình do Google quản lý mà cấp vốn cho các sinh viên làm việc trong các dự án nguồn mở
• Quỹ Ubuntu (Ubuntu Foundation) - Cấp vốn cho Ubuntu và các dự án liên quan khác.

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:

• Free Software Foundation
• The Eclipse Foundation (note this was originally a consortium, see below)
• The Gnome Foundation
• The Mozilla Foundation
• The Python Foundation

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:

• The Mellon Foundation - funding significant work particular in the library world
• Google Summer of Code - a programme run by Google that funds students to work on open source projects
• The Ubuntu Foundation - funding Ubuntu and related projects.

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

letrungnghia.foss@gmail.com