WebPA: con đường tới tính bền vững

By Elena Blanco, Ross Gardler, and Nicola Wilkinson, Published: 30 November 2007, Reviewed: 11 June 2012

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

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

Lời người dịch: Đây là dự án thứ 4 trong số 7 dự án mẫu trong loại bài về xây dựng cộng đồng nguồn mở hướng tới tính bền vững. Những triết lý trong việc xây dựng một cộng đồng những người sử dụng để tạo ra những người đóng góp cho một dự án nguồn mở hướng tới tính bền vững là một tham khảo tuyệt vời cho những ai có mong muốn xây dựng một cộng đồng nguồn mở hiện nay. Bạn rất và rất nên đọc kỹ bài này.

OSS Watch được JISC cấp vốn để cung cấp sự hỗ trợ và chỉ dẫn về sử dụng và phát triển phần mềm và các giấy phép tự do nguồn mở. Một trong những cách thức mà điều này có thể đạt được là thông qua các tư vấn chi tiết một - một với các dự án. OSS Watch bây giờ đã tiến hành được một số lượng đáng kể các tư vấn và cực kỳ vui mừng để báo cáo về một số các kết quả xác thực từ hoạt động đó.

Sự tư vấn đáng kể vào đầu năm 2007 đã diễn ra với dự án WebPA. Dự án do JISC cấp vốn này sẽ làm một phiên bản nguồn mở của một hệ thống đánh dấu có điều tiết theo điểm ngang hàng trên trực tuyến đang tồn tại và đặc biệt có quan tâm trong việc xây dựng một cấu trúc hỗ trợ cộng đồng. Đi theo sự tư vấn với OSS Watch, dự án WebPA, phần lớn được Nic Wilkinson dẫn dắt, đã thực hiện các bước tích cực để xây dựng một cấu trúc hỗ trợ cộng đồng và nó bây giờ dường như là tất cả công việc nặng nhọc đang trả giá. Như một kết quả WebPA làm thành một trường hợp điển hình thú vị như một mô hình cho tất cả các dự án có mong muốn đi xuống con đường phát triển mở.

Blog của WebPA

WebPA thiết lập 2 blog của dự án như một cơ chế để giữ cho cộng đồng được cập nhật về những gì đã và đang xảy ra. Một blog tập trung vào sự phát triển kỹ thuật của dự án (blog kỹ thuật) và cái kia về nghiên cứu sư phạm và phát triển khung công việc cho dự án (blog nghiên cứu). Blog kỹ thuật của các vấn đề có giao diện của dự án và các bước thực tế được tiến hành để giải quyết chúng. Quan trọng hơn đối với OSS Watch, nó đưa ra một ví dụ cụ thể về các mà JISC đã cấp vốn cho dự án có thể thành công lấy tư vấn của chúng tôi và tùy biens nó cho trường hợp đặc thù của họ. Để minh họa cho điều này, hãy xem xét các trích đoạn của blog, được liệt kê ở đây cùng với sự tư vấn đặc thù của OSS Watch cho những gì chúng có liên quan.

• Tôi không bao giờ đã tưởng tượng rằng việc chọn giấy phép tiềm năng mà chúng tôi có thể sử dụng có thể khó khăn đến thế. Điều này tất cả dẫn tới việc viết ra sự thỏa thuận của nhóm và phát hành nguồn mở trong tương lai của WebPA. Tư vấn ngày 02/01/2007: Sắp xếp ra giấy phép và vị thế IPR của bạn sớm. Trong một thế giới lý tưởng, giấy phép sẽ được quyết định trước khi dự án bắt đầu hoặc ít nhất càng sớm càng tốt khi những phụ thuộc của phần mềm được xác định.

• Chúng tôi cũng đã xoay xở để có một vài trình bày rất cơ bản cùng nhua như một sự giới thiệu cho dự án... Cột mốc chính khác của chúng tôi là có được một danh sách thư của JISC. Ngày 17/01/2007.

• Dự án WebPA đã bắt đầu phổ biến xa hơn ra ngoài trong tạp chí 'Dlib'. Tư vấn ngày 08/02/2007: Chắc chắn cộng đồng tiềm năng của bạn nhận thức được về bạn và có thể giao tiếp với bạn từ ngày đầu tiên; chắc chắn họ sẽ chưa tụ tập trước cửa của bạn, nhưng việc tạo ra một thương hiệu là bước đầu tiên. Đơn giảm việc đảm bảo rằng tất cả các tư liệu được phổ biến sẽ được nhận diện như tới từ dự án của bạn đi cùng con đường hướng tới việc tăng cường cho thương hiệu của bạn.

