Thứ Hai, 27 tháng 5, 2013

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
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ẹ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 GoogleCodeSourceForge, 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:

  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:

  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

Không có nhận xét nào:

Đăng nhận xét

Lưu ý: Chỉ thành viên của blog này mới được đăng nhận xét.