Nguồn mở cho doanh nghiệp - Quản lý rủi ro, gặt hái phần thưởng - rà soát lại

Open Source for the Enterprise - Managing Risks, Reaping Rewards – review

By James A J Wilson, Published: 09 November 2006, Reviewed: 14 May 2012

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

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

• Các tác giả: Dan Woods, Gautam Guliani
• Nhà xuất bản: O'Reilly
• Năm: 2005
• ISBN: 0-596-10119-8

Nguồn mở cho doanh nghiệp (Open Source for the Enterprise) chọn ra trong sự phấn khích xung quanh phần mềm nguồn mở (PMNM) và các nỗ lực khai thác nó cho tinh thần kinh doanh tốt và suy nghĩ rõ ràng. Cuốn sách có mục đích dứt khoát trong việc xem xét của các nhà quản lý CNTT đối với việc áp dụng PMNM. Dù trọng tâm là trong các môi trường thương mại, nhiều tư vấn cũng sẽ phù hợp cho các nhà quản lý trong các cơ quan nhà nước.

Phần thưởng và trách nhiệm của nguồn mở

Cùng với những lý do thông thường được đưa ra cho việc áp dụng PMNM - việc tránh bị khóa trói và nhà cung cấp, tiết kiệm tiền cho phí giấy phép, tính mềm dẻo - cuốn sách này đặc biệt chú ý tới phần thưởng làm phật lòng hơn đối với của việc trao quyền của các nhân viên, đặc biệt tập hợp các kỹ năng được gia tăng mà sự sử dụng nguồn mở có ý định yêu cầu và khuyến khích.

Các tác giả, có lẽ khắc nghiệt một chút được đưa ra cho bản chất tự nhiên ngày càng tinh tế về nhiều trong số nhiều hơn các chương trình phổ biến, định rõ các PMNM như là thiếu các mức thương mại của sự thương mại hóa. Bằng cách này họ ngụ ý thẳng thừng các qui trình cài đặt và cấu hình, tài liệu rõ ràng, và tất cả các chi tiết khác mà tạo ra các phần mềm thân thiện với người sử dụng cho các nhân viên ít chất kỹ thuật hơn.

Đưa ra sự thiếu hụt này, họ thấy nó như là phận sự của các nhân viên CNTT để phát triển các kỹ năng cần thiết có khả năng nhận được nhiều nhất từ phần mềm:

Để thành công với PMNM, là khôn ngoan để lên kế hoạch cho việc vượt qua được sự thiếu thương mại hóa. Lý do cơ bản của cuốn sách là việc phát triển các kỹ năng như vậy có thể có được những lợi ích to lớn.

Các tổ chức sẽ có lợi nhiều nhất từ PMNM cần phải tùy biến thích nghi để làm thế, bao gồm việc tránh các vấn đề về các nhân sự chủ chốt - nơi mà chỉ một người có sự tinh thông được yêu cầu để làm cho thứ gì đó làm việc được, đặt một tổ chức vào rủi ro nếu người đó đi mất.

Rõ ràng, việc huấn luyện nhân viên thể hiện một sự đầu tư, mà đây là một sự đầu tư, còn gây tranh cãi, mang lại những lợi ích có liên quan vượt ra khỏi khả năng thích ứng ngày một gia tăng của phần mềm. Các tác giả định rõ đặc điểm cho quyết định sẽ đi với PMNM như một sự đầu tư vào thời gian; phần mềm sở hữu độc quyền như một sự đầu tư vào tiền.

Rủi ro của nguồn mở

Một trong những rủi ro của việc áp dụng nguồn mở, theo Wooods và Guliani, là các phòng CNTT lấy các phần mềm còn quá non cho các kỹ năng của họ có được để đối phó. Sự đánh giá trung thực các năng lực của các nhân viên một phòng vì thế là quan trọng, được kết hợp với các mô hình cho việc đánh giá độ chín của PMNM, như Xếp hạng Độ sẵn sàng Doanh nghiệp – BRR (Business Readiness Rating) hoặc Mô hình Độ chính Nguồn Mở - OSMM (Open Source Maturity Model).

Các tác giả cũng đưa ra chỉ dẫn về các nghệ thuật đen tối của một nghiên cứu Hoàn vốn Đầu tư - ROI (Return on Investment) về PMNM, thấy đau để chỉ ra rằng các giấy phép thường chỉ là một yếu tố nhỏ trong các chi phí của phần mềm (thường không lớn hơn 20% các chi phí phần mềm sở hữu độc quyền). Những cảnh báo như vậy cảm nhận được một cách nổi bật đã đưa ra mồi nhử ban đầu của phần mềm 'tự do' (như trong giá thành). Thay vì ý nghĩa thứ 2, đôi khi bị bỏ qua, ý nghĩa của tự do (như tự do hợp pháp để tùy biến thích nghi), có thể chứng minh có lợi hơn về lâu dài.

Có một chương hữu dụng và khá thẳng thắn về các giấy phép, để giúp các nhà quản lý hiểu những hạn chế pháp lý đi với các quyền tự do sử dụng nguồn mở. Chương tiếp theo mô tả sự sợ hãi, không chắc chắn và nghi ngờ - FUD (fear, uncertainty and doubt) mà những người phản đối nguồn mở sử dụng để cố hạn chế sự áp dụng, và để giảm thiểu tiềm năng gây hại cho những hậu quả đối với các thị trường phần mềm truyền thống. Điều này bao gồm sự thảo luận các vấn đề về bằng sáng chế nảy sinh từ tranh cãi giữa SCO với IBM, và nó không rút ra những cú đấm đối với những sự không chấc chắn thực sự về pháp lý.

Khi nào và vì sao sử dụng nguồn mở

Một xem xét quan trọng mà cuốn sách đưa ra là giá trị chiến lược mà CNTT mang lại cho một công ty. Nói đơn giản, giá trị này càng lớn, càng có khả năng một công ty sẽ hưởng lợi từ các thuộc tính mềm dẻo và năng động của nguồn mở. Việc sử dụng PMNM trao cho một tổ chức sự kiểm soát cũng như trách nhiệm.

Khi được khuyến cáo rằng một tổ chức phát triển một văn hóa học tập trong các nhân viên của nó để thích nghi với nguồn mở, cuốn sách cũng thừa nhận vai trò ngày một gia tăng mà các cuộc tư vấn nguồn mở có thể đóng trong việc thu hẹp khoảng cách các kỹ năng trong các lĩnh vực đặc thù.

Các phụ lục - Các ứng dụng phần mềm

Nguồn mở cho doanh nghiệp bao gồm hơn 60 trang phụ lục đánh giá các gói PMNM đặc thù. Chúng là ứng dụng thực tế rõ ràng, dù thời hạn sử dụng còn hạn chế, đưa ra bước thay đổi nhanh trong thị trường phần mềm.

Kết luận

Cuốn sách này được viết cho các nhà quản lý CNTT, và sẽ trả lời cho các câu hỏi của họ về nguồn mở một cách đáng ngưỡng mộ. Tất cả các vấn đề chính, từ động lực của các lập trình viên cho tới những tranh cãi, được đề cập tới theo một cách thức rõ ràng và thực tế. Các tác giả có lẽ quá cẩn thận về những thách thức mà nguồn mở thể hiện, nhưng điều này ít nhất đảm bảo rằng mỗi độc giả sẽ nhận thức được đầy đủ về những gì họ đang tự cho phép họ. Quá phấn khích trong thế giới mới can đảm của nguồn mở được thấm đẫm, nhưng hy vọng sự thích thú không bị dập tắt. Trong khi cuốn sách vẫn còn là hiện hành, nó rất đáng được khuyến cáo.

• Authors: Dan Woods, Gautam Guliani
• Publisher: O’Reilly
• Year: 2005
• ISBN: 0-596-10119-8

Open Source for the Enterprise picks up on the excitement surrounding open source software and attempts to harness it to good business sense and clear thinking. The book is aimed squarely at IT managers considering adopting open source software. Although the focus is on commercial environments, much of the advice will also be relevant to managers in public institutions.

Rewards and responsibilities of open source

Alongside the usual reasons given for adopting open source software - avoiding vendor lock in, saving money on licence fees, flexibility - this book pays particular attention to the more vexed reward of staff empowerment, specifically the increased skills set that the use of open source is purported to require and encourage.

The authors, perhaps a little harshly given the increasingly polished nature of many of the more popular programs, characterise open source software as lacking commercial levels of productization. By this they mean straightforward installation and configuration processes, clear documentation, and all the other details that make software user-friendly for less technical staff. Given this lack, they see it as incumbent upon IT staff to develop the necessary skills to be able to get the most out of the software:

To succeed with open source software, it is wise to plan for overcoming the lack of productization. It is the fundamental argument of this book that developing such skills can pay great benefits.

Organizations that are to get the most out of open source software need to adapt to do so, which includes avoiding key person problems - where only one person has the expertise required to get something to work, putting an organization at risk should that person leave.

Obviously, staff training represents an investment, but this is an investment, it is argued, that brings associated benefits beyond increasing the adaptability of software. The authors characterise the decision to go with open source software as an investment in time; proprietary software as an investment in money.

Risks of open source

One of the risks of adopting open source, according to Woods and Guliani, is that IT departments take on software that is too immature for their skills set to cope with. Honest assessment of the abilities of one’s staff is therefore important, combined with models for assessing the maturity of open source software, such as the Business Readiness Rating (BRR) or the Open Source Maturity Model (OSMM).

The authors also offer guidance on the dark arts of conducting a Return on Investment (RoI) study on open source software, taking pains to point out that licences are usually only a small factor in the costs of software (generally not more than 20% of true proprietary software costs). Such warnings are eminently sensible given the initial lure of ‘free’ (as in price) software. It is instead the second, sometimes overlooked, meaning of free (as in legally free to adapt), that may prove more beneficial in the long term.

There is a useful and relatively straightforward chapter on licences, to help managers understand the legal restrictions that come with the freedoms of using open source. A further chapter describes the FUD (fear, uncertainty and doubt) that opponents of open source employ to try to limit adoption, and to minimise potentially damaging consequences for traditional software markets. This includes discussion of the patent issues arising from the SCO vs IBM dispute, and it doesn’t pull punches regarding genuine legal uncertainties.

When and why to use open source

An important consideration that the book raises is the strategic value that IT brings to a company. Simply put, the greater this value, the more likely one is to benefit from the flexible and dynamic properties of open source. Using open source software gives an organisation control as well as responsibility.

While it is recommended that an organisation develop a learning culture among its staff to adapt to open source, the book also acknowledges the increasing role that open source consultancies can play in bridging skills gaps in specific areas.

Appendices - Software Applications

Open Source for the Enterprise concludes with over 60 pages of appendices evaluating specific open source software packages. These are of definite practical application, albeit limited shelf-life given the fast pace of change in the software market.

Conclusions

This book is written for IT managers, and should answer their questions about open source admirably. All the major issues, from developer motivation to legal wranglings, are covered in a clear and practical manner. The authors are perhaps over-cautious with regard to the challenges that open source presents, but this does at least ensure that every reader should be fully aware of what they are letting themselves in for. Over-excitement at the brave new world of open source is dampened, but hopefully without interest being extinguished. While the book remains current, it is to be recommended.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Các catalog dự án và các mô tả dự án có sử dụng DOAP

Project Catalogues and Project Descriptors using DOAP

By Ross Gardler, Published: 02 January 2007, Reviewed: 11 February 2013

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

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

Lời người dịch: Một vấn đề quan trọng đối với các dự án phần mềm tự do nguồn mở (PMTDNM) là việc quảng bá cho dự án để có được càng nhiều người sử dụng và càng nhiều lập trình viên đóng góp cho dự án càng tốt. Công việc đó có thể làm được một cách tự động thông qua các website, các catalog giới thiệu - mô tả dự án trên trực tuyến với định dạng DOAP - định dạng Mô tả Dự án (Description of a Project). Bên cạnh đó, cũng còn có các công cụ khác nữa có thể giúp làm được như vậy và/hoặc có thể hỗ trợ làm việc với DOAP được tốt hơn. Bài viết là rất cần cho những người thực sự đang quản lý một dự án PMTDNM hiện nay.

Các dự án nguồn mở cần phải được đưa ra thị trường nếu chúng muốn lôi cuốn những người sử dụng và những người đóng góp. Hầu hết các dự án có một webiste mô tả cộng việc của họ nhưng làm thế nào họ lôi cuối mọi người tới website của họ ngay từ lần đầu tiên? Trong khi nhiều dự án có thể dựa vào các máy tìm kiếm để được thấy, thì có một số lượng các catalog dự án ngày một gia tăng mà một dự án nên cân nhắc được liệt kê trong đó, nhưng việc duy trì các khoản đầu vào trong một số lượng lớn các catalog có thể là một qui trình mất thời gian. Tài liệu này giới thiệu định dạng Mô tả của một Dự án - DOAP (Description of a Project) cho việc quản lý các chi tiết dự án trong các catalog đang nổi lên.

Trình mô tả dự án mở

Việc liệt kê dự án của bạn trong các catalog trực tuyến như Freecode là một tác vụ nặng nề, và có thể một khá nhiều thời gian. Hơn nữa, một phát hành mới hoặc thay đổi đáng kể trong dự án của bản thiết lập neenn các yêu cầu mà ai đó phải cập nhật từng khoản đầu vào vằng việc viếng thăm từng site của catalog, một lần nữa là một qui trình mất thời gian. Trong nhiều trường hợp, điều này có nghĩa là các dự án hoặc không được liệt kê hoặc các khoản đầu vào của họ trở nên lạc hậu, tạo ra một ấn tượng hiểu sai về tính bất lực trong dự án.

Những gì cần thiết là cách thức đối với các dự án để cập nhật tất cả các catalog cùng một lúc. May thay, Web ngữ nghĩa - Symantic Web (các dữ liệu được cung cấp ở dạng mà các máy dễ dàng xử lý được) đưa ra đúng cơ chế như vậy. Một Mô tả của một dự án - DOAP (Description of a Project) là một tài liệu máy đọc được mà được sử dụng để chia sẻ thông tin về một dự án. Một trình mô tả DOAP có thể được sử dụng cho:

• việc nhập dễ dàng các dự án vào trong các danh bạ
• việc cập nhật các danh bạ được tự động
• trao đổi dữ liệu được giữa các danh bạ
• thiết lập cấu hình tự động cho các tài nguyên như các danh sách thư, các danh bạ được chỉa sẻ và các trình theo dõi các vấn đề
• việc hỗ trợ người duy trì các gói, những người tạo thành các nguồn cho các nhà phân phối

Sử dụng DOAP

DOAP tạo thuận lợi cho việc xây dựng các đăng ký dự án bằng việc cho phép các site 'trình tổng hợp' kéo vào các hồ sơ của dự án từ nhiều nguồn khác nhau và kết hợp chúng thành một cơ sở dữ liệu duy nhất. Để cho một dự án sẽ được kết hợp theo một trình tổng hợp như vậy, dự án cần phải tạo ra một tệp DOAP (xem phần tiếp sau) và xuất bản nó đâu đó có thể truy cập được thông qua một yêu cầu http hoặc https. Điều này thường có nghĩa rằng nó được xuất bản trên website của dự án. Sau đó dự án có thể hoặc lưu ý trực tiếp cho trình tổng hợp thu lượm các tệp, như xem xét chúng cho các bản cập nhật. Một khi website của trình tổng hợp biết về một tệp DOAP đặc biệt nào đó, thì nó có thể hướng dẫn tệp đó cho những thay đổi và vì thế cập nhật các hồ sơ của nó bất kỳ khi nào tệp DOAP được cập nhật.