• Hôm qua chúng tôi đã có một cuộc gặp có nhiều thông tin với Ross và Rowan từ OSS Watch. Ngày 07/03/2007.

• Tất cả điều này phải làm và 2 cuốn sách nguồn mở phải đọc! Ngày 23/03/2007: Hãy thực hiện nghiên cứu của bạn, xây dựng một cộng đồng dẫn dắt dự án là không khó, nhưng nó hoàn toàn khác với bất kỳ dạng cấu trúc nào khác và nó sẽ không xảy ra chỉ qua một đêm cho bạn. Hiểu được thực tiễn tốt nhất và chỉ ra được cách áp dụng nó cho công việc của bạn là chìa khóa cho sự thành công.

• Như với mọi điều có liên quan tới những thỏa thuận và IPR, có một sự thiếu hụt phân biệt được về sự hiểu biết như đối với số lượng công việc cần thiết để được hoàn tất. Cũng có một sự thiếu hụt phân biệt được về sự hiểu biết như vì sao điều này có thể là quá quan trọng đối với dự án và sự thành công tiềm tàng của nó. Tư vấn ngày 24/04/2007: Nhận thức được rằng bạn không biết mọi điều và hãy có tư vấn sớm. Một khi bạn có được tư vấn đó thì hãy chắc chắn là nó được giao tiếp có hiệu quả đối với cả đội dự án và cộng đồng.

• Chắc chắn là chúng tôi đang nhận được tiền xứng đáng từ bên ngoài OSS Watch (không phải tiền chúng tôi trả). Tôi đã hỏi một số đồng nghiệp ở đây tại Loughborough liệu họ có thích tham gia vào đội WebPA một vài giờ và ngồi đó không. Mỗi người mà có ý định tìm ra về các cộng đồng đã đưa ra ý kiến phản hồi tích cực. Mọi người đã nói rằng họ đã muốn họ có khả năng bỏ ra nhiều thời gian hơn để dự phiên buổi chiều, để tìm ra nhiều hơn. Tư vấn ngày 10/03/2007: Luôn giúp những người mà giúp bạn và tin tưởng ở những nơi xứng đáng.

• Cũng được nhấn mạnh đối với đội WebPA một số con đường rằng dự án có thể nắm lấy như những chiến lược đầu ra hoặc (khái niệm tốt hơn) tính bền vững của dự án từ lúc mà việc cấp vốn sẽ hết. Tư vấn ngày 10/05/2007. Kế hoạch cho tính bền vững càng sớm càng thực tế. OSS Watch khuyến khích bạn xem xét nó trong quá trình của pha đấu thầu và có thể giúp với điều này Bạn càng sớm bắt đầu kế hoạch cho nó thì nó càng có khả năng xảy ra hơn.

• Tính bền vững có liên quan tới sự sống sót liên tục của dự án, hoặc các kết quả đầu ra của dự án, sau vòng cấp vốn hiện hành. Có nhiều con đường của tính bền vững sẵn có đối với các dự án bao gồm việc bảo trợ cho tất cả các kết quả đầu ra tới một dự án cha phù hợp, việc khai thác các kết quả đầu ra một cách thương mại hoặc việc gửi vào các kho phù hợp. Là sống còn để lưu ý rằng trong trường hợp của phần mềm, là không đủ để đơn giản làm cho mã nguồn sẵn sàng trong một “xưởng” như SourceForge.

• Tuy nhiên, điều này bây giờ làm cho tôi đau đầu! Tôi đã làm cho nó quá phức tạp. Tư vấn ngày 15/05/2007: Hãy giữ cho nó đơn giản. Hãy để nó làm những gì những người sử dụng muốn nó phải làm và không gì hơn. Việc giữ cho nó đơn giản không chỉ giúp cho bạn, mà còn giúp cho bất kỳ ai đến với mã như một người đóng góp tiềm năng.

