Các bài học về tính bền vững đối với hạ tầng nghiên cứu

Sustainability lessons for research infrastructure

By Gabriel Hanganu, Published: 09 August 2010, Reviewed: 14 February 2012

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

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

Lời người dịch: Nhiều nhà nghiên cứu và cơ quan nghiên cứu không muốn cộng tác với nhau vì sợ mất các dữ liệu nghiên cứu. Tuy nhiên, có những lĩnh vực mà họ nên có sự cộng tác với nhau, ví dụ như trong hạ tầng nghiên cứu. Hạ tầng nghiên cứu, hạ tầng điện tử và nghiên cứu điện tử là gì, làm thế nào để chúng có tính bền vững và chúng học được từ các mô hình phát triển mở của các dự án nguồn mở những gì, là nội dung của bài viết này. “Một số bài học về tính bền vững của phát triển mở có thể giúp loại bỏ các rào cản cho sự tham gia với các công cụ và dịch vụ của hạ tầng nghiên cứu. Chúng bao gồm việc xây dựng các kế hoạch về tính bền vững và quản lý của dự án, tránh dựa hoàn toàn vào sự hỗ trợ phát triển được trung ương cung cấp, và các nhà nghiên cứu và các nhà cung cấp dịch vụ có khả năng thúc đẩy ý thức cộng đồng sâu sắc hơn xuyên khắp hạ tầng nghiên cứu ... và cuối cùng cải thiện được tính hiệu quả của nó”. Có thể nó rất cần cho các nhà nghiên cứu và những người ra chính sách nghiên cứu tham khảo.

Bất chấp sự sẵn sàng của một dải ấn tượng các hệ thống và tài nguyên trực tuyến cho các nhà nghiên cứu của nước Anh, Báo cáo về Sự tham gia Cộng đồng (Community Engagement Report) gần đây do JISC cấp vốn đã xác định một số rào cản cho sự áp dụng chúng. Chúng bao gồm những cơ hội bị hạn chế cho sự cộng tác giữa các đối tác cạnh tranh trong qui trình đấu thầu, sự thiếu nhận thức về chia sẻ mở các kết quả nghiên cứu, và sự cung cấp dài hạn không phù hợp hỗ trợ phát triển phần mềm. Hãy nhìn sát hơn vào một số rào cản đó, và khai thác cách mà kinh nghiệm từ thực tiễn phát triển mở (bản dịch tiếng Việt) có thể được sử dụng để làm dịu bớt hoặc loại bỏ chúng.

Giới thiệu

Hạ tầng kỹ thuật được xây dựng để hỗ trợ các nhà nghiên cứu nước Anh (được biết tới như là Hạ tầng Điện tử - HTĐT – e-Infrastructure) bao gồm một sự kết hợp các hệ thống và dịch vụ được thiết kế để cải thiện sự cộng tác xuyên chủ đề và thúc đẩy các cách thức mới tiến hành nghiên cứu (cũng được tham chiếu tới như là Nghiên cứu Điện tử - NCĐT – e-Research). Tuy nhiên, cho tới nay, các nhà nghiên cứu của nước Anh đã chỉ ra một số hạn chế trong việc sử dụng các dịch vụ và cơ sở đó theo cách thức có ý nghĩa. Những rào cản chính cho một sự áp dụng rộng rãi hơn là về xã hội và tổ chức hơn là công nghệ. Chúng tôi gợi ý rằng việc học và áp dụng một số bài học chính từ thực tiễn phát triển mở có thể cải thiện hiện trạng.

Chúng tôi tiếp cận chủ đề này trong 3 tài liệu có liên quan: một thảo luận chung (bản dịch tiếng Việt) và 2 tài liệu sâu về chi tiết hơn, Các bài học của Cộng đồng về Hạ tầng Nghiên cứu (HTNC) (bản dịch tiếng Việt) và Các bài học về Tính bền vững của Hạ tầng Nghiên cứu (tài liệu này), chúng đều bao gồm các trích dẫn từ các nhà nghiên cứu và các nhà cung cấp dịch vụ của nước Anh được phỏng vấn cho Báo cáo về sự Tham gia Cộng đồng. Trong tài liệu này, chúng tôi nhấn mạnh một số bài học về tính bền vững từ thực tiễn phát triển mở mà có thể giúp loại bỏ các rào cản để tham gia vào các hệ thống và dịch vụ của HTĐT nước Anh.

Hiểu về tính bền vững của phần mềm trong các điều khoản rộng lớn hơn

Tính bền vững của các dự án nghiên cứu hàn lâm (và các kết quả đầu ra của chúng, bao gồm cả phần mềm) được hiểu chủ yếu theo những điều khoản của việc đảm bảo cấp vốn tiếp tục. Tuy niên, trong các cộng đồng phát triển mở thì tính bền vững được hiểu theo các điều khoản rộng rãi hơn. Việc mở rộng vượt ra khỏi đội khởi xướng và việc khai thác những đóng góp từ tất cả các bên có tiềm năng và có quan tâm là những đặc tính chủ chốt của thực tiễn phát triển mở. Các tài nguyên được yêu cầu cho sự phát triển và hỗ trợ liên tục các kết quả đầu ra của nghiên cứu có thể được hỗ trợ theo các cách thức khác nhau (bản dịch tiếng Việt). Bằng việc để mở ngang bằng cho những đóng góp từ các bên khác, các dự án nghiên cứu hàn lâm có thể tối đa hóa những cơ hội của chúng để trở nên bền vững về lâu dài.