Vì, để có hiệu ứng tối ưu, tệp DOAP được lưu trữ cục bộ đối với dự án, không cần thiết đối với những người duy trì dự án phải viếng thăm site của trình tổng hợp để cập nhật các hồ sơ của chúng. Họ đơn giản cập nhật tệp DOAP cục bộ và chờ cho site của trình tổng hợp thu lượm thông tin mới. Tất nhiên, vì tệp DOAP được làm để truy cập được thông qua một yêu cầu http hoặc https, bất kỳ catalog nào khác được DOAP trợ giúp cũng có thể truy cập được thông tin mieenxn là chúng biết tìm ở đâu.

Khi một dự án được liệt kê trong nhiều catalog được trợ giúp bằng DOAP hơn, các lợi ích của việc cập nhật từ xa bắt đầu nhân bản. Tất cả điều mà người duy trì dự án cần phải làm là cập nhật tệp của chúng, và tất cả các catalog sẽ tự chúng được cập nhật tự động. Việc cập nhật này xảy ra như thế nào là phụ thuộc vào cách mà catalog được triển khai. Một số catalog sử dụng một ATOM feed, các catalog khác thì định kỳ thu thập các tệp.

Phát hiện các tệp DOAP mới cũng có thể được hỗ trợ bằng việc đưa ra một liên kết cho tệp DOAP của bạn tới một tong những trang wiki mới mà liệt kê các tệp DOAP. Một lần nữa, một catalog có thể sử dụng danh sách các liên kết này để khám phá các tệp DOAP còn chưa được biết trước đó. Một ví dụ về các trang wiki được sử dụng cho mục đích này là Semantic Web Bulletin Board.

Các catalog của các chuyên gia và các mở rộng DOAP

Các catalog DOAP có thể là khổng lồ, khi mà chúng không thường hạn chế các dự án nào sẽ được liệt kê. Một catalog lớn và rộng như vậy không phải luôn là những gì được một người sử dụng yêu cầu. Một người sử dụng có thể muốn xem một danh sách các dự án mà trực tiếp có liên quan tới một sự quan tâm đặc biệt. Ví dụ, một thành viên của dự án X có thể có quan tâm để xem một catalog có chứa tất cả các dự án phổ biến mà phụ thuộc vào sự án X. Như một sự lựa chọn, họ có thể muốn thấy một catalog của tất cả các dự án mà dự án X phụ thuộc vào.

Một ví dụ về một catalog của các chuyên gia như thế này có thể thấy tại Quỹ Phần mềm Apache - ASF (Apache Software Foundation). ASFF có nhiều dự án tích cực và cho tới khi họ đã áp dụng DOAP thì đã không có trọng điểm nào nơi mà các bên có quan tâm có khả năng có được một tóm tắt về tất cả các dự án đó. Với sự áp dụng DOAP, ASF có khả năng giới thiệu projects.apache.org, một webiste cung cấp nhiều cách thức khác nhau để xem các dự án đang có sẵn trong ASF. Ví dụ, có khả năng để truy xuất một danh sách tất cả các dự án có liên quan tới XML, hoặc tất cả các dự án được viết trong một ngôn ngữ lập trình đặc biệt.

Một khía cạnh thú vị của catalog của ASF là nó đã mở rộng ngôn ngữ mô tả DOAP để đưa vào thông tin bổ sung mà chỉ phù hợp với ASF. DOAP được thiết kế đặc biệt để cho phép dạng mở rộng này mà không gây ảnh hưởng tới các catalog khác đang sử dụng tệp DOAP y hệt. Ví dụ, ASF đã bổ sung thêm các thẻ tag để lấy thong tin về Ban Quản lý Dự án (Project Management Committee) đối với từng dự án. Thông tin này được hiển thị trong catalog của projects.apache.org, nhưng có thể bị các catalog khác bỏ qua.

Tạo và quản lý các tệp DOAP

Thiết lập được DOAP là một điều tốt lành cho một dự án, vậy một người quản lý dự án định tạo và duy trì một tệp DOAP thế nào?

Các tệp DOAP là các tệp văn bản, nên bạn có thể sử dụng trình soạn thảo văn bản ưa thích để làm việc với chúng. Như một sự lựa chọn, bạn có thể sử dụng trình soạn thảo XML ưa thích của bạn. Cũng có một ít các công cụ dựa vào web có sẵn cho bạn để sử dụng, ví dụ Matic DOAP. Tuy nhiên, chúng không cung cấp các phương tiện cho việc soạn sửa một tệp DOAP đang tồn tại (chúng đơn giản giúp bạn tạo tệp ban đầu).

Nếu bạn có quan tâm trong việc tạo ra công cụ sinh DOAP dựa vào web của riêng bạn mà hỗ trợ bất kỳ sự tùy biến nào, thì một điểm khởi đầu tốt có thể là Apache Labs DOAPizer. Đây là một ứng dụng bằng Javascript minh họa sự tạo ra một DOAP với các mở rộng ASF.

Các dự án tạo các chế tác phần mềm có thể thấy rằng công cụ quản lý xây dựng được chọn của họ, như Apache Maven, tạo thuận lợi cho việc quản lý các tệp DOAP dự án của bạn một cách tự động như một phần của chu kỳ quản lý dự án thông thường.

Một số site đặt chỗ dự án, như SourceForge, cũng đưa ra các giao diện lập trình ứng dụng cho việc mở ra thông tin về các dự án có sử dụng DOAP. Trong trường hợp này, thông tin bạn cung cấp như một phần của mô tả dự án của bạn sẽ được sử dụng để phổ biến DOAP từ site đó.

Một tệp DOAP trông như thế nào?

DOAP là một sơ đồ Khung Định nghĩa Tài nguyên - RDF (Resource Definition Framework); đó là, nó là một bảng từ vựng cho việc mô tả một chủ đề cụ thể, trong trường hợp này là một dự án. Nó thường được viết như một tài liệu XML (RDF/XML). Bên dưới là một ví dụ đơn giản của một tệp DOAP cơ bản mô tả chức năng dự án Foo Bar OSS.

Foo Bar OSS

Platform for making Foo into Bar

There are too many Foo's in the world. This project provides a suite of tools for automatically converting various types of Foo into just about any kind of Bar.

Java

FooBar-Milestone2

2006-01-01

0.2

2007-1-16

Foo Man