• Sau một sự thăm dò ý kiến khá nhanh của đối tác dự án và thí điểm tiềm năng cơ hội sử dụng LDAP nổi lên … Vấn đề đầu tiên tôi đã gặp phải là … Tư vấn ngày 25/05/2007: Hãy là mở về các vấn đề bạn đang đối mặt và cách mà bạn có ý định giải quyết chúng. Bây giờ banj có một khán phòng nhỏ, ai đó ngoài đó có thể có câu trả lời, hoặc có thể dừng bạn đưa ra một quyết định sai.

• Thực tiễn tốt nhất gợi ý rằng các vấn đề nên được thảo luận trong một danh sách thư hơn là một blog vì ý định nên là để khuyến khích những đóng góp tất cả các dạng. Mọi người chỉ có thể bình luận trên blog, họ không thể tạo các bài mới nên những đóng góp của họ bị hạn chế đối với các chủ đề bạn chọn. Tuy nhiên, một số thành viên cộng đồng có thể có khả năng hơn để tham gia với một bài viết trên blog hơn là một danh sách thư và ngược lại nên một sự thỏa hiệp thú vị có thể là lý tưởng với một vấn đề đặc biệt trong danh sách thư và sau đó lặp lại điểm đó với một bài viết trên blog sau đó. Điều này sẽ làm tối đa hóa sự cởi mở bên trong khán phòng đích của bạn.

• Ai là cộng đồng của bạn và chính xác liệu wiki sẽ được sử dụng để làm gì? Tư vấn ngày 07/06/2007: Đừng sử dụng công nghệ chỉ đơn giản vì nó “hay”.

• Một wiki là công cụ không đúng cho thảo luận được triển khai. Chúng ta có một danh sách thư, mà bất kỳ ai cũng có thể tham gia và các lưu trữ là mở sẵn sàng. Vì thế danh sách thư là công cụ đúng và một wiki là một công cụ không đúng. Tư vấn ngày 07/06/2007: Hãy sử dụng đúng công cụ cho đúng công việc.

• Trong quá trình này chúng tôi hy vọng có được nhiều cơ quan hơn đặt chỗ WebPA cho các cơ quan của họ. Từ đây chúng tôi hy vọng xây dựng một cộng đồng những người sử dụng. Tư vấn ngày 15/06/2007: Chăm sóc những người sử dụng của bạn trước hết; không có những người sử dụng của bạn thì sẽ không có dự án. Từ những người sử dụng của bạn thì những người đóng góp của bạn sẽ nổi lên. Hãy nhớ rằng những đóng góp có nhiều dạng, không chỉ về những đóng góp mã, và những người đóng góp có thể có các vai trò khác nhau. Các yêu cầu tính năng, các báo cáo lổi và ý kiến phản hồi của người sử dụng tất cả đều là những đóng góp, như là sự truyền bá và tạo ra sự chú ý trong một cộng đồng lớn hơn.

• Hôm qua tôi đã dự một hội thảo do OSS Watch tổ chức về xây dựng các cộng đồng. Đối với chúng tôi như một dự án nguồn mở non trẻ thì nó thực sự hữu dụng để có những ý kiến của cộng đồng mà chúng tôi làm việc trong đó, nhưng không bao giờ thực sự nghĩ như là một cộng đồng! Tư vấn ngày 21/06/2007: Hãy hỏi OSS Watch để có sự tư vấn!

• Điều này để lại một con đường phải đi, nó sẽ thay đổi các thái độ. Liệu điều này có là lý do tốt nhất của sự chú ý hay không thì chỉ có thời gian mới trả lời được. Tư vấn ngày 21/06/2007: Nếu các thực tiễn hiện hành là thất bại và bạn nghĩ bạn có thể hiểu vì sao hãy nói to và rõ ràng. Đừng kiêu ngạo, đừng nói “cho họ” rằng họ là sai, hãy chỉ dẫn đường và những người mà đồng ý sẽ tới và giúp. Những người mà không đồng ý sẽ thách thức bạn và sẽ giúp bạn đảm bảo rằng bạn đã cân nhắc tất cả các lựa chọn, vì thế bạn có khả năng hơn để chọn đúng con đường.