Thừa nhận tình trạng mẫu của phần mềm trong các dự án nghiên cứu hàn lâm

Tính bền vững của các công cụ và dịch vụ hạ tầng nghiên cứu thường được nhắc tới như là một nguồn các mối quan ngại tiềm năng cho các nhà nghiên cứu. Một khía cạnh của sự quan ngại này là độ tin cậy của các giải pháp kỹ thuật mà các dự án nghiên cứu hàn lâm đưa ra trong việc cấp vốn có giới hạn về thời gian. Điều này là sống còn cho quyết định của các nhà nghiên cứu áp dụng chúng:

'Vì bạn đang làm việc với các sản phẩm mà được đưa ra từ nghiên cứu hơn là từ một xưởng sản xuất phần mềm, và thường chúng sẽ có những vấn đề hoặc chúng sẽ được hoàn thiện một nửa hoặc chúng còn chưa thực sự phù hợp […] khó để giải mã được đâu là rủi ro trước khi bạn bắt đầu'.

Để giải quyết sự quan ngại này, nên được làm rõ đối với các dự án rằng hầu hết các phần mềm này còn chưa sẵn sàng để sử dụng nói chung, và đòi hỏi thời gian và kỹ năng đáng kể từ những người sử dụng để thực sự triển khai được:

'Hầu hết các phần mềm nghiên cứu hàn lâm dường như có tuổi thọ khoảng 1 năm trước khi nó biến mất, hoặc không được cập nhật, hoặc thứ gì đó, và chúng tôi chỉ không thể làm việc như vậy được'.

Các chi phí phát triển ban đầu có liên quan tới việc xây dựng các công cụ của HTNC thường được các khoản tiền trợ cấp nghiên cứu có giới hạn về thời gian trang trải. Vì thế, tính hoàn thiện và tính khả dụng của chúng là hạn chế. Bổ sung thêm, sự áp dụng chúng từ những người sử dụng sớm thường tạo ra những yêu cầu tiếp tục, và nhu cầu cung cấp sự duy trì liên tục. Dự án đơn giản không thể đưa ra được điều này:

'Thật khó vì một nhóm nghiên cứu […] có một số sinh viên làm nghiên cứu sinh và đó không phải là một công ty kỹ thuật phần mềm. Nên cuối cùng khi bạn phân phối thứ gì đó thì nó chỉ là một mẫu vật, nó không bao giờ là một sản phẩm hoàn chỉnh cả. Mà họ sau đó bắt đầu phụ thuộc vào nó, và sau đó vấn đề nảy sinh, vì bạn không có sự cấp vốn hoặc thậm chí khả năng duy trì [nó...] bất kể khi nào họ muốn thay đổi thứ gì đó, và họ không có tiền để làm thứ y hệt, vì họ không thể chỉ nói, ô có một số tiền dư thêm chỉ để bổ sung tính năng này còn chưa tồn tại, nên nó sẽ là rất hạn chế'.

Các phát hành sớm và thường xuyên là sống còn cho việc xây dựng một dự án nguồn mở bền vững: các phát hành lôi cuốn những người sử dụng, một số người sử dụng đó sẽ trở thành những người đóng góp, và nhiều người đóng góp hơn nữa làm cho dự án mạnh hơn. Nhược điểm của việc phát hành sớm và thường xuyên là phát hành cần quản lý những kỳ vọng của người sử dụng. Các dự án cần phải rõ ràng về tình trạng các phát hành của chúng và lôi cuốn sự chú ý tới bất kỳ lỗi được biết nào trong tài liệu.

Tránh dựa hoàn toàn vào sự phát triển của trung ương

Các đội được giao nhiệm vụ xây dựng và duy trì các công cụ HTNC theo truyền thống làm việc trong các dự án môi trường đóng. Công nghệ hoặc phần mềm được phát triển được giữ an toàn bên trong ranh giới của đội, và sự không cộng tác được dự tính hoặc được thấy từ bên ngoài. Một người có thể viện lý rằng không có gì đặc biệt về điều này, vì nhiều công cụ và tài nguyên mà các nhà nghiên cứu sử dụng được sản xuất theo cách này. Tuy nhiên, NCĐT đặt sự nhấn mạnh đáng kể trong việc chia sẻ và cộng tác. Một người có thể vì thế kỳ vọng sẽ có khả năng cho các đội có sẵn một số cơ chế theo đó sự đóng góp từ bên ngoài có thể được khai thác vì lợi lích của toàn bộ cộng đồng. Phần mềm được sản xuất theo cách này có thể được phát hành theo một giấy phép nguồn mở và các tài liệu điều hành (bản dịch tiếng Việt) phù hợp có thể được viết để khuyến khích những người đóng góp từ các bên thứ 3 phát triển tiếp sản phẩm đó bằng việc bổ sung thêm các tính năng quan trọng cho các nhu cầu của họ.

