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ẹ 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:
- 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)
- 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.
- 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.
- 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.
- 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/
- 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/
- 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/.
[This
document describes the situation as at October 2008. Ed]
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.
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’.
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 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.
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 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.
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.
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.
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.
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.
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.’
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.
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.’
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.
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.
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.’
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.
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.
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
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.
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
Related
information from OSS Watch:
- 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↩
- The interview pro-forma can be found in Appendix A.↩
- 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.↩
- 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/↩
- Open social defines a common API for social applications across multiple websites. More information is available at: http://code.google.com/apis/opensocial/↩
- 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.