• Sự tìm tòi tiếp theo của tôi [trong SourceForge] từng để thiết lập một danh sách cho các yêu cầu tính năng và thiết lập một ít danh sách khác cho mọi người sử dụng khi dự án tiến lên một lần nữa. Tư vấn ngày 06/08/2007: Bạn tuyệt đối phải có một hạ tầng cho phép cộng đồng của bạn tham gia vào với bạn. Không mất lâu thời gian để làm và một khi được làm thì nó thực sự làm cho sự quản lý dự án dễ dàng hơn nhiều, thậm chí nếu bạn còn chưa có được một cộng đồng.

• Có những người ở ngoài đó đang cố gắng thay đổi cả hệ thống và văn hóa, chủ yếu nhờ công việc của Randy Metcalfe, và bây giờ là Ross Gardler, và các chị tại OSS Watch. Nhờ có họ mà tôi không còn cảm thấy bị cách li khi họ đã thiết lập một cộng đồng đang thịnh vượng. Tư vấn ngày 14/09/2007: Sự tham gia có khả năng ở đâu với các cộng đồng đang tồn tại.

• Liệu chúng tôi đã có được một sự đột phá, tôi cuối cùng đã dừng nói cho bản thân mình về danh sách thư của JISC được chưa nhỉ? Tư vấn ngày 21/09/2007: Việc xây dựng một cộng đồng là chậm, nó có thể là làm nản lòng, nó có thể là cô độc, nhưng nó là đáng với nỗ lực. Hãy nhẫn nại.

• Tôi đang ở trong quá trình ở vào thời điểm hỗ trợ một số cơ quan với những cài đặt WebPA của riêng họ. Ngày 08/10/2007.

• Tôi đã phát hành một phiên bản WebPA như một bản tải về hôm thứ sáu 05/10. Ngày 08/10/2007.

• Tôi đã được hỏi trong vòng 24 giờ qua về các kế hoạch của dự án để phát triển các module tích hợp cho một VLE đặc biệt. Ngày 16/10/2007.

• Tài liệu lộ trình cho phép các thành viên cộng đồng dự án thấy nơi mà dự án có ý định đi cho pha công việc tiếp sau... Để đảm bảo rằng các nhu cầu của cộng đồng sẽ được phản ánh … Tư vấn ngày 22/10/2007: Hiểu được những người sử dụng của bạn, tham gia với những người sử dụng của bạn, làm thỏa mãn những người sử dụng của bạn bằng việc cung cấp những bản tải về sớm. Không có những người sử dụng của bạn thì dự án của bạn sẽ không bền vững; bạn có càng nhiều người sử dụng thì càng có nhiều khả năng hơn bạn tìm được một con đường có tính bền vững.

• Điều này đặt ra cho tôi phải bổ sung thông tin cho những người theo dõi chính tôi. Lúc này điều này là OK, khi mà không có quá nhiều yêu cầu. Tôi đang khuyến khích những người sử dụng hệ thống SourceForge, nên mỗi lần tôi gửi thư điện tử ngược về vói giải pháp mà tôi cố gắng đưa vào các thông tin theo dõi, cũng như với hy vọng rằng ở một vài thời điểm họ sẽ sử dụng hệ thống đó. Tư vấn ngày 08/10/2007: Khi số lượng những người sử dụng gia tăng, thì sẽ có những đòi hỏi về các hoạt động hỗ trợ của các bạn. Bạn phải khuyến khích những người sử dụng của bạn sử dụng các kênh phù hợp sao cho tải hỗ trợ có thể được dàn ra khắp cộng đồng. Điều này có thể đòi hỏi một sự thay đổi trong hành vi đối với những người sử dụng của bạn nên mục tiêu để hỗ trợ cho họ trong việc áp dụng các qui trình và thủ tục có thể là mới đối với họ.

Hãy nhớ là những người sử dụng thường là những người tốt nhất để hỗ trợ những người sử dụng khác. Mục tiêu là để tạo ra một văn hóa theo đó những người sử dụng mà có sự hỗ trợ tự do từ bạn sẽ có thiện chí đưa ra sự hỗ trợ tự do cho những người khác. Làm điều này thất bại đồng nghĩa là bạn cuối cùng sẽ trở thành một nạn nhân của sự thành công của chính bạn và sẽ không bao giờ có thời gian để phát triển công việc được.