Ví dụ, lấy một tình huống điển hình được mô tả trong báo cáo về sự Tham gia Cộng đồng có liên quan tới sự dụng GridSAM. GridSAM là một giao diện đệ trình công việc cho các hệ thống quản lý tài nguyên phân tán, ban đầu được phát triển tại Trung tâm Khoa học Điện tử Luân Đôn và sau đó được các lập trình viên tại Viện Hạ tầng Phần mềm Trung gian Mở (OMII-UK) mở rộng:

'Không may chúng tôi thấy rằng GridSAM có một số vấn đề, và không may GridSAM không còn được phát triển tích cực nữa […]. Phụ thuộc vào những gì xảy ra qua 3 hoặc 4 tháng tới chúng tôi có thể sẽ hoặc bắt đầu đi với […] các giải pháp mà làm việc tốt hơn cho các mục đích của chúng tôi hoặc tự chúng tôi thử và sửa GridSAM, tôi muốn gợi ý. Tôi ngụ ý [OMII] đã và đang cố gắng cật lực, nhưng rõ ràng rất khó vì các lập trình viên được sử dụng trong thứ gì đó hoàn toàn khác, nên hoàn toàn khó để có được sự hỗ trợ vì rất nhiều vấn đề của phần mềm OMII, dù họ đang cố gắng cật lực để cải thiện điều đó. Không may hầu hết các phần mềm trong kho của OMII là chưa hoàn chỉnh, đó chính là vấn đề'.

Mô hình phát triển phần mềm của OMII mà nhà nghiên cứu này tham chiếu tới là mô hình trong đó phần mềm ở giai đoạn đầu từ các dự án nghiên cứu được chọn được 'tăng cường' và được hỗ trợ cho tới thời điểm các kết quả đầu ra của nghiên cứu được pháp hành. Mã được phát hành theo giấy phép nguồn mở, sao cho bất kỳ ai cũng có thể cung cấp sự đóng góp. Tuy nhiên, trong thực tế, không có các cơ chế cộng đồng để khuyến khích và tưởng thưởng cho sự đóng góp bên ngoài, thì điều này hiếm khi thực hiện được.

Một mô hình 'cơ bản' hơn mà có thể được thấy trong các môi trường nguồn mở bên ngoài khu vực hàn lâm là Vườn ươm Apache (Apache Incubator). Các dự án ở đây không được xem là các dự án bền vững chính thống đối với Quỹ Phần mềm Apache cho tới khi có ít nhất 3 người đề xuất tích cực từ các nhân viên khác.

Thực tế là OMII đưa ra mức phát triển và hỗ trợ nhất định cho một giai đoạn thời gian có giới hạn dường như đủ tốt cho một số nhà nghiên cứu. Tuy nhiên, như những người trả lời khác chỉ ra, có lẽ các vấn đề đó cần phải được giải quyết theo một cách cơ bản hơn:

'Cách thức theo đó việc cấp vốn được cung cấp cho các dự án phát triển phần mềm có thể cần phải được thay đổi một cách cơ bản, sao cho chúng bắt đầu sản xuất là các sản phẩm tự bền vững hơn là chỉ là các mẫu'.

Xây dựng và xuất bản các kế hoạch quản lý và tính bền vững của dự án

Một vấn đề mà OSS Watch thường nghe thấy khi tư vấn với các dự án nghiên cứu là về việc cấp vốn tiếp tục. Việc đảm bảo đi theo việc cấp vốn ở cuối của dự án được hiểu như là một sự thừa nhận sự thành công của nó. Thất bại để làm như vậy được xem như một sự thể hiện sự bất lực của dự án để thuyết phục các nhà cấp vốn rằng những gì họ đã làm là đáng giá.

Tuy nhiên, điều này rõ ràng không phải là cách duy nhất trong đó các đội phát triển mở vận hành. Sự hỗ trợ vượt ra ngoài việc cấp vốn ban đầu có thể tới ở các dạng khác (bản dịch tiếng Việt). Chúng bao gồm sự bỏ ra thời gian của cả những người sử dụng và các lập trình viên trong dự án, cơ chế đỡ đầu từ các thành viên tập đoàn có quan tâm, hoặc sự hỗ trợ có trả tiền cho sự duy trì sản phẩm đang được phát triển. Tất cả các cách thức trong đó dự án thấy bản thân nó đang được duy trì và hỗ trợ được đặt ra cùng trong một kế hoạch về tính bền vững. Nếu kế hoạch này được làm cho sẵn sàng trên trực tuyến, thì tầm nhìn cho dự án trở nên rõ ràng hơn. Sự minh bạch và trách nhiệm của nó cũng gia tăng, và những thành viên mới có tiềm năng có thể lên kế hoạch tốt hơn cho sự tham gia của họ với cộng đồng.