Có nhiều yếu tố hơn có thể được sử dụng trong các tài liệu DOAP. Một danh sách của chúng không được cung cấp ở đây, nhưng sơ đồ hoàn chỉnh có thể thấy ở website của dự án DOAP (https://github.com/edumbill/doap/wiki).

Một ưu điểm của việc sử dụng RDF là nó dễ dàng mở rộng bảng từ vựng DOAP. Một sự mở rộng như vậy có thể thấy trong ví dụ ở trên. Lưu ý rằng người duy trì được mô tả bằng việc sử dụng định dạng RDF khác được gọi là Friend của một Friend - FOAF (bạn của bạn). Điều này có nghĩa là bảng từ vựng DOAP cần không tự quan tâm về cách mô tả một con người. Tương tự, như được thảo luận ở trên, ASF từng có khả năng để mở rộng bảng từ vựng DOAP để đưa vào thông tin phù hợp cho chỉ các dự án của Apache.

Một ví dụ nữa về việc mở rộng DOAP với các sơ đồ khác tới ở dạng của việc đảm bảo tệp DOAP của bạn được sử dụng trong hơn một ngôn ngữ. Ví dụ, các liên kết có thể được dán nhãn với sơ đồ siêu dữ liệu Dublin Core để phân biệt giữa các trang tải về trong các ngôn ngữ khác nhau, như có thể thấy bên dưới.

Java Platform

Việc tạo và duy trì catalog riêng của bạn

Cũng dễ dàng như để cập nhật các catalog của những người khác với DOAP, cũng rất dễ dàng để tạo các catalog của riêng bạn bằng việc sử dụng các tệp DOAP. Trước khi xem xét làm thế nào, chúng ta hãy xem xét vì sao một dự án có thể muốn làm điều này.

Như hầu hết các người quản trị web (webmasters) biết, chìa khóa cho việc có được một xếp hạng cao trong hầu hết các máy tìm kiếm là có nội dung cập nhật có giá trị và thường xuyên trên site. Hơn nữa, việc cung cấp một dịch vụ hữu dụng cho những người viếng thăm là rất quan trọng và làm gia tăng các cơ hội họ sẽ liên kết ngược về bạn. Một cách bao trùm từng trong số các cơ sở đó là để duy trì một catalog các dự án có liên quan tới dự án của riêng bạn theo một số cách thức. Điều này có thể được thực hiện bằng việc sử dụng thẻ tag chủng loại trong tệp DOAP. Nếu vài dự án được liệt kê với cùng chủng loại y hệt đó, sẽ có cơ hội để làm việc cùng và giúp cho nhiều dự án trở nên bền vững (bản dịch tiếng Việt) hơn.

Không có DOAP thì cần thiết phải khuyến khích tất cả các dự án được liệt kê phải duy trì các khoản đầu vào của họ trong catalog của họ, nó tiêu tốn các tài nguyên của họ và vì thế sẽ không có khả năng xảy ra. Như một sự lựa chọn, ai đó trong dự án của bạn có thể duy trì từng khoản đầu vào, nhưng điều đó tiêu tốn các tài nguyên dự án của riêng bạn. Tuy nhiên, nếu các dự án được liệt kê trong một catalog của dự án, thì nó có thể cũng có lợi cho dự án của bạn. Bạn có thể thấy các dự án có liên quan và những người khác cũng sẽ thấy dễ dàng hơn, tới lượt nó, có thể giúp bạn xây dựng một cộng đồng (bản dịch tiếng Việt) xung quanh dự án của bạn.

Phần mềm cho sự tạo ra các catalog từ các tệp DOAP còn chưa được chín muồi. Mã đằng sau projects.apache.org là sẵn sàng từ Apache nhưng phần lớn vẫn còn được xem như một dự án nội bộ.

Như một sự lựa chọn, Apache Forrest có mã thực nghiệm trong trình cài cắm projectInfo mà sẽ tạo ra một site tương tự như của site projects.apache.org. Bất kể thực tế là những dự án đó vẫn còn trong các giai đoạn sớm của chúng, thì chúng đều làm việc tốt.

Các lựa chọn khác bao gồm Exhibit từ MIT, một khung xuất bản dữ liệu có cấu trúc hạng nhẹ cho phép bạn tạo các trang web với sự hỗ trợ cho việc sắp xếp, lọc, và trực quan hóa bằng việc chỉ viết HTML và có khả năng lựa chọn một số mã CSS và Javascript. Dự án Exhibit không đặc biệt nhằm vào các tệp DOAP, mà nó làm việc rất tốt với chúng.

Open source projects need to be marketed if they want to attract users and contributors. Most projects have a website describing their work but how do they attract people to their website in the first instance? While many projects may rely on search engines to be found, there are a growing number of project catalogues that a project should consider being listed in, but maintaining entries in a large number of catalogues can be a time consuming process. This document introduces the Description of a Project (DOAP) format for managing project details in emerging catalogues.

An Open Project Descriptor

Listing your project in online catalogues such as Freecode is an onerous task, and can take up a considerable amount of time. Furthermore, each new release or significant change in your project setup requires someone to update each entry by visiting each catalogue’s site, again a time-consuming process. In many cases, this this means projects are either not listed or their entries become stale, giving a misleading impression of inactivity in the project.

What is needed is a way for projects to update all catalogues simultaneously. Fortunately, the Semantic Web (data provided in a form that is easily processed by machines) provides just such a mechanism. A Description of a Project (DOAP) is a machine- readable document that is used to share information about a project. A DOAP descriptor can be used for:

• easy importing of projects into directories
• automated updating of directories
• data exchange between directories
• automatic configuration for resources such as mailing lists, shared repositories and issue trackers
• assisting package maintainers who bundle resources for distributors

DOAP in use

DOAP facilitates the building of project registries by allowing ‘aggregator’ sites to pull in project records from many different sources and combine them into a single database. In order for a project to be incorporated in such an aggregator, the project needs to create a DOAP file (see next section) and publish it somewhere where it is accessible via an http or https request. This usually means that it is published on the project’s website. Then the project can either notify the aggregator directly of the location of this file, or register it at one of the sites from which the aggregator harvests the files, i.e. examines them for updates. Once the aggregator website knows about a particular DOAP file, it can monitor the file for changes and therefore update its records whenever the DOAP file is updated.

Since, for optimal effect, the DOAP file is stored locally to the project, there is no need for project maintainers to visit the aggregator site in order to update their records. They simply update their local DOAP file and wait for the aggregator site to harvest the new information. Of course, since the DOAP file is made accessible via an http or https request, any other DOAP-enabled catalogue can also access the information as long as they know where to look.

As a project is listed in more DOAP enabled catalogues, the benefits of remote updating start to multiply. All the project maintainer needs to do is update their file, and all catalogues should automatically update themselves. How this updating occurs is dependent on how the catalogue is implemented. Some catalogues use an ATOM feed, other catalogues periodically harvest files.

Discovery of new DOAP files can also be supported by submitting a link to your DOAP file to one of the new wiki pages that list DOAP files. Again, a catalogue may use this list of links to discover previously unknown DOAP files. An example of wiki pages used for this purpose are the Semantic Web Bulletin Board .

Specialist catalogues and DOAP extensions

DOAP catalogues can be vast, as they do not generally restrict which projects are listed. Such a large and broad catalogue is not always what is required by a user. A user may want to view a list of projects that are directly related to a particular interest. For example, a member of project X may be interested to see a catalogue containing all known projects that are dependent on project X. Alternatively, they may wish to see a catalogue of all projects that project X depends upon.

An example of a specialist catalogue such as this can be found at The Apache Software Foundation (ASF). The ASF has many active projects and until they adopted DOAP there was no central point where interested parties were able to get a summary of all those projects. With the adoption of DOAP, the ASF are able to produce projects.apache.org, a website that provides many different ways of viewing the available projects within the ASF. For example, it is possible to retrieve a list of all XML-related projects, or all projects written in a particular programming language.

An interesting aspect of the ASF catalogue is that it has extended the DOAP description language to include additional information that is only relevant to the Apache Software Foundation. DOAP is specifically designed to allow this kind of extension without affecting other catalogues using the same DOAP file. For example, the ASF has added tags to capture information about the Project Management Committee for each project. This information is displayed in the projects.apache.org catalogue, but may be ignored by other catalogues.

Creating and Managing DOAP Files

Having established that DOAP is a good thing for a project, how does a project manager go about creating and maintaining a DOAP file?

DOAP files are text files, so you can use your favourite text editor to work with them. Alternatively, you can use your favourite XML editor. There are also a few web-based tools available for you to use, for example DOAP A Matic. However, these do not provide a means for editing an existing DOAP file (they simply help you create the initial file).

If you are interested in creating your own web-based DOAP generation tool that supports any customisations, then a good starting point would be the Apache Labs DOAPizer. This is a Javascript application that illustrates the creation of a DOAP with ASF extensions.

Projects creating software artifacts may find that their chosen build management tool, such as Apache Maven, provides a facility for managing your project’s DOAP files automatically as part of the normal project management cycle.

Some project hosting sites, such as SourceForge, also provide APIs for exposing information about projects using DOAP. In this case, the information you provide as part of your project description will be used to populate the DOAP from the site.

What does a DOAP file look like?

DOAP is a Resource Definition Framework (RDF) schema; that is, it is a vocabulary for describing a particular topic, in this case a project. It is commonly written as an XML document (RDF/XML).

Below is a simple example of a basic DOAP file describing the fictional Foo Bar OSS project.

Foo Bar OSS

Platform for making Foo into Bar

There are too many Foo's in the world. This project provides a suite of tools for automatically converting various types of Foo into just about any kind of Bar.

Java

FooBar-Milestone2

2006-01-01

0.2

2007-1-16

Foo Man

There are many more elements that can be used in DOAP documents. A full list of them is not provided here, but the complete schema can be seen at the DOAP project website (see Further reading).

One advantage of using RDF is that it is easy to extend the DOAP vocabulary. Such an extension can be seen in the above example. Note that the maintainer is described using another RDF format called Friend of a Friend (FOAF). This means that the DOAP vocabulary need not concern itself with how to describe a person. Similarly, as discussed above, the ASF has been able to extend the DOAP vocabulary to include information relevant to Apache projects only.

A further example of extending DOAP with other schemas comes in the form of ensuring your DOAP file is of use in more than one language. For example, links can be labelled with the Dublin Core meta data schema to distinguish between download pages in various languages, as can be seen below.

Java Platform

Creating and maintaining your own catalogue

As well as being easy to update other people’s catalogues with DOAP, it is also very easy to create your own catalogues using DOAP files. Before looking at how, let us consider why a project may want to do this.

As most webmasters know, the key to getting a high rank on most search engines is to have valuable and constantly updating content on the site. Furthermore, providing a useful service to your visitors is of great importance and increases the chances that they will link back to you. One way of covering each of these bases is to maintain a catalogue of projects that are related to your own project in some way. This can be done by using the category tag in the DOAP file. If several projects are listed with the same category, there may be an opportunity to work together and help multiple projects in becoming more sustainable.

Without DOAP it is necessary to encourage all listed projects to maintain their entries in your catalogue, which consumes their resources and so is unlikely to happen. Alternatively, someone in your project can maintain each entry, but that consumes your own project’s resources. However, if the projects listed in the catalogue maintain a DOAP file, the only additional overhead in managing that catalogue is maintaining a list of projects within it. If you have created your DOAP file and have your project listed in a project catalogue, it can benefit your project as well. You can find related projects and be found by others more easily, which in turn can help you in building a community around your project.

Software for the creation of catalogues from DOAP files has yet to fully mature. The code behind projects.apache.org is available from Apache but is still largely considered an internal project. Alternatively, Apache Forrest has experimental code in its projectInfo plugin that will produce a similar site to that at projects.apache.org. Despite the fact that these projects are still in their early stages, they both work well.

Other options include Exhibit from MIT, a lightweight structured data publishing framework that lets you create web pages with support for sorting, filtering, and rich visualizations by writing only HTML and optionally some CSS and Javascript code. The Exhibit project is not specifically targeted at DOAP files, but it works very well with them.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Nguồn mở vẫn phù hợp cho các hệ thống nghiệp vụ sống còn

Open source still suitable for business-critical systems

Posted on September 24, 2012 by Sander van der Waal

Theo: http://osswatch.jiscinvolve.org/wp/2012/09/24/open-source-still-suitable-for-business-critical-systems/

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

Lời người dịch: Nhiều người nghĩ rằng nguồn mở là không phù hợp cho các hệ thống nghiệp vụ sống còn. Suy nghĩ này là sai. Đó là nội cung của bài viết này. Ngoài ra, khi nói về nguồn mở và đám mây, bài viết cho thấy nguồn mở hơn là đám mây. Lý do: “đặc biệt trong lĩnh vực quản lý rủi ro, một số bước cần phải được tiến hành để chắc chắn rằng các hệ thống và dữ liệu là an ninh và an toàn trong một môi trường đám mây. Kiểm soát và tính trực quan của các hệ thống là ít rõ ràng hơn nhiều trong môi trường đám mây, và việc kiểm toán các qui trình cần phải hiện diện để đảm bảo điều này được giải quyết đúng đắn phù hợp”.

Nguồn mở là sẵn sàng cho các nghiệp vụ. Không chỉ đối với các công ty nhỏ hơn đang tìm kiếm một hệ thống quản trị nội dung (CMS) đơn giản, mà còng cho cả các hệ thống nghiệp vụ sống còn với lượng giao thông cao. Đây không phải là tin gì mới mẻ, và các ví dụ là phổ biến, như sử dụng Linux tại Thị trường Chứng khoán Luân Đôn. Nhưng một báo cáo thú vị của Jim Norton, cựu chỉ tịch của BCS, gần đây đã tái khẳng định thông điệp này và nó thú vị để đọc. Đối với một người, báo cáo đã được Amadeus, một nhà cung cấp công nghệ cho nền công nghiệp lữ hành đỡ đầu. Như Glyn Moody lưu ý đúng, đây không phải là một công ty có quan tâm trong việc hỗ trợ một quan điểm công nghệ đặc biệt, mà đang tập trung vào việc cung cấp các giải pháp thực tế.

Các lợi ích của nguồn mở

Báo cáo liệt kê những lợi ích của nguồn mở là phù hợp cho các dạng những người tham gia đóng góp khác nhau. Đặc biệt cho các khách hàng doanh nghiệp, Norton lưu ý rằng nguồn mở cung cấp:

• Sự truy cập tới đổi mới lớn hơn - Một cộng đồng tự tăng cường đã nổi lên đối với nghiên cứu và phát triển được chia sẻ mà các khách hàng của phần mềm nguồn mở có thể tham gia.
• Khả năng đáp ứng của nhà cung cấp được cải thiện - Sự truy cập tới một cộng đồng cho phép thời gian đáp ứng các vấn đề tốt hơn nhiều. Khách hàng không còn phụ thuộc vào một nhà cung cấp để đáp ứng thích hợp và đúng lúc, mà có một cộng đồng rộng lớn hơn những người có thể giúp khi có những vấn đề.
• Khả năng truy cập hệ thống được cải thiện - có các hệ thống khác nhau rộng lớn hơn đã được triển khai cởi mở trong vòng ít thập kỷ qua. Điều này cho phép các khách hàng sử dụng và tiếp tục sử dụng các hệ thống nếu họ có sẵn sự tinh thông theo yêu cầu. Các khách hàng không có nhu cầu phải phụ thuộc vào chu kỳ vòng đời phần mềm mà nhà cung cấp yêu cầu.

Khi tập trung nhiều hơn vào các khách hàng đầu cuối, những lợi ích bổ sung sau đây được nhấn mạnh:

• Sự lựa chọn và độ sâu của các dịch vụ lớn hơn - Norton viện lý rằng các dịch vụ nhất định là có sẵn đối với nguồn mở từng đơn giản là không khả thi về mặt tài chính theo mô hình kinh tế của phần mềm sở hữu độc quyền.
• Dân chủ hóa các dịch vụ - Bằng việc xây dựng các dịch vụ trong phần mềm nguồn mở, việc loại bỏ các hạn chế như các phí có liên quan tới số lượng, đổi mới lớn hơn là có khả năng và cho phép nhiều hơn nhiều các dịch vụ tinh vi phức tạp sẽ được phát triển. Đơn giản là, vì các thành phần như các máy chủ web, các máy tìm kiếm và các khung phát triển là sẵn sàng như các dịch vụ nguồn mở có thể được phát triển trên đỉnh của điều này mà không có nhu cầu phải lo lắng về các thành phần mức thấp hơn đó.

Nguồn mở hơn là đám mây

Norton cũng đã phân tích xu thế tỏa khắp của đám mây và kết luận rằng đặc biệt trong lĩnh vực quản lý rủi ro, một số bước cần phải được tiến hành để chắc chắn rằng các hệ thống và dữ liệu là an ninh và an toàn trong một môi trường đám mây. Kiểm soát và tính trực quan của các hệ thống là ít rõ ràng hơn nhiều trong môi trường đám mây, và việc kiểm toán các qui trình cần phải hiện diện để đảm bảo điều này được giải quyết đúng đắn phù hợp.

Thách thức khác là tính tương hợp và tính khả chuyển của các giải pháp đám mây, chúng vẫn còn là đang được phát triển. Các sáng kiến như OpenStack và Apache CloudStack phát triển các giải pháp và các cộng đồng thú vị để giải quyết các vấn đề đó.

Cuối cùng, báo cáo đưa ra một phân tích để thông báo cho quản lý CNTT cách biến đổi từ các hệ thống đóng sang mở. Nó đề cập tới một số các lo ngại thực tế có thực mà các nhà quản lý có thể có và giúp họ hiểu cách tận dụng một số lợi ích của nguồn mở. Một phần quan trọng của điều này là tập trung vào nhân viên và nhu cầu huấn luyện các nhân viên và để cho họ làm quen với hệ thống mới và hiểu được công nghệ. OSS Watch đã cung cấp một số tài nguyên có thể giúp bạn hiểu được đổi mới mở trong phần mềm (bản dịch tiếng Việt). Hãy tự nhiên liên hệ nếu bạn muốn tìm thấy nhiều hơn. Về cộng đồng liên hệ với Sander van der Waal. Hãy đánh dấu liên kết này.

Người ta nghĩ về “Nguồn mở vẫn phù hợp cho các hệ thống nghiệp vụ sống còn”.

Open source is business-ready. Not just for smaller companies that are looking for a simple CMS, but also for business-critical systems with high-volume traffic. This is not really news, and the examples are well-known, such as the use of Linux at the London Stock Exchange. But an interesting report (pdf) by Jim Norton, former president of the BCS, recently reinforced this message and it is an interesting read. For one, the report had been sponsored by Amadeus, a technology provider to the travel industry. As Glyn Moody rightly notes, this is not a company that has an interest in supporting a particular technological viewpoint, but is focusing on providing real solutions.

Benefits of open source systems

The report lists benefits of open source that are relevant to different kinds of stakeholders. Specifically for enterprise customers, Norton notes that open systems provide:

• Access to greater innovation – A self-reinforcing open community has emerged of shared research and development that customers of open source software can tap into.
• Improved supplier responsiveness – Access to an open community allows much better response time for problems. A customer is no longer dependent upon one supplier to respond adequately and timely, but has a wide community of people that may help out when there are problems.
• Enhanced system accessibility – There is a wide variety of systems that has been developed openly over the last few decades. This enables customers to use and continue to use systems if they have the required expertise available. Customers do not need to depend on supplier-demanded software life cycles.

When focusing more on end consumers, the following added benefits are highlighted:

• Greater choice and depth of services – Norton argues that certain services that are available for open source have simply not been financially viable under the economic model of proprietary software
• Democratisation of services – By building services on open source software, removing limitations such as volume-related fees, greater innovation is possible and enables much more sophisticated services to be developed. Simply put, because components such as web servers, search engines and development frameworks are available as open source services can be developed on top of this without the need to worry about these lower level components.

Open source rather than cloud

Norton also analysed the pervasive trend of cloud and concludes that specifically in the area of risk management, some steps need to be taken in order to make sure that systems and data are secure and safe in a cloud environment. Control and visibility of systems are much less clear and obvious in a cloud environment, and auditing processes need to be in place to ensure this is properly addressed.

Another challenge is the interoperability and portability of cloud solutions, which is still very much under development. Open initiatives such as OpenStack and Apache CloudStack develop interesting solutions and communities that address these issues.

Finally, the report provides an analysis to inform IT management how to make transition from closed to open systems. It addresses some of the real practical concerns IT managers may have and helps them understand how to harness some of the benefits of open source. One important part of this is the focus on staff and the need to train staff and make them familiar with the new system and understand the technology. OSS Watch has provided a number of resources that can help you understand open innovation in software. Feel free to get in touch if you would like to find out more.

Community by Sander van der Waal. Bookmark the permalink.

One thought on “Open source still suitable for business-critical systems”

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Chương trình pha 2 về Môi trường Nghiên cứu Ảo của JISC: Thái độ và Nhận thức về Phát triển Mở

The JISC Virtual Research Environment Phase Two Programme: Attitudes to and Awareness of Open Development

By Sander van der Waal, Published: 28 August 2008, Reviewed: 16 April 2012

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

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

Lời người dịch: OSS Watch, một cơ quan tư vấn quốc gia của Anh, được Ủy ban các Hệ thống Thông tin Chung - JISC (Joint Information Systems Committee) cấp vốn để triển khai Chương trình Môi trường Nghiên cứu Ảo với hàng loạt các dự án với nhiều mục tiêu khác nhau, trong đó có mục tiêu hướng các dự án theo mô hình phát triển mở. Bài viết này nói về thái độ và nhận thức về phát triển mở trong các dự án đó. Trong triển khai thực tế tại Anh, các dự án cũng đã bộc lộ ra nhiều điểm yếu, như về nhận thức triết lý và pháp lý và cách tổ chức các dự án, các cộng đồng của các lập trình viên và các cộng đồng người sử dụng. Nó rất gần với những gì đang xảy ra ở Việt Nam hiện nay. Vì thế, những bài học của nó có lẽ rất đáng để chúng ta tham khảo.

Tóm tắt

[Tài liệu này mô tả tình trạng như vào tháng 10/2008]

Nền tảng

OSS Watch là một dịch vụ tư vấn quốc gia cung cấp tư vấn về phần mềm nguồn mở (PMNM) cho các cộng đồng cao đẳng và đại học trong giáo dục. Thẩm quyền bao gồm sự hỗ trợ cho chính sách năm 2004 của JISC về nguồn mở, nó đã thiết lập nguyên tắc rằng các dự án do JISC cấp vốn sẽ không chỉ phát hành phần mềm của chúng như là nguồn mở, mà còn tuân theo một tiếp cận phát triển mở (bản dịch tiếng Việt), bao gồm việc tiến hành các bước để tận dụng cộng đồng những người sử dụng và các lập trình viên xung quanh các phần mềm đó.

Đầu năm 2008, OSS Watch đã thắng sự phê chuẩn cho sự lên mức hỗ trợ của họ cho các dự án giáo dục cao đẳng và đại học (HE/FE) của Anh, giúp họ triển khai chính sách này và đặt họ vào vị thế tốt hơn nhiều để hiện thực hóa đầy đủ các lợi ích của nguồn mở như một kết quả. Nghiên cứu này từng được ủy nhiệm vào cuối năm 2008 để giúp thông báo công việc mới thông qua việc nghiên cứu điều tra mức nhận thức hiện hành, thái độ và sự hiểu biết về khái niệm phát triển mở trong cộng đồng đổi mới của JISC.

Các dự án được lựa chọn cho nghiên cứu điều tra từng là 4 dự án được cấp vốn trong chương trình Nghiên cứu Môi trường Ảo – VRE (Virtual Research Environment) Pha 2 của JISC, nó đang phát triển phần mềm đổi mới cho cộng đồng nghiên cứu của Anh. Phương pháp luận của nghiên cứu đã kết hợp các cuộc phỏng vấn mặt đối mặt với một thảo luận dạng nhóm có trọng tâm. Phân tích lần đầu tiên đã định lượng và xem xét ới các kinh nghiệm của riêng các tác giả quản lý các dự án do JISC cấp vốn để làm cân bằng giữa các ý tưởng của nguồn mở ở một phía và các thực tiễn thực tế ở phía kia. Bản thân đội của OSS Watch cũng đã không trực tiếp tham gia trong việc thiết kế danh sách các khuyến cáo.

Các phát hiện và khuyến cáo

Nghiên cứu đã phát hiện 4 dự án cực kỳ tích cực về nguồn mở và nhiệt tình, nhắc lại cho những người tiêu dùng về PMNM. 2 trong số 4 dự án đó được phỏng vấn đã có các kho mã nguồn truy cập được một cách công khai và thậm chí cho những ai còn chưa được cam kết chắc chắn đối với việc phát hành các phần mềm của họ như là nguồn mở.

Đa số đã chỉ gần đây trở nên nhận thức được về phát triển mở như một tiếp cận và có nhu cầu khuyến khích các bên thứ 3 đóng góp mã và tài liệu trong vòng đời của dự án. Khi không có dự án nào từng rõ ràng mời những đóng góp, từ quan điểm của phát triển mở, chúng có thể được coi như là cơ bản là các phát triển đóng.

Thiểu số các dự án đã nghi ngờ về khả năng áp dụng của phát triển mở đối với các dự án của họ, tự coi họ nhiều hơn ở mức kiểm thử một khái niệm hơn là việc phát triển phần mềm có chất lượng sản xuất. Thậm chí những người mà thấy nhu cầu đã thể hiện các mối quan tâm đáng kể xung quanh tổng chi phí của việc quản lý qui trình chấp nhận và điều tiết những đóng góp, đưa ra rằng họ đã không cấp vốn cho nó trong các đề xuất dự án của họ. Bất chấp điều này, nhiều người đã bày rỏ một mong muốn thực sự được giáo dục xa hơn về điều này.

Danh sách các khuyến cáo đã đưa ra để giải quyết sự thiếu nhận thức xung quanh nhu cầu về thực tiễn tuân theo một tiếp cận phát triển mở. Thông tin được chỉnh sửa cho các hoàn cảnh đặc thù của các dự án do JISC cấp vốn từng là một chủ đề lặp đi lặp lại, như như cầu giáo dục những người viết thầu và ghi điểm thầu ở giai đoạn sớm nhất có thể. Cũng được khuyến cáo rằng OSS Watch xem xét các cách thức khác mà vấn đề này có thể mang lại được sự chú ý đối với cộng đồng JISC thông qua, ví dụ, việc xem xét những khuyến khích và những thay đổi chính sách có khả năng và thông qua việc triển khai các hội thảo để giải quyết các quan ngại đôi khi đã nằm sâu trong các dự án khi nói về 'đi với nguồn mở'.

Nền tảng

OSS Watch đưa ra tư vấn về một loạt rộng rãi các chủ đề xung quanh sự áp dụng và phát triển PMNM đối với các cộng đồng giáo dục cao đẳng và đại học. Vào khoảng giai đoạn khi mà chương trình 2 của VRE đã bắt đầu, cơ quan dịch vụ này đã bắt đầu nắm lấy vai trò tích cực hơn trong việc giúp các dự án phát triển của JISC triển khai đầy đủ chính sách nguồn mở của JISC với một sự nhấn mạnh đặc biệt vào sự phát triển cộng đồng.

Báo cáo này thể hiện kết quả của các nỗ lực thông báo công việc 'dự án nhúng' vào này bằng việc nghiên cứu điều tra trước hết cách mà các dự án phát triển phần mềm do JISC cấp vốn hiện hành đã từng thàng công trong việc tạo các cộng đồng, bằng việc sử dụng chương trình VRE Pha 2 của JISC như một ví dụ, và thứ 2 là các cách thức theo đó qui trình này có thể được làm dễ dàng, có hoặc không có sự hỗ trợ của OSS Watch.

OSS Watch và chính sách nguồn mở của JISC

OSS Watch đã được thành lập vào năm 2003 như một dịch vụ tư vấn thí điểm nhỏ với một quyền hạn ban đầu hạn chế tới việc thiết lập và duy trì một website, việc tổ chức các hội nghị và hội thảo quốc gia và cung cấp chỉ dẫn cho các viện trường theo yêu cầu. Khi nó được 6 năm, nó đã chuyển từ đối tượng thuần túy giáo dục này thành một trong những tổ chức hỗ trợ và chỉ dẫn tích cực. Ví dụ, OSS Watch, ở những nơi có thể, đã bắt đầu tham gia và đóng góp cho tất cả chương trình JISC khởi tạo các sự kiện, tiến hành nhiều cuộc trao đổi ý kiến với các dự án và xuất bản các trường hợp điển hình về một dải các dự án phát triển nguồn mở tích cực.

Vào năm 2004, OSS Watch đã phác thảo một chính sách nguồn mở cho JISC để trả lời cho Chính sách PMNM của Chính phủ Anh 1. Đáng nhớ nhất, điều này đã thiết lập nguyên tắc rằng, mặc định, các dự án phát triển phần mềm của JISC sẽ phát hành các phần mềm của họ theo một giấy phép nguồn mở được Sáng kiến nguồn mở – OSI (Open Source Initiative) phê chuẩn, tinh chỉnh yêu cầu hiện hành cho các kết quả đầu ra của dự án sẽ được làm sẵn sàng một cách tự do cho các cộng đồng giáo dục cao đẳng và đại học. Ít đáng kể hơn, chính sách cũng đã thiết lập các chỉ dẫn về phát triển mở, khuyến cáo rằng các dự án nắm lấy các bước nuôi dưỡng các cộng đồng các lập trình viên (và những người sử dụng) xung quanh các phần mềm của họ:

4.9 Tính bền vững và các cộng đồng

Nhiều dự án nguồn mở được nỗ lực cộng đồng hỗ trợ, và JISC khuyến khích sâu sắc sự tham gia và đóng góp rộng rãi cho các dự án nguồn mở.

• Các dự án phải nói trong lời thầu của họ liệu họ có nhìn thấy trước dự án tiếp tục được vượt ra khỏi khoảng thời gian được cấp vốn hay không, và nếu có thì họ thấy ai sẽ tham gia vào dự án đó.
• Các dự án sẽ cam kết với những người sử dụng đầu cuối và các bên khác sẽ khuyến khích và xây dựng các cộng đồng tự duy trì bền vững.
• Các dự án sẽ tạo thuận lợi cho sử dụng phần mềm của họ trong các cơ sở khác của HE và FE của nước Anh.
• Các dự án có thể tạo thuận lợi cho sử dụng các phần mềm của họ trong cộng đồng rộng lớn hơn [23].
• Các dự án sẽ chấp nhận các báo cáo lỗi, các bản vá, các bản dịch và các ý kiến phản hồi từ những người đóng góp bên ngoài dự án.

- Chính sách về PMNM cho các dự án và dịch vụ của JISC

Ý định từng là đối với các dự án phải thiết lập, thông qua các cộng đồng người sử dụng và lập trình viên của họ, một mức hỗ trợ đủ cho họ để chuyển vượt ra khỏi các pha ban đầu của họ với ít sự dựa dẫm vào việc cấp vốn tiếp tục.

Môi trường Nghiên cứu Ảo Pha 2 của JISC

Chương trình Môi trường Nghiên cứu Ảo Pha 2 (VRE2) của JISC từng là một trong khoảng 30 chương trình của JISC phát triển và thí điểm phần mềm cho HE/FE. Theo website của JISC, một VRE 'giúp các nhà nghiên cứu trong tất cả các nguyên tắc quản lý dải phức tạp ngày một gia tăng các tác vụ có liên quan trong việc triển khai nghiên cứu'. VRE2 đã tiếp tục từ VRE1, một chương trình thí điểm lớn hơn và nhiều hơn, và đã được làm từ 4 dự án phát triển thí điểm các môi trường nghiên cứu ảo để hỗ trợ cho các nhu cầu của các nhà nghiên cứu nước Anh.

Dự án VRE cho Nghiên cứu các Tài liệu Cổ (VRE-SDM) đang xây dựng các cơ sở cho các nhà nghiên cứu nằm rải rác về địa lý để truy cạp và chú giải các bộ sưu tập ảnh. Dự án VRE cho Khảo cổ học (VERA) đang phát triển và thí điểm một VRE với sự đào sâu nghiên cứu Thành phố La mã cổ Silchester để cải thiện các phương tiện làm tài liệu các khai quật khảo cổ học một cách có hiệu quả và các chế tác có liên quan của nó. MyExperiment đang tạo ra một mạng xã hội cho các nhà khoa học dựa vào, nhưng không bị hạn chế tới, việc chia sẻ và thực hiện các tiến trình công việc. Dự án Nghiên cứu cộng tác Các sự kiện trên Web (CREW) đang tạo ra một VRE để nắm bắt và xuất bản cho cộng đồng bác học diễn ra tại và xung quanh các sự kiện nghiên cứu.

Thậm chí trong chương trình khá nhỏ này, các dự án giải quyết một núi các nhu cầu lạ thường, một số tập trung vào một miền nghiên cứu duy nhất, số khác thì tương đối chung về phạm vi. Hồ sơ dự án của JISC như là tổng thể chia sẻ sự đa dạng này và, kết quả là, hầu hết không có khả năng chọn ra một chương trình đại diện hoặc một tập hợp các dự án. Nói vậy, có những đặc tính nhất định rằng các dự án của JISC thường chia sẻ. Đối với một người, việc bổ sung vào các dự án của họ cho FE và HE của nước Anh, họ cũng thường do các cơ quan của HE hoặc FE của nước Anh quản lý, thường là những cơ quan của những người trong các dịch vụ điện toán hoặc các phòng khoa học máy tính. Thứ 2, toàn bộ các dự án của JISC có xu hướng sẽ chạy dưới những ràng buộc tương tự nhau về chi phí và thời gian: ngân sách thường là dưới 500.000 £ và chạy cho 1 hoặc 2 năm. Thứ 3, các dự án thường phân tán về địa lý với các đội dự án riêng rẽ chia khắp nhiều viện trường của nước Anh. Tính tới tất cả những điều này, thì chương trình VRE2 là không khác gì.

Những lợi ích của phát triển mở

Những lợi ích của nguồn mở từng được ghi tốt lại thành tài liệu. Tuy nhiên, một số lợi ích được báo cáo có thể còn gây tranh cãi đang tồn tại ngang bằng, nếu không nói là lớn hơn, so với các phát triển nguồn đóng. Ví dụ, sự tồn tại của các cộng đồng người sử dụng tích cực đóng góp tài liệu, kinh nghiệm và tư vấn cho những người sử dụng khác, chắc chắn không là duy nhất cho nguồn mở.

Ưu điểm thực sự mà các dự án nguồn mở có là khả năng của chúng để tận dụng các tài nguyên của vô số các cá nhân và tổ chức để phát triển phần mềm tiếp, thông qua một dạng rà soát lại ngang hàng đơn giản không tồn tại với nguồn đóng. Tuy nhiên, ưu thế này được báo trước rõ ràng về sự tồn tại của các cộng đồng tích cực các lập trình viên cũng như các cộng đồng tích cực của những người sử dụng.

Sự hình thành các cộng đồng không xảy ra một cách tự động chỉ vì phần mềm được phát hành như là nguồn mở. Nếu các dự án muốn thiết lập chúng, họ cần tiến hành các bước tích cực để nuôi dưỡng chúng thông qua suốt đời dự án. Trong khi mục tiêu tối thượng là một cộng đồng các lập trình viên tích cực, thì các cộng đồng người sử dụng tất nhiên là quan trọng sống còn cho cả 2 vì không có người sử dụng người sử dụng thì dự án có thể không có lý do để tồn tại, và vì thế các cộng đồng người sử dụng cũng có khả năng đại diện cho hầu hết các nguồn các lập trình viên trong tương lai, hoặc thông qua những người sử dụng tham gia trực tiếp vào hoặc thông qua những người làm của họ để làm thế nhân danh họ. Hệ quả là, điều quan trọng là các cộng đồng người sử dụng được hỗ trợ và tiếp tục lớn lên.

Qui trình lôi kéo những người sử dụng mới vào có thể đại diện cho một thách thức đối với các dự án đang làm thỏa mãn các nhu cầu được số lượng người khá nhỏ chia sẻ. Và thậm chí đối với các dự án đang giải quyết các nhu cầu được cầm giữ rộng lớn hơn, nếu điều này cũng có nghĩa là việc xử trí các thách thức kỹ thuật đáng kể, thì nó có lẽ dường như có ý nghĩa nhiều hơn để giữ cho cộng đồng khá nhỏ một cách hợp lý những người sử dụng ban đầu, trong khi khái niệm được kiểm thử, hơn là rủi ro làm hỏng uy tín của dự án bằng việc phát hành phần mềm mà không làm việc được.

Những người sử dụng không chỉ là nguồn của các lập trình viên tiềm tàng. Những người làm việc trong các cộng đồng kỹ thuật đặc thù hoặc làm việc trong các tiêu chuẩn kỹ thuật có thể muốn trở thành có liên quan và sử dụng phần mềm như một động cơ cho một công nghệ đang nổi lên. Điều này có thể là một tình huống 2 bên cùng thắng win - win. Tuy nhiên, có một rủi ro là nếu những người đó bắt đầu đông hơn những người sử dụng đầu cuối, thì đội dự án như là tổng thể đánh mất đi tầm nhìn mục tiêu ban đầu của mình và trở thành một bài tập hàn lâm: tất cả đều là các lập trình viên và không có người sử dụng.

Đạt được một sự thỏa hiệp có thể cảm nhận được

OSS Watch không phải là một tổ chức bảo vệ và không thúc đẩy nguồn mở như vậy; ngược lại, nó cung cấp sự tư vấn không thiên vị về việc các viện trường có thể làm thế nào đối với việc áp dụng hoặc phát triển nó. Đã nói rằng, ở những nơi các dự án phát triển phần mềm chọn đi xuống con đường nguồn mở, thì OSS Watch bảo vệ việc ôm lấy khái niệm đó hoàn toàn, bao gồm cả việc tiến hành các bước hướng tới việc phát triển các cộng đồng xung quanh phần mềm và không chỉ 'việc đánh đống mã' cho nó trong một dịch vụ đặt chỗ nguồn mở tới cuối cùng. Điều này không nói rằng OSS Watch khuyến cáo tất cả các dự án sẽ chạy như những nền dân chủ dựa vào sự đồng thuận. Phát triển mở không phải là một lĩnh vực hoặc tất cả hoặc không gì cả: có khả năng là mở trong khi giữ lại những yếu tố kiểm soát.

Một số bước hướng tới sự phát triển mở có khả năng sẽ là (hoặc được thừa nhận sẽ là) có khả năng đạt được hơn so với những bước khác.

Phương pháp luận

Công việc theo lĩnh vực được tiến hành cho nghiên cứu này có ở dạng một loạt các cuộc phỏng vấn bán cấu trúc với 4 dự án VRE2 giữa tháng 1 tới tháng 4/2008, được bổ sung với một phiên gặp của chương trình VRE2 vào tháng 5/2008.

Các cuộc phỏng vấn

Các cuộc phỏng vấn đã được thiết kế để xem xét các thái độ quan điểm của từng dự án riêng rẽ, hiểu được và tiến bộ hướng tới việc triển khai phát triển mở, các rào cản ngăn cản điều đó và các cách thức theo đó sự phát triển mở có thể được thực hiện dễ dàng hơn, cả có và không có sự hỗ trợ của OSS Watch.

Tiếp cận được sử dụng cho cuộc phỏng vấn (chung) đầu tiên với VERA và VRE-SDM từng khá là để thăm dò và đã tập trung vào các thái độ của 2 dự án và hiểu về khái niệm phát triển mở. Cuộc phỏng vấn thứ 2 với MyExperiment đã diễn ra như một phần của một cuộc gặp dự án đang tồn tại và ít thời giản đã được bỏ ra để khai thác thái độ và nhiều hơn thời gian vào sự tiến bộ thực sự với sự phát triển cộng đồng, đặc biệt ở phía của những người sử dụng. Để cải thiện phạm vi đạt được, một cuộc phỏng vấn theo lối chính thống 2 đã được phác thảo và được sử dụng để chỉ dẫn cho cuộc phỏng vấn cuối cùng với CREW.

Chủ đề của sự phát triển cộng đồng về bản chất tự nhiên tự bản thân nó được chia thành những người sử dụng ở một phía và các lập trình viên ở phía kia, trong khi công nhận những chồng lấn giữa cả 2. Đối với cả 2 cộng đồng, thường thì có ý nghĩa để phân biệt giữa “bạn bè và gia đình” - những người được tuyển mộ trong giai đoạn viết thầu - và những người không biết hoặc không liên quan ban đầu với dự án. Các hoạt động với nhóm sau từng không thể tránh khỏi nhiều hơn về sự cam kết tham gia hơn là sự phát triển: giữ cho họ vẫn tham gia và hạnh phúc. Các quyết định về cách mà các dự án đã lôi cuốn được mối quan tâm từ bên ngoài đã dẫn tới các câu hỏi về cách mà các dự án đã tự bản thân họ ra được thị trường với những người sử dụng và cộng đồng kỹ thuật tiềm năng, bao gồm cả các dự án VRE2 và các nhóm đang phác thảo các tiêu chuẩn mở.

Dù ban đầu không có ý định như một chủ đề chính cho thảo luận, thì vấn đề cấp phép phần mềm và các dàn xếp pháp lý thường xuyên có thu hoạch, nhất là vì việc chọn một giấy phép phù hợp và cấu trúc pháp lý thường được thể hiện rào cản trung gian nhất cho việc mở ra sự phát triển.

Phiên gặp của chương trình VRE

Phiên gặp của chương trình đã nhằm vào để khêu gợi thảo luận và đi tới một số dạng đồng thuận về hành động có thể đối với OSS Watch. Nó dài 1 giờ, với nửa đầu đã dành cho việc trình bày các phát hiện từ các cuộc phỏng vấn, và nửa sau ở dạng của một thảo luận xung quanh chủ đề phát triển mở, cách có thể đạt được đối với các dự án của JISC, và cách mà nó có thể được làm cho dễ dàng hơn thông qua công việc của OSS Watch. Phiên toàn thể liệt kê các gợi ý cho OSS Watch đã được thảo luận và bổ sung thêm sau và được tinh chỉnh. Cuối cùng, những người tham gia đã có khả năng chỉ ra những gì họ cảm thấy là gợi ý số 1 của họ cho OSS Watch.

Những phát hiện

Thái độ và nhận thức

Về tổng thể, các dự án để thể hiện một thái độ tích cực áp đảo đối với nguồn mở. Như là những người tiêu dùng thường xuyên của PMNM, các dự án thấy nguồn mở như một điều tốt lành về tổng thể và tất cả đã cam kết phát hành phần mềm theo một giấy phép nguồn mở do OSI phê chuẩn. Mặt khác, nhận thức của các dự án và sự hiểu biết về phát triển mở từng ít ổn định hơn. Một người trả lời nói, 'Tôi chỉ từng nghe một đồn đại thực tế về phát triển mở trong cộng đồng JISC vào khoảng năm ngoái. Hãy đưa lên khi chúng tôi đặt vào các vụ thầu'.

Sự phát triển của cộng đồng những người sử dụng

Lời kêu gọi của VRE2 đã truyền lệnh cho một tiếp cận phát triển hướng tới người sử dụng, đưa ra một mô hình 'hình số 8' (xem hình) dựa vào các phương pháp phát triển phần mềm lanh lẹ và có sự tham gia. Kết quả là, tất cả các dự án của VRE2 được cam kết mạnh mẽ cho sự tham gia của cộng đồng những người sử dụng theo nghĩa là hiểu các nhu cầu của những người sử dụng của chúng và làm việc sát sao với họ khi phát triển phần mềm.

Từ một triển vọng của phát triển mở, điều này rõ rằng là điều tốt lành: người sử dụng sẽ quay đi nếu các nhu cầu của họ không được thỏa mãn, và không có người sử dụng thì không có dự án.

Vì mô hình phát triển phần mềm ngược với một mô hình phát triển cộng đồng, 'hình số 8' giả thiết cộng đồng người sử dụng là đã có ở đó, chờ được tham gia vào và không đặt ra nhiều sự nhấn mạnh vào việc lôi kéo những người sử dụng mới. Các dự án VRE2 tất cả đều đã có các cộng đồng người sử dụng được viết bên trong chúng với những nỗ lực ban đầu và thực sự của họ đã được làm để giữ cho họ tham gia vào và có quan tâm.

MyExperiment từng chỉ là dự án đã thực hiện các cố gắng đáng kể để tuyển mở những người sử dụng mới, nhưng điều này từng thẳng hơn đáng kể đối với họ vì phần mềm của họ đã có khả năng truy cập được như một ứng dụng 'web 2.0' được đặt chỗ. CREW và VRE-SDM vẫn còn ở trong giai đoạn kiểm soát truy cập tới phần mềm thông qua các phiên kiểm thử khả năng sử dụng 'chỉ ra và nói' được quản lý một cách cẩn thận; đối với chúng đơn giản là quá sớm để làm cho phần mềm thường là sẵn sàng - những người sử dụng cần một mức độ nhất định 'cầm tay chỉ việc'. VERA từng tăng tốc cho Silchester vào mùa hè 2008, khi đó những người sử dụng của họ có thể có cơ hội đầu tiên của họ trợ giúp cho công nghệ được phát triển.

Phát triển cộng đồng lập trình viên

không có dự án nào thực sự đã xem xét việc mở ra sự phát triển vượt ra khỏi các đội cốt lõi của họ trong các giai đoạn cấp vốn ban đầu. Một bình luận đại diện đã được một người quản lý kỹ thuật thực hiện từng là, 'chúng tôi không có kế hoạch cho việc mở nó ra như một sự phát triển nguồn mở. Điều đó không để nói chúng tôi cho thể loại trừ điều đó'.

Việc đặt ra các tư liệu

Bước quan trọng nhất trong việc mở ra sự phát triển là làm cho phần mềm sẵn sàng sao cho các lập trình viên khác có thể 'chơi' với nó được. Tuy nhiên, điều này không chỉ là về việc đặt mã nguồn lên một website hoặc trao sự truy cập công khai tới hệ thống kiểm soát phiên bản. Thường được thừa nhận chung rằng các lập trình viên (và những người sử dụng) có khả năng hơn nhiều để tham gia vào nếu phần mềm được làm cho sẵn sàng như một phát hành với một số tuyên bố về chất lượng có liên quan. Ví dụ, là nó sẽ biên dịch và chạy, ít nhất là như vậy.

Hai trong số 4 dự án VRE, MyExperiment và VERA, đã làm cho mã nguồn của chúng sẵn sàng thông qua kiểm soát phiên bản: MyExperiment thông qua RubyForge và VERA thông qua một hệ thống Trac địa phương, dù mã của VERA không truy cập được công khai 3. Tuy nhiên, vì các lý do khác nhau, các dự án đã không triển khai bất kỳ phát hành chính thức nào. Một giải thích cho điều này là các dự án đã không cần phải làm thế để làm cho phần mềm truy cập được tới những người sử dụng của họ. Những người sử dụng MyExperiment hầu như tất cả sử dụng dịch vụ đặt chỗ của dự án (một 'bản beta vĩnh viễn') tại myexperiment.org hơn là việc cài đặt các bản sao cục bộ; VERA, CREW và VRE-SDM vẫn còn kiểm soát truy cập đối với phần mềm.

Nhìn vượt ra khỏi điều này, các dự án đã thể hiện một sự ngại ngùng cơ bản về việc lôi cuốn các lập trình viên của bên thứ 3 và đặt phần mềm của họ ra theo cách này. Đã có cảm giác rằng các dự án của họ đơn giản không 'đủ lớn và đủ phổ biến' cho điều đó trở nên đáng làm. Một dự án nói, 'Bạn phải có đủ người sử dụng phần mềm để làm cho điều đó sống sót được'. Cũng đã có sự sợ hãi rằng việc đặt phần mềm mở ra cho các lập trình viên tới một số lượng nhất định sự cởi mở và đã có cảm giác từ một dự án rằng 'sự minh bạch đó có thể hạn chế các lập trình viên'. Trong cuộc gặp của chương trình VRE, sự sợ hãi đó đã được khai thác tiếp.

Lo ngại khác từng là bằng việc mở ra sự phát triển, các dự án có thể đánh mất một yếu tố kiểm soát và thậm chí dấu ấn có liên quan tới việc được cấp vốn để phát hành dự án trước. Cũng có lo ngại rằng những người khác có thể thay đổi đường lối của dự án gây hại cho cộng đồng người sử dụng đầu cuối. Tất cả các dự án đã dường như ưa thích hơn mô hình Linux: nơi mà họ kiểm soát được phần cốt lõi và các công cụ phát triển của những người đóng góp bên thứ 3 ở xung quanh.

ngược về dự án.

Áp dụng và quản lý các đóng góp

Làm cho các phát hành sẵn sàng sẽ cho phép các lập trình viên 'chơi' với phần mềm. Những gì nó cung cấp là các cơ chế để cho phép những thay đổi sẽ được đóng góp ngược trở lại vào dự án.

Ở mức này hay mức khác, các dự án VRE2 đã nhận thức được rằng việc triển khai các phát hành là một phần cần thiết của việc mở ra sự phát triển. Tuy nhiên, những gì họ đã không mong đợi phải làm là phát hành phần mềm của họ bất kỳ lúc nào sớm hơn lúc cuối cùng. Trong khi các dự án từng rất mở về ý tưởng phát triển mở, cùng một lúc chúng cũng đã thể hiện nhưng lo ngại thực sự về tổng chi phí của việc quản lý qui trình chấp nhận các đóng góp trên đỉnh của việc phát hành bản thân phần mềm. Một người quản lý kỹ thuật đã bình luận, '[Tổng chi phí này] không là nhân tố trong dự án này và tôi đã không tính tới nhân tố đó trong bất kỳ vụ thầu nào mà tôi đã viết'. Người khác nói, 'Việc quản lý và thông báo mã khi những người khác đang đóng góp là nhiều công việc hơn là tự bạn viết mã'.

Kết quả của sự bất đắc dĩ này, không dự án nào đã có các kế hoạch cụ thể cho việc mở ra sự phát triển, không website của lập trình viên nào chuyên tâm và không có chỉ dẫn nào về cách để đóng góp. Bất chấp điều này, đã có 2 dự án – MyExperiment và VERA - đã đồng ý cho các bên bên ngoài phát triển các công cụ và các trình cài cắm. MyExperiment, bằng việc phát hành một “RESTful”, API, thậm chí đã và đang ngấm ngầm mời chào điều này và các ví dụ của 'mash-up' tích hợp chức năng đã tồn tại của MyExperiment ở dạng của 3 Google Gadgets. Tuy nhiên, MyExperiment thừa nhận, rằng họ đã cần một chiến lược cho các trình cài cắm sao cho những người xây dựng chúng có thể biết 'khi nào thì đưa chúng vào'.

Một cách khác theo đó các dự án đã hy vọng mở ra từng là bằng việc đưa ra các thành phần phụ như là các dự án nguồn mở theo các quyền của riêng chúng. VERA đã có, như một phần của những nỗ lực của họ để tích hợp các ứng dụng dùng ngay được như Wordpress và MediaWiki vào cổng của họ, đã phát triển một thành phần phần mềm trung gian có tên là 'RecycleBridge' để tạo thuận lợi cho điều này. CREW đã nói có mong muốn đưa ra một thành phần ghi chú dựa vào RDF được tích hợp đã chia sẻ nó với 2 dự án khác do JISC cấp vốn tại Viện Công nghệ Học và Nghiên cứu – ILRT (Institute for Learning and Research Technology) của Đại học Bristol. Trong cả 2 trường hợp, nó từng cảm thấy rằng bằng việc đưa ra các thành phần đó, họ có thể được làm phù hợp cho một nhóm rộng lớn hơn nhiều những người sử dụng và có một cơ hội tốt hơn để lôi cuốn các lập trình viên từ các cổng và các cộng đồng web một cách tương ứng.

MyExperiment cũng đã cam kết với các cộng đồng kỹ thuật, nhưng là duy nhất trong số các dự án VRE2 theo đó họ đã quyết định không ôm lấy các cổng như là công nghệ trình bày chính của họ. Tuy nhiên, họ đã nêu tham vọng đưa ra một hoạt động của cổng song song với dự án chính. MyExperiment đã cam kết với cả World Wide Web Consortium và các cộng đồng các kho số thông qua sự phát triển của họ đối với các Đối tượng myExperiment được Bọc gói - EMO (Encapsulated myExperiment Objects) được thiết kế để tích hợp với tiêu chuẩn OAI-ORE 4 đang nổi lên. MyExperiment cũng đã cộng tác với dự án SKUA được JISC cấp vốn để khai thác sử dụng Open Social 5 như một đường cộng tác có khả năng. Bằng cách làm như vậy, dự án SKUA đã trở thành dự án đầu tiên và duy nhất cài đặt MyExperiment một cách cục bộ thay vì sử dụng dịch vụ đặt chỗ.

Tính bền vững và các kế hoạt thoát ra

Tiếp cận chung của các dự án về tính bền vững hoặc để tìm kiếm cấp vốn bổ sung vào cuối của dự án hoặc để nghiên cứu các cơ hội khai thác thương mại. Như một quản lý kỹ thuật đã bình luận, 'Kế hoạch về tính bền vững đang được xem như là đủ đối với sự thành công sớm hơn trong dự án mà chúng tôi có cơ hội đấu thầu để có thêm tiền'.

Những gợi ý từ các dự án đối với OSS Watch

Nhiều gợi ý đã được các dự án đưa ra từng có liên quan tới sự cung cấp thông tin. Tuy nhiên, đã không có nhiều thông tin hơn từng là cần thiết; từng nhiều hơn sự phong phú của thông tin đang có sẵn được chỉnh sửa cho những hoàn cảnh đặc biệt của các dự án do JISC cấp vốn. Ví dụ, trong khi OSS Watch đã xuất bản nhiều trường hợp điển hình nguồn mở, thì vẫn chỉ có một trường hợp đã chỉ ra cách một dự án 6 đang tồn tại được JISC cấp vốn là thành công tuân theo một tiếp cận phát triển mở. Việc xuất bản các ví dụ tương tự nhiều hơn từng là gợi ý phổ biến nhất cho tới nay vì, như câu của một người quản lý kỹ thuật, 'Luôn dễ dàng hơn để chơi theo người cầm đầu của tôi'.

Ví dụ khác về việc tùy biến này từng là gợi ý về việc cung cấp các mô hình điều hành mẫu template và các thỏa thuận giấy phép của những người đóng góp. OSS Watch đã có rồi các nguồn về việc phác thảo các tài liệu đó, nhưng các dự án cảm thấy rằng nhiều thời gian có thể tiết kiệm được bằng việc cho phép các dự án có được các tài liệu soạn sẵn cho các hoàn cảnh đặc thù của họ. Điều này đã trợ giúp cho việc ra quyết định cũng có thể đơn giản hóa qui trình lựa chọn bản thân giấy phép nguồn mở. Thay vì việc dựa vào tư vấn chung chung, các dự án có thể được chỉ dẫn thông qua một loạt các kịch bản cho phép họ khai thác các rủi ro, các chi phí và lợi ích của việc đưa ra các quyết định cấp phép khác nhau. Cùng lúc, cũng đã có gợi ý rằng OSS Watch hoặc JISC có thể đưa ra một dịch vụ tư vấn pháp lý chín muồi đầy đủ cho nguồn mở.

Một khía cạnh xa hơn đối với các gợi ý có liên quan tới thông tin từng là nhu cầu phổ biến sẽ ít thụ động hơn và tích cực hơn nhiều. Bổ sung vào thông tin đang được làm cho sẵn sàng trên website và các RSS feed có liên quan, nên chủ động tích cực đặt ra trước cho những người cần biết nó, đặc biệt là những người viết thầu và những người chấm thầu. OSS Watch, ở những nơi có khả năng, tham gia vào tất cả các cuộc họp của chương trình và thành phố JISC, và các dự án thường được yêu cầu tư vấn với OSS Watch khi họ bắt đầu làm quen. Tuy nhiên, các dự án đã nói rằng thông điệp về phát triển mở đã và đang nhận được quá chậm. Trừ phi những người viết thầu nhận thức được và được giáo dục về nó, phát triển mở có lẽ rất không được lên kế hoạch hoặc dành ngân sách cho.

Không có lượng thông tin, giáo dục hoặc tư vấn nào sẽ giúp một số dự án vượt qua được những sợ hãi có từ lâu nhất của họ về 'đi với nguồn mở'. Đã có gợi ý rằng OSS Watch nên tổ chức các cuộc hội thảo với các dự án để xem xét những lo ngại của họ và cách mà chúng có thể được giải quyết, ví dụ, thông qua việc quản lý có hiệu quả những kỳ vọng của người sử dụng. Một cách giúp các dự án để vượt qua được những nỗi sợ hãi của họ có thể là bằng cách làm việc với họ để đi theo các kịch bản của họ qua tới những cực logic của họ; bằng việc giúp cho các dự án trực quan hóa các kịch bản trong các trường hợp tiềm năng tồi tệ nhất, các rủi ro sẽ được hiểu và xác định tốt hơn.

Một số gợi ý từng ít hơn về trợ giúp cho các dự án riêng rẽ và nhiều hơn về chính sách ở mức độ phòng, viện trường và quốc gia. Ví dụ, có thể một số ngần ngại về việc đặt phần mềm ra sớm hơn sẽ được xử trí qua các phòng và viện trường đặt ra những khuyến khích, theo một số cách thức mà phong trào truy cập mở đã khuyến khích các nhà nghiên cứu đặt cọc các xuất bản phẩm của họ trong các kho của viện trường? Một ý tưởng cơ bản nhưng phổ biến từng là đối với OSS Watch hoặc JISC 'quản lý' thực sự một cộng đồng các lập trình viên nguồn mở cho các dự án của JISC. Điều này có thể cung cấp một kho các lập trình viên và những người đóng góp và giúp đảm bảo rằng tri thức là không bị mất. Được gợi ý thậm chí nếu điều này có thể không làm việc được trong thực tế, thì nó có thể vẫn có giá trị 'thí nghiệm có suy nghĩ' để triển khai.

Kết luận

Thậm chí dù các dự án VRE2 tất cả cam kết phát hành phần mềm của họ như là nguồn mở, thì sự thiếu tài nguyên đối với các lập trình viên, các phát hành chính thức và, trong một số trường hợp, truy cập đọc các kho mã chỉ ra rằng các dự án VRE2 đang không tiến hành phát triển theo một cách thức rất mở. Hệ quả là, chúng đang làm cho ít có khả năng hơn nhiều cho các cộng đồng phát triển để hình thành, duy trì tri thức được các thành viên của đội xây dựng và làm cho các dự án vượt ra khỏi việc cấp vốn ban đầu của chúng.

Các lý do các dự án VRE2 còn chưa ôm lấy phát triển mở dường như có nguồn gốc trong sự kết hợp của sự thiếu nhận thức, tâm lý và thiếu tài nguyên. Nhận thức có liên quan tới cả các bước nào phải tiến hành cũng như tầm quan trọng của việc thực sự tiến hành chúng: liệu chúng có là có bản cho phát triển mở hay chỉ đơn giản là mong muốn. Đối với các bước mà các dự án nhận thức được, dường như có các rào cản tâm lý đáng kể ngăn cản họ khỏi việc tiến hành chúng cả về sự khó khăn được thừa nhận của họ, nỗ lực (chi phí tổng) có liên quan và có khả năng rời ra.

Không có ai được phỏng vấn hoàn toàn phản đối phát triển mở. Tuy nhiên, đã có một số nghi ngờ về cách mà nó được áp dụng thế nào cho các dự án của họ, đặc biệt nơi mà họ thấy các dự án của họ phần nhiều là để kiểm thử một khái niệm hơn là việc tạo ra phần mềm chất lượng sản xuất. Thậm chí như vậy, đa phần đã không phản đối ý tưởng đặt phát triển mở vào thực tế trong các dự án trong tương lai, miễn là chúng có đủ các tài nguyên để làm điều đó và việc triển khai nó sẽ không làm trệch đường của chúng quá nhiều khỏi tác vụ của việc phát triển phần mềm.

Khái niệm phát triển cộng đồng là một phần rất lớn trong chính sách nguồn mở của JISC và các kết quả đầu ra sẽ được phát hành, các cơ chế sẽ được đặt tại chỗ cho sự đóng góp của cộng đồng (những người sử dụng và các lập trình viên) thông qua dự án, và kế hoạch bền vững cho dự án. Tuy nhiên, điều này đã không xảy ra, trong trường hợp của VRE2, trong các dự án cấp vốn thực tế cho toàn bộ chi phí của việc quản lý qui trình phát triển mở. Bài học ở đây là OSS Watch và JISC nên chủ động tích cực hơn với việc giáo dục cộng đồng đổi mới của JISC, đặc biệt những người viết thầu và những người chấm thầu, về tầm quan trọng của việc đưa các yếu tố này vào.

Các khuyến cáo

Danh sách các khuyến cáo được sắp xếp ưu tiên sau đây đối với OSS Watch đã được tính chế từ các cuộc phỏng vấn và phiên họp của chương trình VRE. Bản thân đội OSS Watch từng không trực tiếp có liên quan tới việc thiết kế chúng mà đã, ở những nơi có thể, làm việc với các khuyến cáo đó trong kế hoạch dự án của OSS Watch cho giai đoạn cấp vốn 2008-2010.

Bình luận về tình trạng đã được bổ sung để chỉ ra các hoạt động từng được thực hiện trong từng lĩnh vực và phản ánh tình trạng trong năm 2011.

Khuyến cáo cho OSS Watch	Lý do cơ bản	Tình trạng trong năm 2011
Công khai hóa nhiều hơn các ví dụ của các dự án phát triển mở thành công, đặc biệt các dự án được JISC cấp vốn hoặc các dự án vận hành theo những ràng buộc tương tự.	Cho phép các dự án chơi theo kiểu 'đi theo người đi đầu của tôi'.	Đã xuất bản một số trường hợp điển hình (bản dịch tiếng Việt) đặc thù của các dự án được cấp vốn.
Triển khai nghiên cứu khả thi trong khả năng thiết lập cộng đồng phát triển nguồn mở được quản lý cho các chương trình đổi mới của JISC.	Như một phương pháp có khả năng tính mất mát về tri thức từ việc cấp vốn ngắn hạn và sự luân chuyển nhân viên.	Nằm ngoài phạm vi công việc hiện hành của chúng tôi. Chúng tôi chỉ là đơn vị dịch vụ tư vấn. Làm việc với JISC và các nhà cấp vốn khác để xem xét các lựa chọn.
Đưa ra các cơ sở hỗ trợ ra quyết định thông qua website của OSS Watch để đưa các dự án đi qua các kịch bản khác nhau khai thác các rủi ro, chi phí và lợi ích của việc chọn các quyết định cấp phép phần mềm khác nhau.	Làm cho dễ dàng hơn đối với các dự án để chọn một giấy phép, cần thiết trước khi chúng có thể mở ra.	Chọn giấy phép được kết hợp vào công việc tư vấn.
Đưa ra các mô hình điều hành mẫu template và các thỏa thuận giấy phép của người đóng góp được tùy biến cho các dự án được JISC cấp vốn.	Loại trừ rào cản chính có liên quan tới việc đưa chúng vào thực tế sẵn sàng.	CLA mẫu từ Đại học Oxford là sẵn sàng theo yêu cầu. Các tài liệu các mẫu template mô hình điều hành (bản dịch tiếng Việt) đã được phát hành.
Giáo dục cộng đồng đổi mới của JISC, và đặc biệt những người viết thầu và những người chấm thầu, về tầm quan trọng sử dụng các dịch vụ đặt chỗ nguồn mở bên ngoài.	Bằng việc sử dụng các dịch vụ đặt chỗ ở ngoài, các bên thứ 3 có khả năng hơn để thấy các dự án là mở thực sự. Nó cũng loại trừ rủi ro mà các máy chủ dự án tái mục đích khi việc cấp vón của JISC kết thúc.	Làm việc với JISC để đảm bảo các dự án thấy được tư vấn từ OSS Watch trong quá trình viết thầu (bản dịch tiếng Việt). Một danh sách kiểm tra các vấn đề phải xem xét trong khi viết thầu (bản dịch tiếng Việt) đã được xuất bản. Một trình bày trong video về Mô hình Độ chính Bền vững đã được phát hành. 2 tài liệu về quản lý dự án phần mềm trên GoogleCode và SourceForge, một cách tương ứng, đã được xuất bản.
Giáo dục cộng đồng đổi mới của JISC và đặc biệt cho những người viết thầu, chấm thầu, về tầm quan trọng của việc phát hành phần mềm sớm và thường xuyên.	Các phát hành làm cho dễ dàng hơn cho các lập trình viên các bên thứ 3 để 'chơi' với phần mềm.	Đã xuất bản một Mô hình độ chín bền vững (bản dịch tiếng Việt) để giúp tự đánh giá các dự án.
Giáo dục cộng đồng đổi mới của JISC và đặc biệt cho những người viết thầu, chấm thầu, về tầm quan trọng của việc phát triển các website chuyên tâm và các tài nguyên cho các lập trình viên.	Làm hạ thấp rào cản để tham gia vào trong dự án.	Đã xuất bản một Mô hình độ chín bền vững phần mềm (bản dịch tiếng Việt) để giúp tự đánh giá các dự án, và 2 tài liệu về các công cụ (bản dịch tiếng Việt) và quản lý phát hành (bản dịch tiếng Việt) để giúp quản lý các qui trình phát triển phần mềm.
Giáo dục cộng đồng đổi mới của JISC và đặc biệt cho những người viết thầu, chấm thầu, về tầm quan trọng của việc mang tới những người sử dụng mới, ở những nơi mà điều này là có khả năng.	Càng nhiều người sử dụng mà dự án có, thì kho các lập trình viên tiềm năng càng lớn.	Đã tổ chức các hội thảo cộng đồng về chủ đề này. Đã xuất bản một Mô hình độ chín bền vững phần mềm (bản dịch tiếng Việt), và tài liệu Các vai trò trong các dự án nguồn mở (bản dịch tiếng Việt) để giúp các dự án tự đánh giá và tận dụng các đóng góp bên ngoài, một cách tương ứng.
Giáo dục cộng đồng đổi mới của JISC và đặc biệt cho những người viết thầu, chấm thầu, về tầm quan trọng của việc khuyến khích sự đóng góp của các bên thứ 3, đưa ra các số liệu của sân chơi về có bao nhiêu thời gian các nhân viên bỏ ra cho qui trình điều tiết đóng góp của bên thứ 3.	Để gia tăng khả năng các dự án sẽ phân bổ ngân sách một cách thực tế cho phát triển mở.	Làm việc với JISC để đảm bảo các dự án tìm kiếm sự tư vấn từ OSS Watch trong quá trình viết thầu (bản dịch tiếng Việt). Đã xuất bản một danh sách kiểm tra các vấn đề để xem xét trong khi viết thầu (bản dịch tiếng Việt).
Triển khai nghiên cứu khả thi tong khả năng thiết lập một dịch vụ tư vấn pháp lý quốc gia cho nguồn mở, có khả năng trong mối quan hệ đối tác với pháp lý của JISC.	Các dự án đã yêu cầu thường xuyên điều này.	Điều này hiện nằm ngoài phạm vi của chức năng nhiệm vụ của OSS Watch.
Tổ chức các hội thảo cho những người viết hầu trong tương lai để xem xét và giải quyết các mối quan tâm của họ về việc đặt các tư liệu ra sớm và việc quản lý các kỳ vọng của người sử dụng, xem xét chi tiết hơn vào các kịch bản trường hợp tồi tệ nhất được thừa nhận.	Để giải quyết sự ngần ngại thực sự về việc mở ra.	Làm việc với JISC để đảm bảo các dự án tìm kiếm sự tư vấn từ OSS Watch trong quá trình viết thầu (bản dịch tiếng Việt). Hỗ trợ cho những người viết thầu được bao trùm trong các hội thảo về xây dựng cộng đồng.
Triển khai nghiên cứu để xem xét những khuyến khích nào của phòng ban và viện trường có thể được đặt vào để khuyến khích các dự án đưa ra phần mềm của họ sớm.	Bổ sung cho chính sách hiện đang tồn tại.	Một số công việc thăm dò trong lĩnh vực này, nhưng hiện không phải là một ưu tiên.

OSS Watch hạnh phúc đưa ra tư vấn về cách mà phát triển mở có thể làm lợi cho dự án của bạn. Hãy liên hệ với chúng tôi tại mailto:info@oss-watch.ac.uk.

Thừa nhận

OSS Watch được Ủy ban các Hệ thống Thông tin Chung - JISC (Joint Information Systems Committee) cấp vốn và nằm ở các Dịch vụ Điện toán của Đại học Oxford.

Tác giả muốn cảm ơn người quản lý chương trình JISC VRE và các thành viên của các dự án VRE về việc đóng góp thời gian của họ để tham gia trong nghiên cứu này và về việc bình luận trong các bản thảo trước của báo cáo này. Đặc biệt, tác giả muốn cảm ơn: Ruth Kirkham, John Pybus, Ségolène Tarte, Henriette Roued Olsen, Mark Baker, Matthew Grove, Emma O’Riordan, David de Roure, Carole Goble, Danius Michaelides, David Withers, Alan Williams, Stuart Owen, Ian Dunlop, Franck Tanoh, Katy Wolstencroft, Meik Poschen, Yuwei Lin, Antoon Goderis, Jiten Bhagat, Nikki Rogers, Michael Daw và Frederique van Till.

Các phụ lục

Phụ lục A - Phỏng vấn theo mẫu có sẵn

Mẫu này được phát triển để chỉ dẫn cho cuộc phỏng vấn cuối cùng với CREW.

• Giới thiệu
  • Chính sách nguồn mở của JISC
• Phát triển cộng đồng người sử dụng
  • Kích cỡ hiện hành
  • Marketing và PR (Website, blog, phát động, báo chí quốc gia, trình diễn demo, …)
  • Cam kết tham gia với những người sử dụng đang tồn tại (các hội thảo về các yêu cầu, kiểm thử khả năng sử dụng, huấn luyện, …)
• Phát triển cộng đồng các lập trình viên
  • Kích cỡ hiện hành
  • Website của các lập trình viên: danh sách thư, trình theo dõi các vấn đề, SVN, tài liệu...
  • Đặt chỗ hosting
  • Bạn đang lôi cuốn các lập trình viên như thế nào, như từ cộng đồng web ngữ nghĩa, cộng đồng người sử dụng, … ?
  • Liệu có các đóng góp của bất kỳ bên thứ ba nào hay không?
  • Mô hình điều hành
  • Các phát hành
• Tình trạng pháp lý
  • Liệu họ có tìm thấy tư vấn?
  • Quyền sở hữu bản quyền
  • Giấy phép phần mềm
  • Phần mềm của các bên thứ 3
  • Bất kỳ thỏa thuận giấy phép của người đóng góp
  • Bất kỳ giấy phép nội dung nào có thể áp dụng được
• Các vấn đề với việc mở ra: làm thế nào OSS Watch có thể làm cho nó dễ dàng hơn?
  • Các vấn đề như: sự sao nhãng, quyền sở hữu trí tuệ (IPR)
  • Trợ giúp như: các hội thảo, khung điều hành, thỏa thuận giấy phép của người đóng góp, tư vấn.
• Kế hoạch thoát ra
  • Tìm kiếm cấp vốn bổ sung?
  • Các lập trình viên dẫn dắt tiến lên?
  • Ai đang là động lực dẫn dắt?
• Cam kết với các tiêu chuẩn mở
  • Web ngữ nghĩa
  • Các cổng
  • Xã hội mở
  • …
• Rà soát lại các hành động
• Kết thúc

Đọc thêm

Các thông tin có liên quan từ OSS Watch:

• Xây dựng cộng đồng nguồn mở như thế nào; (bản dịch tiếng Việt)
• Nguồn mở bền vững; (bản dịch tiếng Việt)
• Các vai trò trong các dự án nguồn mở; (bản dịch tiếng Việt)
• Các trường hợp điển hình về tính bền vững; (bản dịch tiếng Việt)
• Mô hình độ chín bền vững của phần mềm; (bản dịch tiếng Việt)
• Nguồn mở và hạ tầng nghiên cứu; (bản dịch tiếng Việt)

1. Chính sách PMNM của Chính phủ Anh đã được Chiến lược CNTT-TT về Nguồn mở, các Tiêu chuẩn mở và Sử dụng lại tinh chỉnh lại tiếp tục và đã được phát hành vào tháng 12/2009.
2. Mẫu chuẩn bị trước cho các cuộc phỏng vấn có thể thấy trong Phụ lục A.
3. Dịch vụ đặt chỗ bên ngoài như SourceForge và Google Code được ưu tiên cho những người đã duy trì trong nội bộ vì chúng ít rủi ro rằng hạ tầng dự án sẽ được tái mục đích khi cấp vốn kết thúc. Sử dụng các dịch vụ bên ngoài cũng có khả năng tạo ra nhiều hơn ấn tượng về tính mở và hệ quả là làm gia tăng khả năng các bên thứ 3 sẽ đóng góp.
4. Sáng kiến Kho lưu trữ Mở cho Đối tượng Sử dụng lại và Trao đổi - OAI - ORE (Open Archives Initiative Object Reuse and Exchange) xác định các tiêu chuẩn cho mô tả và trao đổi tổng hợp nguồn Web. Nhiều thông tin hơn sẵn sàng ở: http://www.openarchives.org/ore/
5. Xã hội mở định nghĩa giao diện lập trình ứng dụng - API cho các ứng dunngj xã hội xuyên nhiều website. Nhiều thông tin hơn sẵn sàng ở: http://code.google.com/apis/opensocial/
6. Dự án đã tham chiếu tới WebPA nằm ở Đại học Loughborough. WebPA đang phát triển các công cụ dựa vào web cho đánh giá ngang hàng trực tuyến. Nhiều thông tin hơn sẵn sàng ở: http://webpaproject.lboro.ac.uk/.

Executive Summary

[This document describes the situation as at October 2008. Ed]

Background

OSS Watch is a national advisory service that provides open source software advice to the further and higher education communities. The remit encompasses support for JISC’s 2004 policy on open source, which established the principle that JISC-funded projects should not only release their software as open source but also follow an open development approach, including taking steps to foster communities of users and developers around their software.

In early 2008, OSS Watch won approval to significantly ramp-up their level of assistance to UK higher and further education projects, to help them implement this policy and put themselves in a much better position to fully realise the benefits of open source as a result. This study was commissioned late 2008 to help inform the new work through investigating the current level of awareness, attitudes to and understanding of the open development concept within the JISC innovation community.

The projects selected for investigation were the four funded within the JISC Virtual Research Environment Phase Two programme, which is developing innovative software for the UK research community. The study methodology combined face-to-face interviews with a focus-group-style discussion. The analysis was primarily qualitative and took into consideration the author’s own experience of managing JISC-funded projects to strike a balance between the ideals of open source on the one side and practical realities on the other. The OSS Watch team itself were not directly involved with drawing up the list of recommendations.

Findings and recommendations

The study found the four projects to be extremely positive about open source and to be enthusiastic, repeat consumers of open source software. Two out of the four projects interviewed had publicly accessible source code repositories and even those that did not were firmly committed to releasing their software as open source.

The majority had only recently become aware of open development as an approach and of the need to encourage third parties to contribute code and documentation during the lifetime of the project. As none of the projects was explicitly inviting contributions, from an open development perspective, they can be considered to be essentially closed developments.

A minority of projects doubted the applicability of open development to their projects, seeing themselves to be more at the level of testing a concept rather than developing production-quality software. Even those that saw the need expressed significant concerns around the overhead of managing the process of accepting and moderating contributions, given that they had not budgeted for it in their project proposals. Despite this, many expressed a real desire to be further educated about it.

The list of recommendations arrived at set out to address the lack of awareness around the need for and practice of following an open development approach. Information tailored to the specific circumstances of JISC-funded projects was a recurring theme, as was the need to educate bid-writers and markers at as early a stage as possible. It was also recommended that OSS Watch look into other ways this issue could be brought to the attention of the JISC community through, for example, looking at possible incentives and policy changes and through carrying out workshops to address projects’ sometimes deep-seated concerns about ‘going open’.

Background

OSS Watch provides advice on a wide variety of topics around the adoption and development of open source software to the further and higher education communities. Around the period when the second VRE programme started, the service started taking a more active role in helping JISC development projects fully implement the JISC open source policy with a particular emphasis on community development.

This report represents the result of efforts to inform this ‘project-embedding’ work by investigating firstly how successful existing JISC-funded software development projects have been in creating communities, using the JISC Virtual Research Environment Phase Two programme as a sample, and secondly the ways in which this process could be made easier, with or without the assistance of OSS Watch.

OSS Watch and the JISC Open Source Policy

OSS Watch was formed in 2003 as a small pilot advisory service with a remit initially limited to establishing and maintaining a website, organising national conferences and workshops and providing guidance to institutions as requested. When in its sixth year, it had migrated from this purely educational objective to one of active support and guidance. For example, OSS Watch, where possible, started attending and contributing to all JISC programme start-up events, conducting numerous consultations with projects and publishing case studies of a range of active open source development projects.

In 2004, OSS Watch drafted an open source policy for JISC in response to the UK Government Open Source Software Policy 1. Most memorably, this established the principle that, by default, JISC software development projects should release their software under an Open Source Initiative (OSI) approved open source licence, refining the existing requirement for project outputs to be made freely available to the further and higher education communities. Less memorably, the policy also established guidelines for open development, recommending that projects take steps to cultivate communities of developers (and users) around their software:

4.9 Sustainability and communities

Many open source projects are supported by community effort, and the JISC is keen to encourage broad participation and contribution to open source projects.

• Projects must state in their bid whether they foresee the project continuing beyond the time span of the funding, and if so whom they see participating in the project.
• Projects should engage with end users and other parties to encourage and build self-sustaining communities.
• Projects should facilitate the use of their software in other UK HE and FE institutions.
• Projects may facilitate the use of their software in the wider community [23].
• Projects should accept bug reports, patches, translations and feedback from contributors outside the project.

– Policy on open source software for JISC projects and services

The intention was for projects to establish, through their user and developer communities, a level of support sufficient for them to move beyond their initial phases with less reliance on continuation funding.

JISC Virtual Research Environment Phase Two Programme

The JISC Virtual Research Environment Phase Two (VRE2) programme was one of around thirty JISC programmes developing and piloting software for further and higher education. According to the JISC website, a Virtual Research Environment (or VRE), ‘helps researchers in all disciplines manage the increasingly complex range of tasks involved in carrying out research’. VRE2 followed on from VRE1, a larger and more experimental programme, and was made up of four projects developing pilot virtual research environments to support the needs of UK researchers.

The VRE for the Study of Ancient Documents (VRE-SDM) project is building facilities for geographically dispersed researchers to access and annotate image collections. The VRE for Archaeology (VERA) project is developing and piloting a VRE with the Silchester Roman Town dig to enhance the means of efficiently documenting archaeological excavation and its associated artefacts. MyExperiment is creating a social network for scientists based around, but not restricted to, the sharing and execution of workflows. The Collaborative Research Events on the Web (CREW) project is producing a VRE to capture and publish the scholarly communication that takes place at and around research events.

Even within this relatively small programme, the projects address an extraordinary gamut of needs, some focusing on a single research domain, others being more generic in scope. JISC’s project portfolio as a whole shares this diversity and, as a result, it is almost impossible to pick a representative programme or set of projects. That said, there are certain characteristics that JISC projects normally share. For one, in addition to their being projects for _UK FE and HE, they are also normally _run__by UK HE or FE institutions, frequently by those in computing services or computer science departments. Secondly, JISC projects all tend to run under similar cost and time constraints: budgets are normally well under £500,000 and run for one to two years. Thirdly, projects are often geographically distributed with individual project teams split across multiple UK institutions. In all these respects, the VRE2 programme is no different.

The benefits of open development

The benefits of open source have been well documented. However, some of the reported benefits can be argued to exist in equal, if not greater, measure in closed-source developments. For example, the existence of active user communities contributing documentation, experience and advice to other users, is certainly not unique to open source.

The real advantage open source projects have is their capacity to harness the resources of numerous individuals and organisations to develop the software further, through a form of peer-review simply not available with closed source. This advantage is, however, clearly predicated on the existence of active communities of developers as well as active communities of users.

Community formation does not happen automatically just because software is released as open source. If projects want to establish them, they need to take active steps to foster them throughout the lifetime of the project. While the ultimate goal is an active developer community, user communities are of course critically important to both because without users the project would have no reason to exist, and because user communities also represent the most likely source of future developers, either through users getting involved directly or through their employing people to do so on their behalf. Consequently, it is important that user communities are supported and continue to grow.

The process of drawing in new users may represent a challenge for projects satisfying needs shared by a relatively small number of people. And even for projects addressing more widely held needs, if this also means tackling significant technical challenges, it may seem to make more sense to keep the initial user community reasonably small, while the concept is tested, rather than risk damaging the project’s reputation by releasing software that does not work.

Users are not the only source of potential developers. Those working within specific technical communities or working on technical standards may want to become involved and use the software as a vehicle for an emerging technology. This can be a win-win situation. However, there is a risk that if these people start to outnumber the end-users, the project team as a whole loses sight of its original purpose and becomes an academic exercise: all developers and no users.

Achieving a sensible compromise

OSS Watch is not an advocacy organisation and does not promote open source as such; in contrast, it provides unbiased advice on how institutions can go about adopting or developing it. Having said that, where projects developing software choose to go down the open source route, OSS Watch does advocate embracing the concept in its entirety, including taking steps towards developing communities around the software and not just ‘code dumping’ it on an open source hosting service at the end. This is not to say that OSS Watch recommends all projects should run as consensus-based democracies. Open development is not an all or nothing endeavour: it is possible to be open while retaining elements of control.

Some steps towards open development are likely to be (or perceived to be) more achievable than others.

Methodology

The fieldwork conducted for this study took the form of a series of semi-structured interviews with the four VRE2 projects between January and April 2008, complemented by a session at the VRE2 programme meeting in May 2008.

Interviews

The interviews were designed to look at each individual project’s attitudes, understanding and progress towards implementing open development, the barriers preventing it and the ways in which open development could be made easier, both with and without the assistance of OSS Watch.

The approach used for the first (joint) interview with VERA and VRE-SDM was fairly exploratory and concentrated on the two projects’ attitudes and understanding of the open development concept. The second interview with MyExperiment took place as part of an existing project meeting and less time was spent exploring attitudes and more on actual progress with community development, particularly on the user side. In order to improve coverage, an interview pro-forma2 was drafted and used to guide the final interview with CREW.

The topic of community development naturally divided itself into users on one side, and developers on the other, whilst recognising overlaps between the two. For both communities, it normally made sense to distinguish between “friends and family” – those recruited at the bid writing stage – and those not initially known or involved with the project. Activities with the former group were inevitably more about engagement than development: keeping them on board and happy. Discussions on how projects had attracted outside interest led to questions on how projects had marketed themselves to potential users and the technical community, including the other VRE2 projects and groups drafting open standards.

Although not originally intended as a major topic for discussion, the issue of software licensing and legal arrangements frequently cropped up, not least because choosing an appropriate licence and legal structure often presented the most immediate barrier to opening out development.

Session at the VRE programme meeting

The programme meeting session aimed to provoke discussion and arrive at some form of consensus on possible action for OSS Watch. It was an hour long, with the first half devoted to presenting the findings from the interviews, and the second half taking the form of a discussion around the subject of open development, how achievable it is for JISC projects, and how it might be made easier through the work of OSS Watch. A preliminary list of suggestions for OSS Watch was discussed and further added to and refined. At the end, participants were able to indicate what they felt to be their number one suggestion to OSS Watch.

Findings

Attitudes and awareness

Overall, projects demonstrated an overwhelmingly positive attitude to open source. As frequent consumers of open source software, the projects saw open source as a good thing overall and all were committed to releasing their software under an OSI-approved open source licence. On the other hand, projects’ awareness and understanding of open development was less consistent. One respondent said, ‘I’ve only heard a real buzz about open development in the JISC community in the last year or so. Post when we put our bids in.’

User community development

The VRE2 call prescribed a user-centred development approach, introducing a ‘figure of eight’ model (see Figure 1) based on agile and participative software development methods. As a result, all four VRE2 projects are strongly committed to user community engagement in the sense of understanding their users’ needs and working closely with them when developing the software. From an open development perspective, this is clearly a good thing: users will turn away if their needs are not satisfied, and without users there is no project.

As a software development model as opposed to a community development model, the ‘figure of eight’ assumes the user community is already out there, waiting to be engaged with and does not place very much emphasis on drawing in new users. The VRE2 projects all had user communities written into them at their outset and genuine efforts had been made to keep them engaged and interested.

MyExperiment was the only project to have made significant attempts to recruit new users, but this was significantly more straightforward for them because their software was already accessible as a hosted ‘web 2.0’ application. CREW and VRE-SDM were still at the stage of controlling access to the software through carefully managed ‘show and tell’ usability testing sessions; for them it was simply too early to be making the software generally available ­– users needed a certain degree of ‘hand-holding’. VERA was gearing up for the Silchester summer 2008 dig, at which their users would have their first chance to get their hands on the technology developed.

Developer community development

None of the projects had really considered opening up development beyond their core teams in their initial funding periods. A representative comment made by one technical manager was, ‘We haven’t got a plan for opening it out as an open source development. That is not to say we would rule it out.’

Putting materials out

The most important step in opening out development is making the software available so that other developers can ‘play’ with it. However, this is not just about putting the source code on a website or granting the public access to the revision control system. It is generally recognised that developers (and users) are much more likely to get involved if the software is made available as a _release _with some associated statement of quality. For example, that it will compile and run at the very least.

Two out of the four VRE projects, MyExperiment and VERA, had already made their source code avilable via version control: MyExperiment through RubyForge and VERA through a local Trac system, although the VERA code is not publicly accessible3. However, for differing reasons, the projects had not carried out any formal releases. One explanation for this was that the projects had not needed to do so in order to make the software accessible to their users. MyExperiment’s users were almost all adopting the project’s hosted service (a ‘perpetual beta’) at myexperiment.org rather than installing local copies; VERA, CREW and VRE-SDM were still controlling access to the software.

Looking beyond this, projects expressed a basic hesitancy about attracting third-party developers and putting their software out in this way. There was the feeling that their projects were simply not ‘big enough and popular enough’ for it to be worth it. One project said, ‘You have got to have enough people using the software to make it viable.’ There was also the fear that putting software out opened up developers to a certain amount of exposure and there was the feeling from one project that ‘that transparency could inhibit developers’. At the VRE programme meeting, this fear was explored further.

Another concern was that by opening up development, projects would lose an element of control and even the cachet associated with having been funded to deliver the project in the first place. There was also the worry that other people might change the direction of the project to the detriment of the end user community. All projects appeared to prefer the Linux model: where they control a core part and third-party contributors develop tools around the edges.

Accepting and managing contributions

Making releases available allows developers to ‘play’ with the software. What it does not provide for is mechanisms to allow changes to be contributed back into the project.

At one level or another, the VRE2 projects recognised that carrying out releases was a necessary part of opening up development. However, what they had not expected to do was release their software any earlier than at the end. While projects had been very open about the idea of open development, at the same time they also expressed real concerns about the overhead of managing the process of accepting contributions on top of delivering the software itself. One technical manager commented, ‘[This overhead] wasn’t factored in on this project and I haven’t factored it in on any bid I’ve written.’ Another said, ‘Managing and massaging the code when other people are contributing is a lot more work than writing the code yourself.’

As a result of this reluctance, none of the projects had concrete plans for opening up development, no dedicated developer websites and no instructions on how to contribute. Despite this, there were two projects – MyExperiment and VERA – that were agreeable to outside parties developing tools and plug-ins. MyExperiment, by releasing a “RESTful”, API, were even implicitly inviting this and examples of ‘mash-ups’ integrating MyExperiment functionality already existed in the form of three Google Gadgets. MyExperiment admitted, however, that they did need a strategy for plug-ins so that those building them would know ‘where to put them’.

Another way in which the projects had hoped to open out was by spinning out sub-components as open source projects in their own right. VERA had, as part of their efforts to integrate off-the-shelf applications such as Wordpress and MediaWiki within their portal, developed a middleware component dubbed ‘RecycleBridge’ to facilitate this. CREW stated a desire to spin out an integral RDF-based annotations component having already shared it with two other JISC-funded projects at the University of Bristol Institute for Learning and Research Technology (ILRT). In both cases, it was felt that by spinning these components out, they would be made relevant to a much wider group of users and stand a better chance of attracting developers from the portals and semantic web communities respectively.

MyExperiment had engaged with technical communities too, but were unique among the VRE2 projects in that they had decided not to embrace portals as their main presentation technology. They did, however, state an ambition to launch a portals activity in parallel to the main project. MyExperiment had engaged with both the World Wide Web Consortium and digital repositories communities through their development of Encapsulated myExperiment Objects (EMOs) designed to interoperate with the emerging OAI-ORE4 standard. MyExperiment had also collaborated with the JISC-funded SKUA project exploring the use of Open Social5 as a possible collaboration path. In doing so, the SKUA project became the first and only project to install MyExperiment locally rather than using the hosted service.

Sustainability and exit plans

The projects’ general approach to sustainability was either to seek additional funding at project end or to investigate commercial exploitation opportunities. As one technical manager commented, ‘The sustainability plan is being seen as enough of a success earlier in the project that we stand a chance of bidding for more money.’

Suggestions from the projects to OSS Watch

Many of the suggestions made by projects were related to the provision of information. However, it was not so much that more information was needed; it was more that the wealth of existing information be tailored to the particular circumstances of JISC-funded projects. For example, while OSS Watch had published numerous open source case studies, there was only one that showed how an existing JISC-funded project6 had successfully followed an open development approach. Publishing more similar exemplars was the most popular suggestion by far because, in the words of one technical manager, ‘It’s always easier to play follow-my-leader.’

Another example of this tailoring was the suggestion of providing template governance models and contributor licence agreements. OSS Watch already had resources on drafting these documents, but the projects felt that a lot of time could be saved by allowing projects to obtain boilerplate documents for their specific circumstances. This assisted decision-making could also simplify the process of choosing the open source licence itself. Rather than relying on generic advice, projects could be guided through a series of scenarios allowing them to explore the risks, costs and benefits of taking different licensing decisions. At the same time, there was also the suggestion that OSS Watch or JISC could provide a fully fledged legal advice service for open source.

A further aspect to the information-related suggestions was the need for dissemination to be less passive and much more active. In addition to information being made available on the website and its associated RSS feeds, it should be proactively put in front of the people who need to know it, particularly the bid writers and bid markers. OSS Watch does, where possible, attend all JISC town and programme meetings, and projects are normally required to consult with OSS Watch when they get started. However, projects reported that the message about open development had been received far too late. Unless bid-writers are made aware and educated about it, open development is very unlikely to be planned or budgeted for.

No amount of information, education or advice will help some projects get over their most deep-seated fears about ‘going open’. There was the suggestion that OSS Watch should organise workshops with projects to look at their concerns and how they might be addressed, for example, through effectively managing the expectations of users. One way of helping projects to overcome their fears could be by working with them to follow their scenarios through to their logical extremes; by helping projects to visualise potential worst-case scenarios, risks are much better understood and defined.

Some of the suggestions were less about help for individual projects and more about policy at the departmental, institutional and national level. For example, could some of the hesitancy about putting software out earlier be tackled through departments and institutions putting in place incentives, in the same way that the open access movement has encouraged researchers to deposit their publications in institutional repositories? One radical but popular idea was for OSS Watch or JISC to actually ‘manage’ an open source community of developers for JISC projects. This would provide a pool of developers and contributors and help to ensure that knowledge is not lost. It was suggested that even if this might not work in practice, it might still be a valuable ‘thought experiment’ to carry out.

Conclusions

Even though the VRE2 projects are all committed to releasing their software as open source, the lack of resources for developers, formal releases and, in some cases, read access to code repositories shows that the VRE2 projects are not conducting development in a very open way. As a consequence, they are making it much less likely for development communities to form, preserve the knowledge built up by team members and take the projects beyond their initial funding.

The reasons the VRE2 projects have not embraced open development appear to be rooted in a combination of lack of awareness, psychology, and lack of resources. Awareness relates both to which steps to take as well as the importance of actually taking them: whether they are essential to open development or simply desirable. For the steps projects are aware of, there seem to be significant psychological barriers preventing them from taking them both in terms of their perceived difficulty, effort (overhead) involved and possible fall-out.

None of those interviewed were completely against open development. However, there were some that were doubtful as to how applicable it was for their projects, especially where they saw their projects to be more about testing a concept than producing production quality software. Even so, the majority were not against the idea of putting open development into practice in future projects, as long as they have sufficient resources to do it and implementing it will not distract them too much from the task of developing the software.

The concept of community development is very much a part of the JISC open source policy and the VRE2 circular explicitly required applicants to ‘make clear the licence under which software outputs will be released, mechanisms that will be put in place for community contribution (users and developers) throughout the project, and the sustainability plan for the project.’ However, this had not resulted, in the case of VRE2, in projects budgeting realistically for the overhead of managing the process of open development. The lesson here is that OSS Watch and JISC should be much more pro-active with educating the JISC innovation community, particularly the bid-writers and bid-markers, on the importance of factoring this in.

Recommendations

The following prioritised list of recommendations for OSS Watch has been distilled from the interviews and VRE programme meeting session. The OSS Watch team itself was not directly involved with drawing them up but did, wherever possible, work these recommendations into OSS Watch’s project plan for the 2008-2010 funding period.

The status comment was added to indicate the activities that have been undertaken in each area and reflects the status in 2011.

	Recommendation to OSS Watch	Rationale	Status in 2011
1.	Publicise more exemplars of successful open development projects, particularly those funded by JISC or those operating under similar constraints.	To allow projects to play ‘follow-my-leader’.	Published a number of funded project-specific case studies.
2.	Carry out a feasibility study into the possibility of establishing a managed open source development community for JISC innovation programmes.	As one possible method of countering loss of knowledge resulting from staff turnover and short-term funding.	Outside the scope of our current work. We are an advisory service only. Working with the JISC and other funders to consider options.
3.	Provide assisted decision-making facilities through the OSS Watch website to walk projects through different scenarios exploring the risks, costs and benefits of taking different software licensing decisions.	To make it easier for projects to choose a licence, necessary before they can open up.	Choice of licence incorporated into consultation work.
4.	Provide template governance models and contributor licence agreements tailored for JISC-funded projects.	To eliminate the main barrier associated with putting them in place.	Template CLA from University of Oxford is available on request. Documents on Governance model templates have been released.
5.	Educate the JISC innovation community, and particularly the bid-writers and markers, on the importance of using external open source hosting services.	By using external hosting services, third parties are more likely to see projects as genuinely open. It also eliminates the risk that project servers are re-purposed when JISC funding comes to an end.	Working with the JISC to ensure projects seek advice from OSS Watch during bid writing. A checklist of issues to consider during bid-writing has been published. A video presentation on Sustainability Maturity Models has been released. Two documents on managing project software on GoogleCode and SourceForge, respectively, have been published.
6.	Educate the JISC innovation community, and particularly the bid-writers and markers, on the importance of releasing software early and often.	Releases make it easier for third party developers to ‘play’ with the software.	Published a Software Sustainability Maturity Model to help projects self-evaluate.
7.	Educate the JISC innovation community, and particularly the bid-writers and markers, on the importance of developing dedicated websites and resources for developers.	Lowers the barrier to participation in the project.	Published a Software Sustainability Maturity Model to help projects self-evaluate, and two documents on tools and release management to help manage the software development processes.
8.	Educate the JISC innovation community and particularly the bid-writers and markers, on the importance of bringing in new users, where this is possible.	The more users the project has, the larger is the pool of potential developers.	Have run community workshops on this topic. Published a Software Sustainability Maturity Model, and a Roles in open source projects document to help projects self-evaluate and harness external contributions, respectively.
9.	Educate the JISC innovation community and particularly the bid-writers and markers, on the importance of encouraging third-party contributions, providing ballpark figures on how much staff time to allocate to the process of moderating third-party contributions.	To increase the likelihood that projects will budget realistically for open development.	Working with the JISC to ensure projects seek advice from OSS Watch during bid writing. Published a checklist of issues to consider during bid-writing
10.	Carry out a feasibility study into the possibility of establishing a national legal advice service for open source, possibly in partnership with JISC legal.	Projects have frequently requested this.	This is currently outside the scope of OSS Watch’s remit.
11.	Organise workshops for prospective bid-writers to examine and address their concerns about putting materials out early and managing user expectations, looking in more detail at perceived worst-case scenarios.	To address a real hesitancy about opening up.	Working with the JISC to ensure projects seek advice from OSS Watch during bid writing. Support for bid-writers covered in community-building workshops.
12.	Carry out a study to look at what departmental and institutional incentives could be put in place to encourage projects to put out their software out early.	To complement the existing policy.	Some exploratory work in this area, but not currently a priority.

OSS Watch is happy to provide consultation on how open development can benefit your project. Contact us at mailto:info@oss-watch.ac.uk

Acknowledgements

OSS Watch is funded by the Joint Information Systems Committee (JISC) and is located at Oxford University Computing Services.

The author would like to thank the JISC VRE programme manager and members of the VRE projects for contributing their time to participate in this study and for commenting on previous drafts of this report. In particular, the author would like to thank: Ruth Kirkham, John Pybus, Ségolène Tarte, Henriette Roued Olsen, Mark Baker, Matthew Grove, Emma O’Riordan, David de Roure, Carole Goble, Danius Michaelides, David Withers, Alan Williams, Stuart Owen, Ian Dunlop, Franck Tanoh, Katy Wolstencroft, Meik Poschen, Yuwei Lin, Antoon Goderis, Jiten Bhagat, Nikki Rogers, Michael Daw and Frederique van Till.

Appendices

Appendix A - Interview Pro-Forma

This pro-forma was developed to guide the final interview with CREW.

• Introduction
• Awareness of and attitudes to open development
  • JISC open source policy
• User community development
  • Current size
  • Marketing and PR (Website, blogging, launch, national press, demos, etc)
  • Engagement with existing users (requirements workshops, usability testing, training, etc)
• Developer community development
  • Current size
  • Developer’s website: mailing list, issue tracker, SVN, documentation, etc.
  • Hosting
  • How are you attracting developers, e.g. from semantic web community, user community, etc.?
  • Any 3rd party contributions?
  • Governance model
  • Releases
• Legal status
  • Have they sought advice?
  • Copyright ownership
  • Software licence
  • 3rd party software
  • Any contributor licence agreement
  • Any applicable content licences
• Problems with being open: how could OSS watch make it easier?
  • E.g. problems: distractions, IPR
  • E.g. help: workshops, governance framework, contributor licence agreement, advice.
• Exit plan
  • Seek additional funding?
  • Taken forward by developers?
  • Who is the driving force?
• Open standards engagement
  • Semantic web
  • Portals
  • Open social
  • etc
• Review of actions
• Close

Further reading

Related information from OSS Watch:

• How to build an open source community
• Sustainable open source
• Roles in open source projects
• Sustainability Case Studies
• Software sustainability maturity model
• Open source and research infrastructure

1. The UK Government Open Source Software Policy has been further refined by the ICT Strategy on Open Source, Open Standards and Reuse that was released in December 2009↩
2. The interview pro-forma can be found in Appendix A.↩
3. External hosting services such as SourceForge and Google Code are preferable to those maintained internally because there is less of a risk that the project infrastructure will be repurposed when funding comes to an end. The use of external services is also likely to create more of an impression of openness and consequently increase the likelihood that third parties will contribute.↩
4. Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. More information is available at: http://www.openarchives.org/ore/↩
5. Open social defines a common API for social applications across multiple websites. More information is available at: http://code.google.com/apis/opensocial/↩
6. The project referred to is WebPA based at Loughborough University. WebPA is developing web-based tools for online peer assessment. More information is available at: http://webpaproject.lboro.ac.uk/↩

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com