• Nó [được các đóng góp dẫn dắt] là một cách xây dựng một dự án nơi mà mọi người có thể đóng góp yếu tố nhỏ bé mà họ cần và sau đó rời khỏi dự án. Tôi không rõ đã tạo thuận lợi cho dạng hành động này. Tư vấn ngày 26/10/2007: Hãy cân nhắc những đóng góp của bên thứ 3 chỉ như phần thưởng cho tất cả công việc vất vả của bạn trong phát triển cộng đồng.

Để hiểu đầy đủ vì sao những đóng góp nhỏ đó là quan trọng, hãy xem xét trường hợp này của WebPA. Từng có một lỗi nhỏ có thể chỉ xảy ra trong một cấu hình đặc thù trong hệ thống xác thực nên mà WebPA không có khả năng tìm ra nó.

Nếu lỗi đó không được sửa, thì có bao nhiều người sử dụng tiềm năng từng cố gắng sử dụng phần mềm nhưng đã phải bỏ nó vì họ không thể đăng nhập được vào cài đặt ban đầu của họ? Vì mỗi người sử dụng là một người đóng góp tiềm năng, nên mỗi người sử dụng bị mất là một người đóng góp tiềm năng bị mất. Hơn nữa, mỗi người sử dụng bị mất có thể là mất một người sử dụng đang trả tiền cho Loughborough hoặc quả thực bất kỳ thực thể nào khác có thể muốn đưa ra một sản phẩm được trả tiền hoặc một dịch vụ dựa vào WebPA. Nói cách khác mỗi người sử dụng bị mất làm giảm các cơ hội đạt được tính bền vững.

Những sửa lỗi nhỏ là dòng máu nuôi sống một dự án nguồn mở không chỉ vì chúng đảm bảo một số lượng cao hơn những người sử dụng được thỏa mãn, mà còn vì đã có một bản vá được chấp nhận mà người đóng góp có khả năng nhiều hơn để đề xuất bản vá khác, sau đó là những bản vá khác nữa. Cuối cùng bạn có một người lập trình mới để biểu quyết trong dự án của bạn và bạn sẽ đang ở trên con đường của mình tới tính bền vững.

• Một ý của sự tư vấn chúng tôi đã nhận được là hãy làm một bản demo và làm cho nó sẵn sàng cho những người sử dụng tiềm năng để thấy những gì phần mềm có. Điều này đã được đưa ra vào tháng 10. Trong tuần đầu tiên đó chúng tôi đã có một câu trả lời phi thường. Tư vấn ngày 01/11/2007: Hãy làm cho nó càng dễ dàng có thể cho người sử dụng để đánh giá phần mềm của bạn càng tốt.

Nếu ai đó cố thử một demo trực tuyến và thích những gì họ thấy thì họ có khả năng nhiều hơn nhiều để bỏ thời gian tải về và cài đặt phần mềm của bạn. Nếu phần mềm của bạn không thể được đánh giá trực tuyến thì sau đó hãy tạo ra một loạt các hình chụp màn hình và/hoặc đoạn ghi hình màn hình (thực sự chúng là hữu dụng cho phần mềm mà cũng có thể được đánh gía trên trực tuyến).

Liệu công việc nặng nhọc này có đảm bảo cho tính bền vững không?

WebPA đã làm được một công việc không thể tin nổi về xây dựng cấu trúc hỗ trợ cộng đồng xung quanh mã của họ, họ thậm chí đang bắt đầu thấy hoạt động cộng đồng thực sự.

Liệu tất cả các nỗ lực này có làm cho dự án bền vững hay không? Còn quá sớm để nói. Việc xây dựng các cộng đồng bền vững mất thời gian dài. Ví dụ, đồ thị hoạt động này trong danh sách thư của Quỹ Phần mềm Apache chỉ ra rằng mất khoảng 4 năm trước khi cộng đồng Apache cất cánh.

Mặc dù là quá sớm để nói liệu WebPA sẽ đạt được tính bền vững hay không thì có thể nói điều này: nếu người sử dụng tiếp tục đánh giá cao giá trị của phần mềm này và đội WebPA tiếp tục hỗ trợ chủ động tích cực họ theo cách này thì những cơ hội đạt được tính bền vững là rất cao vì tất cả các lựa chọn bây giờ là sẵn sàng.

WebPA nhất định trao cho bản thân nó cơ hội tốt nhất có thể.

Hiện trạng ư?