Việc mở rộng vượt ra ngoài đội khởi xướng và việc khai thác những đóng góp từ những người tham gia có quan tâm là những tính năng chính của thực tiễn phát triển mở (bản dịch tiếng Việt). Nếu các công cụ và các qui trình được các thành viên dự án sử dụng hàng ngày được làm minh bạch và cuốn hút, và con đường áp dụng trong cộng đồng là rõ ràng, chào đón và đầy đủ thông tin, thì những người đóng góp mới sẽ tham gia. Họ sẽ bị cuốn hút bởi viễn cảnh được là một phần của một dự án có tiềm năng thành công và tự bền vững. Một số những người đóng góp đó có thể được trả tiền từ các ông chủ khác nhau để làm việc trong những khía cạnh đặc biệt của sản phẩm. Những người khác có thể bị lôi cuốn bởi thách thức về kỹ thuật, viễn cảnh có được tiếng tăm, hoặc đơn giản có cơ hội cải thiện hoặc trình diễn các kỹ năng của họ. Tất cả chúng và các dạng tham gia chấp nhận được khác với những người cộng tác bên ngoài có thể được xem và được chỉ định trong tài liệu điều hành (bản dịch tiếng Việt) của dự án.

Thúc đẩy cộng tác nghiên cứu từ giai đoạn đầu

Làm việc theo một cách thức mở là thứ gì đó mà không chỉ các lập trình viên, mà cả các nhà nghiên cứu bản thân họ có thể được khuyến khích để học. Một điều kiện quan trọng cho thành công trong các dự án phát triển mở là có thứ gì đó mà có thể được chạy và kiểm thử càng sớm có thể càng tốt. Điều này có thể có nghĩa là việc chia sẻ một sản phẩm còn chưa hoàn chỉnh và chưa tuyệt vời. Việc học cách làm việc cùng nhau từ giai đoạn đầu trong những sản phẩm còn chưa hoàn chỉnh cũng có thể giúp các nhà nghiên cứu trở thành các thành viên tích cực hơn của các cộng đồng HTNC đang nổi lên.

Hiểu những động lực đối với sự cộng tác nghiên cứu

Tính sẵn sàng cộng tác là một chỉ số hữu dụng của mức độ tin cậy giữa những người tham gia dự án, động lực của họ để làm việc cùng nhau và chia sẻ ý nghĩa của tính hiệu quả trong hợp tác, vượt ra khỏi việc chỉ thúc đẩy cùng nhau để thi hành chỉ lệnh của các nhà cấp vốn. Tất cả những điều đó là sống còn cho sự thành công của cộng tác khoa học trực tuyến. Vì thế điều quan trọng để hiểu được những động lực cho sự cộng tác của các nhà nghiên cứu. Chúng bao gồm việc tổng hợp các kỹ năng, nỗ lực và các tài nguyên có thể để thúc đẩy chất lượng qui trình nghiên cứu. Quan trọng tương tự để hiểu được những rào cản cho sự cộng tác, hầu hết chúng là trực tiếp hoặc gián tiếp có liên quan tới việc cấp vốn.

'Ở mức độ nhất định, các trung tâm nghiên cứu là cạnh tranh nhau. Vì thế có một sự miễn cưỡng nhất định, tôi nghĩ, trong các trung tâm nghiên cứu riêng rẽ trong việc chia sẻ cùng các nguyên tắc những gì mà họ đang làm. Họ có thể đấu thầu vì một dự án nghiên cứu để cạnh tranh với nhau'.

Nghiên cứu quả thực là sự cạnh tranh, và sức ép được thực thi của những yêu cầu 'xuất bản hoặc diệt vong của Thực thi Đánh giá Nghiên cứu - RAE (Research Assessment Exercise) tiếp tục ảnh hưởng tới các nhà nghiên cứu' có thiện ý làm việc một cách cộng tác.

'[RAE] khuyến khích các cá nhân xuất bản độc lập, để giữ các mọi điều bí mật trong khi có thể có nhiều ưu thế cho sự nghiệp của họ, bất kể liệu chúng từng được cấp vốn công khai hay không, vì bằng cách làm như vậy họ dường như sẽ tốt hơn với những tiêu chí được sử dụng cho sự đo đếm sự thực thi đánh giá nghiên cứu. Đó là một vấn đề chính về văn hóa, vì nó làm cho quá khó khăn để thuyết phục các nhà khoa học là mở với các dữ liệu của họ, họ sợ mất nó, và vì thế cả vị trí hiện hành của họ'.

Một cách tính tới sự cạnh tranh nhân tạo dựa vào cấp vốn dẫn dắt tới sự bí mật và nguồn tác giả dạng đóng cửa là phải chia sẻ từ giai đoạn đầu của một dự án. Ở điểm này, ý thức sở hữu của một nhà nghiên cứu vẫn còn khá thấp. Việc mời các đối thủ cộng tác theo cách thức mở có thể lát đường cho việc biến sự cạnh tranh loại trừ lẫn nhau thành sự cộng tác làm giàu lẫn nhau (bản dịch tiếng Việt). Các cá nhân và các trung tâm nghiên cứu có sự cạnh tranh nhau vì thế có thể được khuyến khích để thiết lập các liên minh chiến lược giữa các nhóm đồng thuận để viết các đề xuất các khoản trợ cấp, chia sẻ công việc dự án và xuất bản các kết quả đầu ra của các nghiên cứu cùng với nhau.