Tháng 06/2009: Từ khi tạo tại liệu gốc ban đầu này thì việc cấp vốn của JISC đã kết thúc nhưng đội gốc ban đầu vẫn còn tích cực. Một cộng đồng bây giờ tồn tại với khoảng 17 người sử dụng là các cơ quan và những người khác đang thực hiện các đánh giá. Những đóng góp sớm đã được đưa ra thông qua những đóng góp mã là chậm. Bây giờ đội đang xem xét những lựa chọn cho đường hướng trong tương lai trong khi mô hình điều hành cho phép những người tham gia gây ảnh hưởng tới những quyết định có tác động tới tính bền vững trong pha mới này.

Tháng 12/2009: Có một ít bằng chứng về hoạt động trong dự án, tuy nhiên các vấn đề vẫn đang được đưa vào trong trình theo dõi, nó chỉ ra rằng cộng đồng tiếp tục sử dụng công cụ đó.

Tháng 06/2010: Danh sách thư của cộng đồng WebPA tiếp tục thấy hoạt động và một cuộc họp của WebPA SIG đã diễn ra vào tháng 04/2010.

Tháng 06/2010: Danh sách thư của dự án tiếp tục là tích cực, và một ít các phiên bản đã được sử dụng vào cuối năm 2010. Dự án bây giờ ở giai đoạn alpha và phiên bản hiện hành là 1.0.0.6.

Tháng 12/2011: Như một phần của công việc để tích hợp WebPA sát sao hơn với các VLE, hệ thống từng được sử dụng như một trường hợp điển hình trong dự án ceLTIc được JISC cấp vốn, nó xem xét những triển khai của đặc tả về Tính tương hợp Các công cụ Học - LTI ( Learning Tools Interoperability) IMS. Một WebPA v.2 hiện đang được chuẩn bị để cho phép tích hợp LTI dễ dàng hơn nữa.

OSS Watch is funded by JISC to provide support and guidance on the use and development of free and open source software and licences. One of the ways that this can be achieved is through detailed one-on-one consultations with projects. OSS Watch has now conducted a significant number of consultations and is extremely pleased to report on some genuine results f-rom that activity.

A significant consultation in early 2007 took place with the WebPA project. This JISC-funded project will make an open source version of an existing online peer moderated marking system and is especially interested in building a community support structure. Following a consultation with OSS Watch, the WebPA project, largely driven by Nic Wilkinson, took active steps to build a community support structure and it now seems that all that hard work is paying off. As a result WebPA makes an interesting case study as a model for all projects wishing to go down an open development route.

The WebPA blog

WebPA set up two project blogs as a mechanism to keep the community up-dated on what was happening. One blog concentrated on the technical development of the project (the technical blog) and the other on pedagogic research and the development of framework for the project (the research blog). The technical blog is a treasure trove for anyone interested in open development as it provides real life examples of the issues faced by the project and the practical steps taken to address them. More importantly for OSS Watch it provides a concrete example of how a JISC funded project can successfully take our advice and tailor it to their specific case. To illustrate this, consider these blog excerpts, listed here alongside OSS Watch’s specific advice to which they relate.

• I never imagined that choosing the potential licence that we would use could be so difficult. This is all leading up to the writing of the consortium agreement and the future open source release of WebPA. _2 January 2007_Advice: Sort out your licence and IPR position early. In an ideal world, the licence will be decided before the project starts or at least as soon as software dependencies have been identified.

• We have also managed to get some very basic presentations together as an introduction to the project…. Our other major mile stone is getting a JISCmail list. 17 January 2007

• The WebPA Project has started to disseminate further afield in ‘DLib’ magazine. _8 February 2007_Advice: Make sure your potential community is aware of you and can communicate with you f-rom day one; sure they won’t come flocking to your door yet, but creating a brand is the first step. Simply ensuring that all disseminated materials are identified as coming f-rom your project goes a long way towards cementing your brand.

• Yesterday we had a very informative meeting with Ross and Rowan f-rom OSS-Watch. 7 March 2007

• All this to do and two open source books to read! _23 March 2007_Advice: Do your research, building a community led project is not hard, but it is quite different to any other kind of project structure and it won’t happen overnight for you. Understanding best practice and figuring out how to apply it to your work is the key to success.

• As with everything related to agreements and IPR, there is a distinct lack of understanding as to the amount of work that needs to be completed. There is also a distinct lack of understanding as to why this can be so important to the project and its potential success. _24 April 2007_Advice: Recognise that you don’t know everything and get advice early. Once you have got that advice make sure that it is communicated effectively to both the project team and the community.

• Just to make sure that we are getting our moneys worth out of OSS-Watch (not that we pay) I asked some colleagues here at Loughborough if they would like to join the WebPA team for a couple of hours and sit in. Everyone who attended to find out about Communities has given positive feedback. People have said that they wished they had been able to give more time to attending the afternoon session, to find out more. _10 May 2007_Advice: Always help those who help you and give credit whe-re it is due.

• It has also highlighted to the WebPA team some of the routes that the project can take as exit strategies or (a better term) project sustainability f-rom when the funding runs out. _10 May 2007_Advice: Plan for sustainability as early as is practical. OSS Watch encourages you to consider it during the bid phase and can help with this. The sooner you start planning for it the more likely it is to happen.

Sustainability is concerned with the ongoing survival of the project, or the project’s outputs, after the current round of funding. There are many sustainability routes available to projects including donating all outputs to a suitable parent project, exploiting the outputs commercially or depositing in appropriate repositories. It is vital to note that in the case of software it is not sufficient to simply make the source code available in a “forge” such as SourceForge.

• However, this is now giving me a headache! I have made it overly complicated. _15 May 2007_Advice: Keep it simple. Make it do what users want it to do and nothing more. Keeping it simple not only helps you, but it also helps anyone coming to the code as a potential contributor.

• After a fairly swift poll of the project partner and the other potential pilot the opportunity to use LDAP arose…. The first problem I encountered was… _25 May 2007_Advice: Be open about issues you are facing and how you intend to address them. By now you have a small audience, someone out there may have the answer, or may stop you making the wrong decision.

Best practice suggests that issues should be discussed on a mailing list rather than a blog since the intention should be to encourage contributions of all kinds. People can only comment on blogs, they can’t cre-ate new posts so their contributions are limited to the topics you choose. However, some community members may be more likley to engage with a blog post than a mailing list and vice versa so an interesting compromise could be to deal with a particular issue on the mailing list and then to re-iterate the point with a follow up blog post. This will maximize exposure within your target audience.

• Who is our community and what exactly will the wiki be used for? _7 June 2007_Advice: Don’t use technology simply because it is “cool”.

• A wiki is not the correct tool for discussion to be carried out on. We have a mailing list, which anyone can join and the achieves are openly available. Hence the mailing list is the correct tool and a wiki is an incorrect tool. _7 June 2007_Advice: Use the right tool for the right job.

• In this process we hope to get more institutions to host WebPA for their academics. F-rom this we hope to build a community of users. _15 June 2007_Advice: Look after your users first; without your users there is no project. F-rom your users your contributors emerge. Remember that contributions take many forms, it’s not just about code contributions, and contributors may have different roles. Feature requests, bug reports, bug fixes, and user feedback are all contributions, as is evangelism and generating attention in the wider community.

• Yesterday I attended a workshop run by OSS-Watch on building communities. For us as a young open source project it was really useful to get the opinions of the community that we work within but never really think of as a community! _21 June 2007_Advice: Ask OSS Watch for a consultation!

• This leaves one route to go down, which is to change attitudes. Whether this is the best course of action only time will tell _21 June 2007_Advice: If current practices are failing and you think you may understand why speak loud and clear. Don’t be arrogant, don’t tell “them” they are wrong, just lead the way and those who agree will come and help. Those who don’t agree will challenge you and will help you ensure that you have considered all options, thus you are more likely to choose the right path.

• My next delve [into SourceForge] was to set up a list for feature requests and set up the few other lists for people to use when the project moved forward again. _6 August 2007_Advice: You absolutely must have an infrastructure that allows your community to engage with you. It doesn’t take long to do and once done it actually makes project management much easier, even if you don’t have a community yet.

• There are people out there trying to change both the system and the cultures, mainly thanks to the work of Randy Metcalfe, and now Ross Gardler, and the lads [and ladies] at OSS-Watch. Due to them I no longer feel isolated as they have set up a community which is thriving. _14 September 2007_Advice: Whe-re possible engage with existing communities.

• Have we a break through, have I finally stopped talking to my self on the JISCmail list? _21 September 2007_Advice: Building a community is slow, it can be frustrating, it can be lonely, but it is worth the effort. Be patient.