Công việc đáng kể trong lưu ý này từng được NESTA triển khai thông qua chương trình Crucible của nó, trong đó các cơ sở nghiên cứu sự nghiệm được chọn sớm đã được khuyến khích để đổi mới bằng việc cộng tác xuyên khắp các nguyên tắc nghiên cứu. Như trong sách xuất bản năm 2009, một diễn giả chính của chương trình Crucible đã đưa nó ra trong một bài viết sớm hơn:

'Những gì chúng tôi cần hơn bao giờ hết vào lúc này, là một cộng đồng nghiên cứu mạnh mẽ và đa dạng làm việc về một dải rộng lớn các vấn đề, và để tìm các công cụ cộng tác tốt hơn sao cho để kết nối có hiệu quả các giải pháp không ngờ tới cho những vấn đề trong các lĩnh vực khác nhau'.

Bài học khác mà có thể học được từ thực tiễn phát triển mở là việc khuyến khích tính khả dụng các kết quả đầu ra của các dự án. Các cộng đồng nguồn mở thành công biết rằng sự đóng góp cuốn hút từ bên ngoài phụ thuộc vào sự dễ dàng theo đó mã phần mềm, tài liệu, bộ nhớ của dự án và các kết quả đầu ra khác có thể được những người khác truy cạp và được cải tiến. Việc tối ưu hóa qui trình sử dụng này và việc sử dụng các kết quả đầu ra là mấu chố cho sự tăng trưởng và bền vững của các dự án phát triển mở. Theo một cách thức tương tự, các nhà nghiên cứu có thể hưởng lợi bằng việc xuất bản nghiên cứu của họ trong một định dạng phù hợp trên trực tuyến và việc tối ưu hóa nó để sử dụng lại và khả năng khai thác được gia tăng. Bằng cách này, cơ hội hình như bị bỏ qua của việc không xuất bản trong một tạp chí in có tiếng tăm có thể được cân bằng bởi khả năng khai thác được cải thiện và tiềm năng cao hơn cho sự đóng góp từ bên ngoài cho các kết quả đầu ra được chia sẻ.

Xem xét việc chia sẻ hạ tầng nghiên cứu

Các môi trường nguồn mở đánh giá cao sự đa dạng chuyên nghiệp đối với tiềm năng của nó để tạo ra các giải pháp đổi mới các vấn đề. Các đội nghiên cứu cũng có thể học được từ thực tiễn này. Việc chia sẻ các dạng dữ liệu nghiên cứu nhất định không phải lúc nào cũng có khả năng, nhưng sự cộng tác nghiên cứu không nhất thiết cần được hiểu chỉ trong những điều khoản chia sẻ dữ liệu. Trong thực tế việc làm rõ sự khác biệt giữa việc chia sẻ các dữ liệu nghiên cứu và việc chia sẻ hạ tầng nghiên cứu là một cách thức tốt để đánh giá các mức độ mà ở đó các cộng đồng nghiên cứu khác nhau được chuẩn bị để cộng tác. Bằng việc va chạm các vấn đề chung ở những giai đoạn sớm khi sử dụng các tài nguyên được chia sẻ, các đội nghiên cứu khác nhau có cơ hội nói chuyện với nhau. Điều này có thể lát đường cho các dạng cộng tác nghiên cứu không thể tưởng tượng được trước đó.

Nhiều phòng của các trường đại học đối mặt với viễn cảnh của việc cùng tổ hợp các tài nguyên để giảm các chi phí chồng chéo nhau:

'Tôi nghĩ chúng ta có thể xem xét chia sẻ các cơ sở giữa các phòng ở đây như một cách nâng cao sức mạnh và giữ cho mọi điều được quản lý cục bộ. Điều đó có thể là gợi ý của tôi cho ít nhất 5 năm tới'. Ví dụ, một số phòng thấy hữu dụng để có tất cả các nhu cầu tính toán sức mạnh cao được dàn xếp cục bộ để tránh chi phí điều hành có liên quan tới việc sử dụng Dịch vụ Grid Quốc gia (NGS). Tuy nhiên, các rào cản cho việc chia sẻ sức mạnh tính toán có lẽ sẽ xuất hiện ở cả các mức kỹ thuật và hành chính. Trong trường hợp này, các chính sách và sự hỗ trợ cho việc chia sẻ tài nguyên cần phải được cung cấp, nếu không những sáng kiến của các nhà nghiên cứu riêng rẽ có thể không thành công được:

'Tôi đã xem […] để thấy nếu bạn có thể đưa ra được [một tài nguyên tính toán cục bộ] như một phần của một tài nguyên NGS, và đã quá khó khăn cho tôi để có được điều đó được đặt vào và đi qua cách đó tới việc đề xuất các công việc lên cho nó, vì cái cách mà tôi đã hiểu là chúng tôi đặt tất cả các máy của chúng tôi lên nó và sau đó NGS có thể là một máy tính lớn hơn, nên tôi đã cố thử đẻ xem liệu các tài nguyên mà chúng tôi đã có thì chúng tôi có thể gắn vào đó được hay không, và thực sự đã có nhiều rào cản khác nhau về chính sách để làm điều đó […] [Các phần của Đại học] đặt các tài nguyên về cơ bản và gắn các rào cản hướng tới sử dụng mở của họ, và tôi đoán là có thể đúng với bất kỳ đại học nào, tôi không biết'.

Kinh nghiệm của các đơn vị nghiên cứu mà chia sẻ các tài nguyên hạ tầng, nếu được ghi phù hợp thành tài liệu và được phổ biến có thể sẽ cực kỳ có ích cho các cơ sở khác cân nhắc những sắp xếp tương tự. Các đội nghiên cứu mà chia sẻ mở các vấn đề gặp phải và các giải pháp được thấy trong các giai đoạn đầu sử dụng các công cụ hạ tầng có thể làm gia tăng đáng kể hình ảnh của họ đối với các đội bí mật hơn khác. Bản thân các nhà cung cấp dịch vụ quốc gia – NGS trong trường hợp này - cũng sẽ thấy các phản hồi của họ cực kỳ là hữu dụng, khi mà điều này có thể giúp họ cung cấp một dịch vụ được tốt hơn.

Thay vì gạt bỏ tất cả các dạng cộng tác vì sợ rằng các dữ liệu nghiên cứu chủ chốt của họ có thể bị các đội cạnh tranh sử dụng, các nhà nghiên cứu nên xem xét việc chia sẻ hạ tầng như các cách thức làm cho bản thân họ hiểu là hữu dụng và quan tâm tới các thành viên cộng đồng của họ. Điều này cuối cùng có thể trả hết với các cơ hội bổ sung thêm cho quan hệ đối tác nghiên cứu.

Kết luận

Một số bài học về tính bền vững của phát triển mở có thể giúp loại bỏ các rào cản cho sự tham gia với các công cụ và dịch vụ của hạ tầng nghiên cứu. Chúng bao gồm việc xây dựng các kế hoạch về tính bền vững và quản lý của dự án, tránh dựa hoàn toàn vào sự hỗ trợ phát triển được trung ương cung cấp, và các nhà nghiên cứu và các nhà cung cấp dịch vụ có khả năng thúc đẩy ý thức cộng đồng sâu sắc hơn xuyên khắp hạ tầng nghiên cứu của nước Anh và cuối cùng cải thiện được tính hiệu quả của nó.

Một số vấn đề đó cũng được nhấn mạnh trong một nghiên cứu được ủy quyền cho OSS Watch mà đã nghiên cứu mức độ nhận thức, thái độ và sự hiểu biết về phát triển mở trong các cộng đồng Đổi mới của JISC (bản dịch tiếng Việt).

Despite the availability of an impressive range of online systems and resources for UK researchers, a recent JISC-funded Community Engagement Report has identified a number of barriers to their adoption. These include limited opportunities for collaboration between competing partners during the bid process, lack of recognition for the open sharing of research outputs, and inadequate long-term provision of software development support. Let’s take a closer look at some of these barriers, and explore how experience from open development practice could be used to alleviate or remove them.

Introduction

The technical infrastructure built to support UK researchers (also known as e-Infrastructure) consists of a combination of systems and services designed to improve cross-subject collaboration and foster new ways of conducting research (also referred to as e-Research). However, to date, UK researchers have shown some reserve in using these services and facilities in a meaningful way. The main barriers to a wider adoption are social and organisational rather than technological. We suggest that learning and applying some of the key lessons from open development practice could improve the current situation.

We approach this topic in three related documents: a general discussion and two more detailed insights, Community Lessons for Research Infrastructure and Sustainability Lessons for Research Infrastructure (this document), which both include quotes from UK researchers and IT service providers interviewed for the Community Engagement Report. In this document, we highlight a number of sustainability lessons from open development practice that could help to remove barriers to engagement with UK e-Infrastructure systems and services.

Understand software sustainability in broader terms

The sustainability of academic projects (and of their outputs, including software) is understood mainly in terms of securing further funding. However, in open development communities sustainability is understood in broader terms. Expanding beyond the initial team and harnessing contributions from all potentially interested parties are key features of the open development practice. Resources required for ongoing development and support of research outputs can be supported in a variety of ways . By being equally open to contributions from other parties, academic projects can maximise their chances of becoming sustainable in the long term.

Acknowledge the prototype status of academic project software

The sustainability of research infrastructure tools and services is often mentioned as a potential source of concern for researchers. One aspect of this concern is the reliability of the technical solutions offered by academic projects with time-limited funding. This is critical to the researchers’ decision to adopt them:

‘So you’re working with products that come out of research rather than out of a software factory, and often these will have problems or they’ll be half finished or they don’t really fit together yet […] it’s difficult to decipher what the risk is before you start.’