• I am in the process at the moment of supporting a number of institutions with their own installations of WebPA. 8 October 2007

• I released a version of WebPA as a download on Friday 5 October 8 October 2007

• I have in the past twenty four hours been asked about the projects plans to develop integration modules for a particular VLE. 16 October 2007

• The road map document lets the projects community members see whe-re the project is intending to go for the next phase of work… In order to ensure that the community needs are reflected… _22 October 2007_Advice: Understand your users, engage with your users, satisfy your users and make it easy for users by providing early downloads. Without your users your project will not be sustainable; the more users you have the more likely you are to find a sustainability route.

• This leaves me to add the information to the trackers myself. At the moment this is okay, as there are not too many requests. I am encouraging the users to use the SourceForge system, so every time I email back with the solution I endeavor to include tracking information, as well in the hope that at some point they will use the system. _8 October 2007_Advice: As the number of users grows, so will the demands on your support activities. You must encourage your users to use the proper channels so that the support load can be spread across the community. This may require a change in behaviour for your users so aim to support them in adopting processes and procedures that may be new to them.

Remember users are usually the best people to support other users. The aim is to cre-ate a culture in which users who got free support f-rom you are willing to give free support to others. Failure to do this means that you will eventually become a victim of your own success and will never have time to do development work.

• It [drive-by contributions] is a way of building a project whe-re people can contribute the small element they need to and then leave the project. Unknowingly I facilitated this type of action _26 October 2007_Advice: Consider third party contributions as just reward for all your hard work on community development.

To fully understand why these small contributions are important consider this WebPA case. It was a small bug that would only occur in a specific configuration in the authentication system so it was unlikely WebPA would find it.

If this bug went unfixed, how many potential users would try to use the software but give up because they couldn’t log in to their initial installation? Since every user is a potential contributor, each lost user is potentially a lost contributor. Furthermore, each lost user could be a lost paying customer for Loughborough or indeed any other entity that might want to offer a paid product or service based on WebPA. In other words each lost user results in a decrease in the chances of reaching sustainability.

These small fixes are the lifeblood of an open source project not only because they ensure a higher number of satisfied users, but also because having had one patch accepted the contributor is more likely to submit another, then another and another. Eventually you have a new developer to vote into your project and you are on your way to sustainability.

• One piece of advice we were given was to make a demonstrator and make it available to potential users to see what the software is about. Well this was realised at the end of October. Within this first week we have had a phenomenal response. _1 November 2007_Advice: Make it as easy as possible for users to evaluate your software.

If someone tries an online demo and likes what they see they are far more likely to spend the time downloading and installing your software. If your software cannot be evaluated online then cre-ate a series of screenshots and/or screencasts (actually they are useful for software that can be evaulated online too).

Does this hard work guarantee sustainability?

WebPA has done an incredible job of building a community support structure around their code, they are even starting to see genuine community activity.

Will all this effort make the project sustainable? It is far too early to tell. Building sustainable communities takes a long time. For example, this graph of activity on The Apache Software Foundation’s mailing lists shows that it took around four years before the Apache community took off.

Although it is too early to say whether WebPA will reach sustainability it is possible to say this: if the users continue to appreciate the value of this software and the WebPA team continue to proactively support them in this way the chances of reaching sustainability are very high since all options are now available.

WebPA is certainly giving itself the best chance possible.

Current status?

June 2009: Since the original creation of this document the JISC funding has ended but the original team remain active. A community now exists with some 17 institutional users and others are performing evaluations. Early contributions have been provided though code contributions are slow. Now the team are considering options for the future direction while the governence model allows participants to influence the decisions which impact sustainability in this new phase.

December 2009: There is little evidence of activity within the project, however issues are still entered in the tracker, which indicates that the community continues to use the tool.

June 2010: The WebPA community mailing list continues to see activity and a WebPA SIG meeting took place in April 2010.

June 2011: The project mailing list continues to be active, and a few releases were issued at the end of 2010. The project is now in alpha stage and the current release is 1.0.0.6.

December 2011: As part of the work to integrate WebPA more closely with VLEs, the system has been used as a case study in the JISC-funded ceLTIc project, which looks at implementations of the IMS Learning Tools Interoperability (LTI) specification. A WebPA v.2 is currently being prepared to allow LTI integration more easily.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com