To address this concern, it should be made clear by the projects that most of this software is not yet ready for general use, and requires significant time and skill from users to actually deploy:

‘Most academic software seems to have the lifespan of about a year before it disappears, or doesn’t get updated, or something, and we just can’t work like that.’

The initial development costs associated with building research infrastructure tools are usually covered by time-limited research grants. Therefore, their completeness and usability are limited. Additionally, their adoption by early users often generates further requirements, and the need to provide ongoing maintenance. The project simply cannot offer this:

‘It’s difficult because a research group […] has a number of post docs and PhD students and it’s not a software engineering company. So when you finally deliver something it’s going to be a prototype, it’s never going to be a finished product. But they then start depending on it, and then the problem arises, because you don’t have the funding or even the capacity to maintain [it …] whenever they want to change something, and they don’t have the money to do the same thing, because they can’t just say, oh here’s an extra amount of money just to add this feature that doesn’t exist, so it’s going to be very limited.’

Early and frequent releases are crucial for building a sustainable open source project: releases attract users, some of these users become contributors, and more contributors make the project stronger. The downside of releasing early and often is that one needs to manage user expectations. Projects need to be clear about the status of their releases and draw attention to any known bugs in the documentation.

Avoid relying fully on central development support

Teams tasked with building and maintaining research infrastructure tools traditionally work in closed environment projects. The technology or software developed is kept safely within the confines of the team, and no collaboration is envisaged or sought from outside. One may argue that there is nothing special about this, since many of the tools and resources researchers use are produced in this way. However, e-Research places a significant emphasis on sharing and collaboration. One would therefore expect it to be possible for these teams to have in place some mechanisms by which external contribution could be harnessed to the benefit of the entire community. Software produced in this way could be released under an open source licence and appropriate governance documents could be written to encourage third party contributors to further develop the product by adding features important to their needs.

Take, for instance, a typical situation described in the Community Engagement report concerning the use of GridSAM. GridSAM is a job submission interface for distributed resource management systems, which was initially developed at the London e-Science Centre and further expanded by developers at the Open Middleware Infrastructure Institute (OMII-UK):

‘Unfortunately we found that GridSAM has some problems, and unfortunately GridSAM is no longer actively developed […]. Depending on what happens over the next 3 or 4 months we’ll probably either start coming up with […] solutions that work better for our purposes or try and fix GridSAM ourselves, I would guess. I mean [OMII has] been trying very hard, but obviously it’s very difficult because the developers are employed on something completely different, so it’s quite hard to get the support for a lot of the OMII software, although they are trying hard to improve that. Unfortunately most of the software that’s in the OMII stack isn’t actually finished, that’s the main sort of problem.’

The OMII software development model this researcher refers to is one in which early-stage software from selected research projects is ‘hardened’ and supported up to the point that research outputs are delivered. The code is released under an open source licence, so that anybody can provide contributions. In practice, however, without community mechanisms to encourage and reward external contribution, this is rarely the case.

One more ‘radical’ model that can be found in open source environments outside the academic sector is the Apache Incubator. Here projects are not considered sustainable official projects of the Apache Software Foundation until there are at least three active committers from different employers.

The fact that OMII provides a certain level of development and support for a limited period of time seems good enough for some researchers. However, as other respondents point out, it may be that these issues need to be addressed in a more fundamental way:

‘The way in which funding is provided for projects developing software may need to be more radically changed, so that they start producing self-sustainable products rather than just prototypes.’

Build and publish project sustainability and management plans

One issue that OSS Watch often hears about when consulting with research projects is that of continuation funding. Securing follow-up funding at the end of the project is perceived as a recognition of its success. Failing to do so is seen as an expression of the project’s inability to persuade funders that what they have done is valuable.

However, this is clearly not the only way in which open development teams operate. Support beyond initial funding may come in various other forms. These include user or developer time spent on the project, sponsorship from interested corporate members, or paid support for the maintenance of the product being developed. All of these ways in which the project sees itself being maintained and supported are put together in a sustainability plan. If this plan is made available online, the vision for the project becomes clearer. Its transparency and accountability also increase, and potential new members can better plan their engagement with the community.

Expanding beyond the initial team and harnessing contributions from interested participants are key features of the open development practice. If the tools and processes used by project members on a daily basis are made transparent and appealing, and the adoption path into the community is clear, welcoming and informative, new contributors will join in. They will be attracted by the prospect of being part of a potentially successful self-sustainable project. Some of these contributors may be paid by various employers to work on particular aspects of the product. Others may be attracted by the technical challenge, the prospect of acquiring kudos, or simply by the opportunity to improve or showcase their skills. All these and other accepted forms of engaging with external collaborators can be considered and specified in the project’s governance document.

Foster research collaboration from an early stage

Working in an open fashion is something that not only developers but also researchers themselves can be encouraged to learn. An important condition for success in open development projects is having something that can be run and tested as early as possible. This can mean sharing a product that is imperfect or incomplete. Learning how to work together from an early stage on imperfect products may also help researchers to become more effective members of the emergent research infrastructure communities.

Understand incentives for research collaboration

Collaboration readiness is a useful indicator of the level of trust between project participants, their motivation to work together and share a sense of collective efficacy, beyond merely pushing together to fulfill the mandate of the funders. All these are crucial for the success of online scientific collaboration. It is therefore important to understand the researchers’ incentives for collaboration. These include the pooling of skills, effort and resources likely to improve the quality of the research process. It is equally important to understand the barriers to collaboration, most of which are directly or indirectly related to funding.

‘To a certain degree research centres are in competition. So there is a certain reluctance I think in individual research centres within the same discipline sharing what they’re doing. They may well be bidding for a research project in competition with each other.’

Research is indeed competitive, and the pressure exercised by the ‘publish or perish’ demands of the Research Assessment Exercise (RAE) further affects researchers’ willingness to work collaboratively:

‘[RAE] encourages individuals to publish independently, to keep things secret while there can be many advantages to their career, no matter if they have been funded publicly or not, because by doing that they appear to be better by the criteria used for measurement of the research assessment exercise. That’s a major cultural problem, because it makes it too difficult to persuade scientists to be open with their data, they fear losing it, and therefore their current position.’

One way to counter artificial funding-based competition leading to secrecy and closed-doors authorship is to share from the early stage of a project. At this point, a researcher’s sense of ownership is still relatively low. Inviting competitors to collaborate in the open would pave the way to turning mutually exclusive competition into mutually enriching collaboration. Rival individuals and research centres could therefore be encouraged to set up strategic alliances between groups who agree to write grant proposals, share project work and publish research outputs together.

Significant work in this respect has been carried out by NESTA through its Crucible programme, in which selected early career academics were encouraged to innovate by collaborating across research disciplines. As the keynote speaker at the 2009 edition of the Crucible programme put it in an earlier post:

‘What we need more than ever now, is a diverse and vibrant research community working on a wide range of problems, and to find better communication tools so as to efficiently connect unexpected solutions to problems in different areas.’

Another lesson that can be learned from open development practice is that of enhancing the usability of project outputs. Succesful open source communities know that attracting external contribution depends on the ease by which software code, documentation, project memory and other outputs can be accessed and improved by others. Optimising this process of using and re-using outputs is key to the growth and sustainability of open development projects. In a similar way, researchers could benefit by publishing their research in an appropriate online format and optimising it for increased discoverability and re-use. This way, the apparently missed opportunity of not publishing in an established printed journal could be balanced by the enhanced discoverability and higher potential for external contribution to the shared outputs.

Consider sharing research infrastructure

Open source environments appreciate professional diversity for its potential to generate innovative solutions to problems. Research teams can also learn from this practice. Sharing certain types of research data is not always possible, but research collaboration need not necessarily be understood only in terms of sharing data. In fact clarifying the distinction between sharing research data and sharing research infrastructure is a good way of assessing the levels on which various research communities are prepared to collaborate. By encountering common problems in the early stages of using shared resources, disparate research teams have the opportunity to talk to each other. This can pave the way to previously inconceivable forms of research collaboration.

Many university departments are faced with the prospect of pooling together resources in order to reduce overlapping costs:

‘I think we may look to share facilities between departments here as a way of increasing power and keeping things locally managed. That would be my guess for the next five years at least.’

For instance, some departments find it useful to have all their high-power computing needs arranged locally in order to avoid overheads associated with using the National Grid Service (NGS). However, barriers to sharing computing power are likely to appear at both technical and administrative levels. In this case, policies and support for resource-sharing need to be provided, otherwise the initiatives of individual researchers are unlikely to succeed:

‘I looked […] to see if you could offer [a local compute resource] as part of an NGS resource, and it was too difficult for me to get that put on and go via that way to submitting jobs on to it, because the way I understood it is that we all put our machines on it and then the NGS would be a much bigger computer, so I looked to try to see whether the resources that we had we could stick on it, and actually there were various political barriers to doing that […] [Parts of the University] harbor resources basically and stick up barriers towards their open use, and I guess that’s probably true about any university, I don’t know.’

The experience of research units that share infrastructure resources, if properly documented and disseminated, can be extremely beneficial to other institutions considering similar arrangements. Research teams who openly share the problems encountered and solutions found in the early stages of using infrastucture tools can substantially increase their image against other more secretive teams. The national service providers themselves - the NGS in this case - will also find their feedback extremely useful, as this could help them to provide a better service.

Instead of dismissing all forms of collaboration for fear that their key research data may be used by rival teams, researchers should see the sharing of infrastructure as ways of making themselves known as helpful and caring members of their community. This could eventually pay off with extra opportunities for research partnership.

Conclusion

A number of open development sustainability lessons can help to remove barriers to engaging with research infrastructure tools and services. These include building project sustainability and management plans, avoiding fully relying on centrally provided development support, and encouraging community collaboration from an early stage. The adoption of such lessons by researchers and service providers is likely to foster a deeper sense of community across the UK research infrastructure and ultimately enhance its effectiveness.

Some of these issues have also been highlighted in an OSS Watch-commissioned study that investigated the level of awareness, attitudes to and understanding of open development within JISC Innovation communities.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com