Các bài học của cộng đồng cho hạ tầng nghiên cứu

Community lessons for research infrastructure

By Gabriel Hanganu, Published: 17 May 2010, Reviewed: 14 May 2012

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

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

Lời người dịch: Chúng ta đã từng làm quen với các khái niệm hạ tầng điện tử (HTĐT) và hạ tầng nghiên cứu (HTNC) trong các bài: (1) Nguồn mở và hạ tầng nghiên cứu; và (2) Các bài học về tính bền vững đối với hạ tầng nghiên cứu. Bài viết này cho chúng ta thấy các bài học có thể học được từ cộng đồng phát triển mở cho HTNC. “Một số bài học có liên quan tới cộng đồng phát triển mở có thể giúp loại bỏ các rào cản cho sự tham gia của người sử dụng với các công cụ và dịch vụ HTĐT. Các nhà nghiên cứu có khả năng hơn để sử dụng các cơ sở đó nếu họ cảm thấy rằng họ là một phần của một văn hóa cộng tác và hỗ trợ lẫn nhau, nơi mà sự đóng góp được khuyến khích và được tưởng thưởng từ một giai đoạn sớm. Chúng cũng có khả năng hơn để tham gia với các giải pháp công nghệ được tùy biến thích nghi để phù hợp với các nhu cầu thực tế của cộng đồng”.

Bất chấp tính 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, một Báo cáo Cam kết tham gia Cộng đồng do JISC cấp vốn đã nhận diện được một số rào cản cho sự áp dụng của chúng. Chúng bao gồm sự cạnh tranh cho việc cấp vốn nghiên cứu, một sự bất lực để chia sẻ các tài nguyên, và sự thiếu hỗ trợ phát triển các phần mềm được mở rộng. Hãy xem xét sát hơn vào một số rào cản đó, và khai thác cách mà kinh nghiệm từ phát triển mở có thể được sử dụng để làm dịu bớt hoặc loại bỏ chúng.

Các bài học quan trọng nhất cho các dự án hạ tầng điện tử:

Taooj một cảm giá thuộc về và một văn hóa hỗ trợ lẫn nhau

Điều này có thể được thực hiện bằng việc tạo thuận lợi cho giao tiếp và việc nhận thức sự khác biệt (bản dịch tiếng Việt).

Các rào cản của người sử dụng ở xa

Hãy chắc chắn bạn phổ biến sự thành công, khuyến khích sự đóng góp và tạo các cách thức dễ dàng (bản dịch tiếng Việt) cho những người đóng góp mới tiềm tàng.

Tùy biến thích nghi các công cụ cho các nhu cầu của cộng đồng

Lôi kéo những người sử dụng của bạn tham gia và luôn đặt mọi người cao hơn công nghệ (bản dịch tiếng Việt).

Giới thiệu

Tại Anh, hạ tầng điện tử (HTĐT) bao gồm sự kết hợp của các hệ thống, công cụ và dịch vụ được thiết kế để thúc đẩy các cách thức mới tiến hành nghiên cứu và cải thiện sự cộng tác liên chủ đề. Bất chấp sự phát triển của một danh sách khá lớn các dịch vụ và cơ sở như vậy, các nhà nghiên cứu tại Anh vẫn tiếp tục chỉ ra một số hạn chế trong việc sử dụng chúng một cách rộng rãi. Những rào cản chính cho sự sử dụng các tài nguyên đó dường như có tính 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 một số bài học từ thực tiễn phát triển nguồn mở có thể cải thiện hiện trạng.

Chúng tôi tieps cận chủ đề này theo 3 tài liệu: một thảo luận chung (bản dịch tiếng Việt) và 2 đi sâu vào chi tiết hơn đưa ra những trích dẫn từ các cuộc phỏng vấn gần đây với các nhà nghiên cứu và các nhà cung cấp dịch vụ của Anh - một trong các bài học cộng đồng cho hạ tầng nghiên cứu (HTNC) và tài liệu khác về các bài học về tính bền vững cho hạ tầng nghiên cứu (bản dịch tiếng Việt). Theo điều này, tài liệu đầu trong 2 tài liệu, chúng tôi nhấn mạnh một số bài học cộng đồng mà có thể giúp loại bỏ các rào cản để cam kết tham gia với các hệ thống và dịch vụ HTĐT của Anh.

Tạo một cảm giác thuộc về và văn hóa hỗ trợ lẫn nhau

Trong nguồn mở, cũng như trong ngữ cảnh đổi mới mở rộng lớn hơn, việc khuyến khích những người sử dụng và các lập trình viên tham gia với dự án là sống còn cho việc xây dựng một cộng đống thịnh vượng. Việc xây dựng một sản phẩm bền vững phần lớn phụ thuộc vào việc tôi rèn một môi trường trong đó những người sử dụng và những người phát triển chia sẻ một văn hóa hỗ trợ lẫn nhau và một cảm giác tuân theo cùng một mục tiêu chung. Các hiệu ứng của việc gieo hạt các ý tưởng tương tự trong các cộng đồng nghiên cứu có thể là đáng kể.

Tạo thuận lợi cho giao tiếp

Một số nhà nghiên cứu và nhà cung cấp dịch vụ nói các khó khăn trong việc tạo một kênh có hiệu quả về giao tiếp giữa các bên tham gia đóng góp HTNC. Một mặt, các lập trình viên phát triển phần mềm và các nhà cung cấp dịch vụ thấy khó để nắm bắt được các câu hỏi nghiên cứu hàn lâm hoặc các yêu cầu xuất bản. Mặt khác, các nhà nghiên cứu có thể không đánh giá đầy đủ những thách thức về công nghệ mà việc triển khai các ứng dụng thể hiện, hoặc các hệ thống phân tán là gì và làm thế nào chúng có thể hỗ trợ cho các hoạt động nghiên cứu. Thiếu sự hiểu biết lẫn nhau, khó có khả năng là các bên sẽ biết những gì được mong đợi từ mỗi bên đối với nhau.

Như một nhà cung cấp dịch vụ CNTT đưa ra: 'Nếu bạn mua một chiếc ô tô, bạn biết đấy, hầu hết mọi người biết bạn có gì và bạn nên tìm kiếm gì. Nhưng nếu bạn đến với chúng tôi, “Chúng tôi có thể giúp gì cho bạn” luôn là mù mờ, vì chúng tôi có thể làm rất nhiều, chúng tôi có nhiều kinh nghiệm, nhưng bạn biết đấy, nếu nó từng được viết xuống trong một cuốn sách mỏng thì nó có thể là một dạng dài hơi, và thường thì họ không hiểu tất cả những tiếng lóng mà chúng tôi có và tất cả những điều đó '.

Một cách giải quyết vấn đề này là bằng việc khuyến khích đối thoại liên ngành: 'Có một nhu cầu cho nhiều người hơn ngồi xuống với các nhà khoa học và làm việc với họ về những ứng dụng đặc thù của họ […] cho những người hiểu cả 2, những người mà có thể hiểu được các ứng dụng và cũng hiểu được cách để xúc tác mạng lưới cho họ'.

Việc loại bỏ các rào cản có liên quan tới sử dụng tiếng lóng khoa học hoặc kỹ thuật có thể giúp xây dựng một cảm giác chia sẻ mục tiêu bao quát chung. Những người trả lời đã nhấn mạnh nhu cầu để khuyến khích sử dụng ngôn ngữ tiếng lóng tự do mà được hiểu như nhau đối với các nhà nghiên cứu, các lập trình viên phần mềm, các nhà cung cấp dịch vụ và những người sử dụng tiềm năng khác. 'Một trong những điều là dạng gây chán nản thường xuyên trong lĩnh vực đó là thuật ngữ được giả định, nếu bạn biết tôi ngụ ý gì, thì có nhiều thuật ngữ mà tới từ khoa học máy tính, chúng không bao giờ được thiết kế cho phần còn lại của chúng ta, những người thực sự làm khoa học […]'

Sự khác biệt về tri thức

Một khía cạnh khác của giao tiếp sai hiện hành trong những người tham gia đóng góp có liên quan tới khỏng cách thế hệ giữa những người được xã hội hóa khác nhau về công nghệ. Các khả năng công nghệ tiến hóa nhanh hơn so với các cơ quan có khả năng thích nghi. Điều này ngụ ý rằng tỷ lệ thay đổi công nghệ được các nhà nghiên cứu trải nghiệm trong các cơ quan đó có ảnh hưởng tới họ khác nhau, tùy theo các khả năng công nghệ của họ. Hệ quả là, các nhà quản lý CNTT của các trường đại học thường thấy khó để thiết lập một nền tảng chung, mặt bằng chung trong các viện trường của họ:

'Cái gì có trên con đường chiến lược của chúng ta, cũng có thứ văn hóa mà các ban của trường đại học có xu hướng được các viện sỹ hàn lâm lâu năm hơn quản lý, những người tất cả đều hồi cố về những ngày trước khi các máy tính chiếm lĩnh thế giới, và vì thế nói với các sinh viên nghiên cứu của họ và những người chuẩn bị làm tiến sỹ của họ thực tế đang nói một thứ ngôn ngữ khác so với việc nói cho các giáo sư'.

Đưa ra mức nhạy cảm của chỉ dẫn về sử dụng các dịch vụ của HTNC có thể giúp thúc đẩy một cảm giá thuoocj về một cộng đồng đang chào đón. Hơn nữa, như một nhà cung cấp dịch vụ điện toán có sức mạnh cao đã nói, sự khéo xử và sự nhẫn nại là cần thết để không làm trệch hướng những người áp dụng sớm:

'Chúng tôi biết rằng một số người sử dụng [hệ thống X] tồi tệ, nhưng khi chúng tôi thấy chúng tôi nói cho họ và nói, nhìn kìa, bạn cần hiểu một chút nhiều hơn cách mà điều này làm việc […] nếu bạn tái cấu trúc công việc của bạn như thế này thì bạn sẽ có được lợi ích lớn hơn nhiều […] Đây là một sức ép giữa việc nếu bạn muốn đảm bảo rằng những người sử dụng của bạn đã sử dụng nó tuyệt vời thì bạn có thể muốn nắm giữ chúng suốt, và họ có thể thấy điều đó là hạn chế không thể dung thứ và sẽ không sử dụng nó, vì thế điều đó có thể là sự ngu ngốc'.

Người trung gian và người môi giới

Đôi khi một bước chủ động tích cực hơn là cần thiết cho việc xây dựng cộng đồng. Việc có khả năng là trung gian giữa các thành viện khác nhau của cộng đồng là quan trọng trong ngữ cảnh này. Một nhà báo đã mô tả tình huống nơi mà một đội nghiên cứu có thể cần sự truy cập đặc biệt tới các cơ sở được Dịch vụ Lưới Quốc gia – NGS (National Grid Service) cung cấp. Để có được sự truy cập, họ có thể cần được khuyến cáo từ các nhà nghiên cứu bạn bè đã biết dịch vụ đó rồi:

'Bạn biết đấy, có thể khó để thuyết phục NGS trao cho bạn 700 GB […] để thực sự có dữ liệu ở đó. Nên tôi nghĩ bạn phải biết đúng người và dạng yêu cầu họ rất nhẹ nhàng, bạn biết đấy, gửi một thư điện tử như ai đó biết về những điều đó cho người của NGS, và nói vâng thực sự điều này là […] một yêu cầu nghiêm túc, và họ cần lượng dữ liệu này, và thực sự đó thực sự chỉ là […] tạm thời cho họ nên họ có thể thực sự có được dữ liệu ở đó'.

Những người trung gian đó có một vai trò quan trọng trong việc tạo một cảm giác là một phần của một cộng đồng có tính hỗ trợ lẫn nhau. Như các tác giả báo cáo gợi ý, vai trò của họ trong trường hợp này sẽ liên quan tới việc quản lý những kỳ vọng của các nhà nghiên cứu (bằng việc nhắc nhở họ rằng NGS không cung cấp lưu trữ dữ liệu lâu dài). Cùng lúc, họ có thể cần tư vấn cho nhà cung cấp dịch vụ rằng tài nguyên được yêu cầu là một phần của yêu cầu nghiên cứu đích thực.

Khuyến khích sự đóng góp, loại bỏ những rào cản của người sử dụng

Để tạo một môi trường chào đón và 'muốn quay trở lại' thì điều cơ bản phải khuyến khích sự đóng góp từ cả bên trong và bên ngoài dự án và loại bỏ các rào cản có thể ngăn trở sự tham gia của những người sử dụng trong cộng đồng. Các dự án nguồn mở thành công làm rõ rằng tất cả được chào đón để đóng góp theo cách riêng của họ, từ việc viết mã và làm tài liệu cho tới việc kiểm thử và đưa ra các ý kiến phản hồi trong các phiên bản mới. Một thái độ chào đón tương tự đối với sự đóng góp bên ngoài có khả năng cũng có lợi cho các cộng đồng HTĐT.

Phổ biến sự thành công

Báo cáo nhắc tới tầm quan trọng của việc nhấn mạnh các tình huống nơi mà sử dụng HTĐT đã cải thiện đáng kể qui trình nghiên cứu. Các câu chuyện thành công đó có thể tạo cảm hứng hoặc thúc đẩy các nhà nghiên cứu khác và cần phải được phổ biến rộng rãi:

'Đã và đang thú vị […] khi mọi người bắt đầu đi ra ngoài và chỉ nói những gì có khả năng làm được, chỉ là sự phấn khích nhiều bao nhiêu bạn có thể tạo ra, nên tôi nghĩ có những điều nơi mà bạn có thể chỉ ra rằng mọi người đã làm thực sự cho khoa học mới bằng việc sử dụng các công cụ và sử dụng sự ghen ghét đố kỵ [...] dường như sẽ là làm việc hoàn toàn tốt trong các khoản có được sự tham gia, và vì thế thực tế là, chúng ta đang nói rằng các cộng đồng khác chỉ giống như những điều, giống như các hệ thống mà các cộng đồng sinh học đang bắt đầu rất quan tâm và tham gia vào'.

Những khuyến khích phù hợp có thể đóng một vai trò quan trọng trong việc tối đa hóa hiệu ứng của việc phổ biến các câu chuyện thành công đó. Một số khuyến khích đó, báo cáo gợi ý, cần tính tới sự Nghiên cứu Đánh giá Bài toán - RAE (Research Assessment Exercise), khi điều này là yếu tố động lực quan trọng cho các nhà nghiên cứu và các phòng ban. Gợi ý này chứng thực một khuyến cáo sớm của báo cáo Thế kỷ của Chiến lược Nghiên cứu Thông tin (Century of Information Research Strategy report): 'Các cơ quan cấp vốn tạo ra giải thưởng trao và đánh giá các kết quả đầu ra của họ, bao gồm một yếu tố của sự đóng góp cho giáo dục trong lĩnh vực nghiên cứu'.

Khuyến khích sự đóng góp

Bài học quan trọng khác từ phát triển nguồn mở là sự đóng góp từ những người sử dụng bên ngoài và các lập trình viên nên được khuyến khích và tưởng thưởng. Hầu hết những người sử dụng dự án nguồn mở mở là thụ động trong các tương tác của họ với cộng đồng. Tuy nhiên, khi họ nhận lấy các vai trò tích cực hơn, ví dụ bằng việc báo cáo các lỗi, giúp những người sử dụng khác hoặc viết tài liệu, thì các cộng đồng nguồn mở có khả năng bền vững và quản lý tốt có được các cơ chế cho việc khuyến khích và tưởng thưởng cho những nỗ lực của họ. Trong nhiều trường hợp, họ được chào truy cập bổ sung tới, hoặc kiểm soát đối với, dự án. Việc giải thích tài liệu rõ ràng cách người ta có thể chuyển từ người sử dụng thụ động sang người đóng góp, sau đó sang người đóng góp cao cấp với các quyền của người đề xuất, và cuối cùng sang là thành viên ban lãnh đọ ra quyết định, sẽ diễn ra. Điều này có nghĩa là mỗi người biết những gì phải làm nếu họ muốn gia tăng vai trò và trách nhiệm của họ trong dự án.

Các môi trường HTĐT, bước đầu tiên từ người sử dụng tới người đóng góp thường có liên quan tới việc đưa ra các ý kiến phản hồi trong chức năng của sản phẩm đang được phát triển. Họ có thể, ví dụ, báo cáo về một lỗi hoặc thông báo một dịch vụ mà điều gì đó không làm việc như nó đáng phải. Điều mấu chốt ở đây là để chắc chắn rằng khi những người sử dụng quyết định nhận lấy điều phiền toái để đưa ra ý kiến phản hồi như vậy, thì con đường là cởi mở nhất có thể. Việc thừa nhận những đóng góp ngay lập tức và việc giải quyết các vấn đề theo một cách thức đúng lúc là quan trọng ngang bằng cho sự tham gia của những người sử dụng đó trong tương lai.

'Trong trường hợp các khảo sát riêng rẽ, đôi khi có trường hợp rằng tôi đã tải về một tệp và sau đó phát hiện ra có lẽ có một lỗi bên trong tệp dữ liệu, hoặc thiếu quyền ưu tiên hoặc một biến đặc biệt, hoặc một biến thiếu trong tệp dữ liệu mà nó được tham chiếu tới trong tài liệu, và ngẫu nhiên tôi đã báo cáo rằng dạng ví dụ đó tới bàn trợ giúp, và chúng thường là, trong thực tế khá nhiều khi, họ đã có khả năng quay trở lại và đưa ra giải pháp hoàn toàn nhanh chóng, nên tôi chúng là một dịch vụ rất hữu ích theo cách đó'.

Tạo ra cách cách thức vào dễ dàng

Rào cản khác đối với sự tham gia của người sử dụng có liên quan tới sự thiếu hoặc tài liệu có cấu trúc tồi. Một nhà nghiên cứu đã nhắc về những ý định lặp đi lặp lại của ông để học cách sử dụng một công cụ của HTNC: 'Về cơ bản thì thông qua việc tìm kiếm các bản tin và tìm kiếm các bài trình chiếu từng nằm rải rác đâu đó trên các website khác nhau'.

Những người trả lời khác cũng đã nhắc tới nhu cầu đối với các khả năng huấn luyện có thể cung cấp cho họ với các kỹ năng cần thiết cho việc sử dụng dịch vụ: 'Tôi có thể thấy rằng có những điều mà chúng ta có thể có khả năng sử dụng trong tương lai, nhưng trước hết chúng ta sẽ phải làm việc như thế nào, nếu bạn biết tôi ngụ ý gì? Có những dự án, ví dụ như OGSA-DAI, và OGSA-DAI có một số tính năng mà tôi cáo thể thấy chúng có thể hữu dụng nếu chúng ta đã có được các kỹ năng, hoặc nếu chúng ta có được thời gian để thực sự có khả năng đi đủ xa trong công nghệ để có khả năng thực sự ứng dụng được nó một cách phù hợp'.

Một số nhà cung cấp HTĐT nhận thức được về những vấn đề đó và cố gắng giải quyết chúng, nhưng họ có quan tâm với các chi phí tiềm tàng có liên quan. Một trong số họ đã gợi ý rằng việc cung cấp tài liệu tuyệt vời có thể là một cách để tránh được chi phí triển khai và cập nhật các giải pháp huấn luyện:

'Nếu bạn muốn một lợi ích rộng lớn hơn thì bạn có thể phải làm cho dễ dàng hơn đối với họ để sử dụng, không chỉ tiếp tục huấn luyện cho họ, vì bạn không phải chỉ cân nhắc chi phí huấn luyện, mà còn chi phí đối với họ không tham gia lâu dài với đồ của riêng họ vì họ đang được huấn luyện để sử dụng điều này, và tất nhiên HTĐT sẽ thay đổi một lần nữa và sau đó họ phải được huấn luyện lại. Vì thế những gì bạn muốn làm là làm cho nó thật dễ dàng cho họ để sử dụng mà bạn không cần thiết phải huấn luyện'.

Tùy biến thích nghi các công cụ cho các nhu cầu của cộng đồng

Bài học khác là những người tham gia đóng góp của HTĐT có thể học được từ các cộng đồng nguồn mở là tầm quan trọng của việc thiết kế hoặc yêu cầu các hệ thống và dịch vụ phù hợp với các nhu cầu cộng đồng của họ. Điều đó sẽ giúp cho những người sử dụng hỏi các câu hỏi nghiên cứu của họ và triển khai nghiên cứu theo một cách thức hiệu quả và nhất quán. Cùng lúc, chúng nên là dễ dàng để tùy biến thích nghi cho các nhu cầu đặc thù của các đội nghiên cứu khác nhau.

Lôi cuốn người sử dụng

Một trong những khía cạnh được báo có phát hiện là sự chú ý nhiều hơn đã có đối với việc phát triển công nghệ HTĐT so với việc hiểu các khía cạnh xã hội có liên quan với sự sử dụng của nó. Tác động là toàn bộ qui trình xây dựng các hệ thống và dịch vụ đó có thể cần phải được xem xét lại. Thay vì việc xây dựng các công cụ được nghĩ là sẽ hữu dụng cho các cộng đồng nghiên cứu, và việc vật lộn sau khi làm cho các nhà nghiên cứu sử dụng chúng, một tiếp cận dễ nhận thấy hơn có thể có liên quan tới các nhà nghiên cứu ngày trong qui trình thiết kế và xây dựng chúng. Điều này có thể đảm bảo rằng những gì đang được xây dựng hoàn toàn phù hợp với các nhu cầu của họ.

Một vấn đề với tiếp cận hiện hành được vài nhà nghiên cứu nghệ thuật và loài người chú ý có liên quan tới bản thân hệ biến hóa khoa học điện tử - KHĐT (e-Science), nó có thể là không phù hợp cho việc hỗ trợ các dạng câu hỏi thường được hỏi theo các nguyên tắc của chúng: 'Đang có khả năng để làm phù hợp một hệ biến hóa KHĐT vào trong Nghệ thuật và Loài người là vấn đề thay vì việc liệu chúng ta có thể sủ dụng được công nghệ hay không'. Nói cách khác, các công cụ HTĐT có thể không phải là nguyên tắc có tính tự nhiên, và sử dụng của chúng trong một số dự án nghiên cứu có thể sửa đổi các thực tiễn nghiên cứu được thiết lập và gây tác động tiêu cực cho các kết quả nghiên cứu. Hệ quả là, sự áp dụng của chúng của các nhà nghiên cứu tương ứng có thể bị tổn thương.

'Có những rào cản cơ bản cho việc sử dụng các công nghệ đối với Nghệ thuật và Loài người, nhưng đó là để làm với nguyên tắc […] hơn là [với] việc không hiểu công nghệ, không có khả năng có được công nghệ. Đây là vấn đề của những gì chúng ta có thể làm với các công nghệ mà chúng là hữu dụng, là các câu hỏi về phương pháp luận, và cũng […] về những gì Nghệ thuật và Loài người, dạng nghiên cứu nào chúng ta đang làm?'

Con người hơn là công nghệ

Việc hiểu các mục tiêu của cộng đồng và việc chọn công nghệ phù hợp là sống còn cho sự thành công của các dự án nguồn mở. Trong một số môi trường nguồn mở, vấn đề này đi vượt ra khỏi sự quản lý các công cụ dự án và ảnh hưởng tới các qui trình đóng góp mã phần mềm. 'Chăm sóc được cộng đồng và mã nguonf sẽ chăm sóc được bản thân mình' là cách mà các thành viên của Quỹ Phần mềm Apache đưa ra để ghi nhớ. Việc có các qui trình phù hợp sẵn sàng cho việc xây dựng cộng đồng tạo ra một cách thức bền vững của việc phát triển bản thân phần mềm đó.

Trong nhiều trường hợp, việc áp dụng các công nghệ phù hợp các nhu cầu của cộng đồng có liên quan tới việc sử dụng các công cụ của dự án. như các hệ thống hỗ trợ phiên bản, các trình theo dõi lỗi, các danh sách thư, và nhiều công cụ khác. Các cộng đồng nghiên cứu có khả năng hưởng lợi bằng việc tuân theo các thực tiễn phát triển mở giống như thế. Quả thực, hầu hết các vấn đề được đặt ra từ những người trả lời cho báo cáo có liên quan tới những khía cạnh thực tiễn của việc tham gia với công nghệ. Ví dụ một trong số họ đã nhắc tới những khó khăn trong việc tham gia với các cấu hình khác nhau của cài đặt NGS, làm nảy sinh ra nhu cầu biên dịch mã một cách lặp đi lặp lại:

'Nên các vấn đề mà chúng tôi đã đối mặt từ quan điểm của người sử dụng, tôi đoán vấn đề lớn nhất, là việc các máy của các thư viện và các phiên bản của trình biên dịch đã không được đồng bộ với nhau. nên nó không - các thư viện MPI và hơn thế - không luôn có khả năng biên dịch trong một máy, đặc biệt MPI có khả năng thực thi, và sau đó lấy nó sang các máy NGS khác và chạy nó, và điều này là một vấn đề đáng keerr vì nó có nghĩa là […] trong đó bạn sử dụng nhiều máy tính mà bạn phải đăng nhập vào mỗi lần khi tới lượt và biên dịch mã của bạn, nó mất thời gian, và nhiều tài nguyên của lưới hơn bạn có, mất nhiều thời gian hơn'.

Một cơ chế phù hợp cho việc giữ các phiên bản phần mềm khác nhau được đồng bộ và sống còn. Theo khía cạnh này, kinh nghiệm phát triển mở của các đội phân tán làm việc trong các phiên bản tuần tự đến sau của mã phần mềm có thể là hữu dụng. Các giải pháp tương tự có thể được nghĩ ra cho việc hợp lý hóa qui trình đồng bộ hóa các nút NGS, ví dụ thế. Chìa khóa là khả năng phối hợp mọi người và các qui trình ảnh hưởng tới hiệu năng của các nút đó, hơn là sự cần thiết thiết kế lại bản thân công nghệ.

Vấn đề khác được nhắc tới trong mối quan hệ với NGS có liên quan tới mức độ ở đó phần mềm HTNC cho phép những người sử dụng phát triển các ứng dụng hoặc mở rộng trên đỉnh của các phần mềm đang tồn tại.

'[…] những gì tôi muốn làm là xây dựng các ứng dụng sử dụng NGS ở bên dưới, và NGS có dạng giao diện sai tại thời điểm này, vì thế là khó cho tôi để xây dựng các ứng dụng đó […] có lẽ là hữu dụng nếu giao diện đó là một dịch vụ, tại thời điểm này nó là một sự đăng nhập, tôi phải đăng nhập vào hệ thống và gõ các lệnh của riêng tôi'.

Kết luận

Một số bài học có liên quan tới cộng đồng phát triển mở có thể giúp loại bỏ các rào cản cho sự tham gia của người sử dụng với các công cụ và dịch vụ HTĐT. Các nhà nghiên cứu có khả năng hơn để sử dụng các cơ sở đó nếu họ cảm thấy rằng họ là một phần của một văn hóa cộng tác và hỗ trợ lẫn nhau, nơi mà sự đóng góp được khuyến khích và được tưởng thưởng từ một giai đoạn sớm. Chúng cũng có khả năng hơn để tham gia với các giải pháp công nghệ được tùy biến thích nghi để phù hợp với các nhu cầu thực tế của cộng đồng.

Một số vấn đề đó cũng đã và đang được nhấn mạnh trong một nghiên cứu mà OSS Watch được ủy quyền, nghiên cứu mức độ nhận thức, thái độ đối với và sự hiểu biết của phát triển mở với 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 researchers, a JISC-funded Community Engagement Report has identified a number of barriers to their adoption. These include competition for research funding, an inability to share resources, and a lack of extended software development support. Let’s take a closer look at some of these barriers, and explore how experience from open development could be used to alleviate or remove them.

The most important lessons for e-Infrastructure projects:

Create a sense of belonging and a culture of mutual support

This can be done by facilitating communication and acknowledging difference.

Remove user barriers

Make sure you disseminate success, encourage contribution and create easy ways in for new potential contributors.

Adapt tools to community needs

Involve your users and always put people over technology.

Introduction

In the UK, e-Infrastructure consists of a combination of systems, tools and services designed to foster new ways of conducting research and improve cross-subject collaboration. In spite of the development of an extremely well-populated list of such services and facilities, researchers in the UK continue to show some reserve in using them extensively. The main barriers to the use of these resources appear to be social and organisational rather than technological. We suggest that learning some lessons from open source development practice could improve the current situation.

We approach this topic in three documents: a general discussion and two more detailed insights providing quotes from recent interviews with UK researchers and service providers - one on community lessons for research infrastructure and the other on sustainability lessons for research infrastructure. In this, the first of these two documents, we highlight a number of community lessons that could help to remove barriers to engagement with UK e-Infrastructure systems and services.

Create a sense of belonging and a culture of mutual support

In open source, as well as the wider open innovation context, encouraging users and developers to engage with the project is crucial for building a thriving community. Building a sustainable product largely depends on forging an environment in which users and developers share a culture of mutual support and a sense of following a common goal. The effects of seeding similar ideas in research communities could be substantial.

Facilitate communication

A number of researchers and service providers report difficulties in creating an effective channel of communication between research infrastructure stakeholders. On the one hand, software developers and service providers find it difficult to grasp academic research questions or publication requirements. On the other hand, researchers may not fully appreciate the technical challenges that implementing applications present, or what distributed systems are and how they can support research activities. In the absence of mutual understanding, it is unlikely that these parties will know what to expect from each other.

As one IT service provider put it: ‘If you buy a car, you know, most people know what you get and what you should look for. But if you come to us, “What can we do for you” is always vague, because we can do quite a lot, we’ve got a lot of expertise, but you know, if it was written down in a brochure it would be kind of a long-winded one, and often they don’t understand all the jargon that we have and all that sort of thing.’

One way of addressing this issue is by encouraging cross-specialist dialogue: ‘There is a need for more people to sit down with scientists and work with them on their specific applications […] people that understand both, people that can understand the applications and also understand how to grid-enable them.’

Removing the barriers associated with the use of technical or scientific jargon could help to build a sense of sharing a common overarching goal. Respondents emphasised the need to encourage the use of jargon-free language that is understood equally by researchers, software developers, service providers and other potential users. ‘One of the things that’s sort of continually frustrating in the field is the assumed terminology, if you know what I mean, there’s a lot of terminology that’s come over from computing science, which was never designed for the rest of us who actually do the science […]’

Acknowledge difference

Another aspect of the current mis-communication among stakeholders concerns the generational gap between users who are differently socialised in terms of technology. Technical possibilities evolve faster than institutions are able to adapt. This means that the rate of technological change experienced by researchers in these institutions affects them differently, according to their technological capabilities. Consequently, university IT managers often find it difficult to establish a common, level ground within their institutions:

‘What gets in the way of our strategy, there’s also the cultural thing that the committees of the university tend to be run by the more senior academics who all date back to the days before computers took over the world, and so talking to their research students and their junior post-docs is practically speaking a different language compared with speaking to the professors.’

Providing a sensible level of guidance on using research infrastructure services can help to foster a sense of belonging to a welcoming community. In addition, as one high-powered computing service provider said, tact and patience are needed in order not to drive away early adopters:

‘We know that some people use [system X] badly, but when we find out we talk to them and say, look, you need to understand a little bit more how this works […] if you restructure your work like this you’ll get a much bigger benefit […] It’s a tension between if you wanted to guarantee that your users used it perfectly you’d have to hand-hold them all the time, and they would find that unbearably restrictive and wouldn’t use it, so that would be stupid.’

Mediate and broker

Sometimes a more proactive step is needed for building community. Being able to mediate between different community members is important in this respect. One respondent described a situation where a research team may need special access to the facilities provided by the National Grid Service (NGS). In order to gain access, they would need to be recommended by fellow researchers already known to the service:

‘You know, it can be hard to persuade the NGS to give you a 700 gigabyte […] to actually get the data there. So I think you have to know the right people and sort of ask them very nicely to sort of, you know, send an email as someone who knows about these things to the NGS people, and say yes actually this is […] a serious request, and they do need this amount of data, and actually it’s really only […] temporarily for them so they can actually get the data on there.’

These intermediaries have an important role in creating a sense of being part of a mutually supportive community. As the report authors suggest, their role in this case will involve managing the researchers’ expectations (by reminding them that the NGS does not provide long-term storage for data). At the same time, they would need to advise the service provider that the requested resource is part of a genuine research requirement.

Encourage contribution, remove user barriers

In order to create a welcoming and ‘want to come back’ environment it is essential to encourage contribution from both inside and outside the project and remove any barriers that could prevent users’ involvement in the community. Successful open source projects make it clear that all are welcome to contribute in their own way, from writing code and documentation to testing and giving feedback on new releases. A similar welcoming attitude to external contribution is likely to benefit e-Infrastructure communities too.

Disseminate success

The report mentions the importance of highlighting situations where the use of e-Infrastructure has significantly improved the research process. These success stories may inspire or motivate other researchers and need to be widely disseminated:

‘It’s been interesting […] when people start going out and about and just saying what it is possible to do, just how much excitement you can generate, so I think having stuff where you can show that people have done really new science using those tools and using jealousy […] it seems to be working quite well in terms of getting engagement, and so the fact that, you know, we’re saying that other communities just like things, like the systems biology communities are beginning to be very keen to play and join in.’

Appropriate incentives can play an important role in maximising the effect of disseminating these success stories. Some of these incentives, the report suggests, need to take the Research Assessment Exercise (RAE) into account, as this is an important motivational factor for researchers and departments. This suggestion endorses an earlier recommendation by the Century of Information Research Strategy report: ‘The funding bodies should make the award of grants and the evaluation of their outputs include a significant element of contribution to education in the domain of the research.’

Encourage contribution

Another important lesson from open source development is that contribution from external users and developers should be encouraged and rewarded. Most open source project users are passive in terms of their interactions with the community. However, when they take on more active roles, for example by reporting bugs, helping other users or writing documentation, sustainable and well-run open source communities have in place mechanisms for encouraging and rewarding their efforts. In many instances, they are offered additional access to, or control over, the project. Clear documentation explaining how one can move from passive user to contributor, then to senior contributor with commit rights, and eventually to decision-making board member, will be in place. This means that everyone knows what to do if they want to increase their role and responsibility in the project.

In e-Infrastructure environments, the first step from user to contributor often involves providing feedback on the functionality of the product being developed. They may, for example, report a bug or notify a service that something is not working as it should. The key thing here is to make sure that, when users decide to take the trouble to provide such feedback, the path is as straightforward as possible. Acknowledging contributions immediately and addressing issues in a timely manner are equally important for the future engagement of these users.

‘In the case of individual surveys, there is sometimes the case that I have downloaded a file and then found out perhaps an error within the data file, or lack of priority on a particular variable, or a variable missing within the data file that’s referred to in the documentation, and occasionally I have reported that sort of example to the help desk, and they’ve usually been, well in fact pretty much every time, they’ve been able to get back and come up with the solution quite rapidly, so I find them a very helpful service in that respect.’

Create easy ways in

Another barrier to user engagement concerns a lack of or poorly structured documentation. One researcher mentioned his repeated attempts to learn how to use a research infrastructure tool: ‘Essentially it was through searching for handouts and searching for presentations that were scattered about over various websites.’

Other respondents also mentioned the need for training opportunities that would provide them with the necessary skills for using the service: ‘I can see that there are things there which we probably could be able to use in the future, but first we’d have to work out how, if you know what I mean? There are projects, for example like OGSA-DAI, and OGSA-DAI has some features which I can see they would be useful if we had skills, or if we had the time to actually be able to get far enough into the technology to be able to actually utilize it properly.’

Some e-Infrastructure providers are aware of these issues and try to address them, but they are concerned with the potential costs involved. One of them suggested that providing excellent documentation could be a way of avoiding the cost of deploying and updating training solutions:

‘If you want a wider benefit then you would have to make it easier for them to use, not just keep on training them, because you have to not just consider the cost of training, but also the cost of them not being engaged for a long time with their own stuff because they’re being trained to use this, and of course e-infrastructure will change again and then they have to be re-trained. So what you want to do is make it so easy for them to use that you don’t need training.’

Adapt tools to community needs

Another lesson that e-Infrastructure stakeholders can learn from open source communities is the importance of designing or requesting systems and services that fit their community needs. These should help users ask their research questions and carry out research in an efficient and consistent manner. At the same time, they should be easy to adapt to the specific needs of the various research teams.

Involve users

One of the main aspects revealed by the report is that more attention has been paid to developing e-Infrastructure technology than to understanding the social aspects associated with its use. The implication is that the entire process of building these systems and services may need to be reconsidered. Instead of building tools thought to be useful to the research communities, and struggling afterwards to make researchers use them, a more sensible approach would be to involve researchers in the very process of designing and building them. This would ensure that what is being built fully suits their needs.

One problem with the current approach flagged by several arts and humanities researchers concerned the e-Science paradigm itself, which may be inappropriate for supporting the types of questions usually asked in their disciplines: ‘Being able to fit an e-Science paradigm into Arts and Humanities is the problem rather than whether we can use the technology.’ In other words, e-Infrastructure tools may not be discipline-neutral, and their use in some research projects may modify the established research practices and negatively influence the research results. Consequently, their adoption by the respective researchers may be compromised.

‘There are fundamental barriers to using these technologies for the Arts and Humanities, but that’s to do with the discipline […] rather than [with] not understanding the technology, not being able to get the technology. It’s a matter of what can we do with these technologies which are useful, which are methodological questions, and also […] about what is Arts and Humanities, what kind of research are we doing?’

People over technology

Understanding the aims of the community and choosing technology accordingly is crucial for the success of open source projects. In some open source environments, this issue goes beyond the management of project tools and affects the very processes of contributing software code. ‘Look after the community and the code will look after itself’ is how members of The Apache Software Foundation memorably put it. Having appropriate processes in place for building the community creates a sustainable way of developing the software itself.

In many cases, adopting technologies that fit the needs of the community involves using project tools, such as version support systems, bug trackers, mailing lists, and so on. Research communities are likely to benefit by following open development practices like these. Indeed, most issues flagged by the report respondents concerned practical aspects of engaging with technology. For instance, one of them mentioned difficulties in engaging with different configurations of the NGS nodes, which resulted in the need to compile code repeatedly:

‘So the problems we faced from the user’s point of view, I guess the biggest problem, is that the machines in terms of libraries and compiler versions aren’t kept in sync. So it’s not – MPI libraries and so on – it’s not always possible to compile on one machine, especially MPI executable, and then take it to another of the NGS machines and run it, and this is a significant problem because it means that […] where you use multiple machines you have to log into each one in turn and compile your code, which takes time, and the more grid resources you have, the more time that takes.’

A proper mechanism for keeping different software versions in sync is crucial. In this respect, the open development experience of distributed teams working on subsequent versions of software code can be useful. Similar solutions could be devised for streamlining the process of synchronising the NGS nodes, for example. The key is the ability to coordinate people and processes that affect the performance of these nodes, rather than necessarily re-designing the technology itself.

Another issue mentioned in relation to the NGS concerns the degree to which research infrastructure software allows users to develop applications or extensions on top of existing ones.

’[…] what I would like to do is build applications that use the NGS underneath, and the NGS has the wrong kind of interface at the moment, so it’s difficult for me to build those applications […] it’d be useful if the interface was a service, at the moment it’s a log-on, I have to log on to the system and type my own commands.’

Conclusion

A number of open development community-related lessons could help to remove barriers to user engagement with e-Infrastructure tools and services. Researchers are more likely to use these facilities if they feel that they are part of a culture of mutual support and collaboration, where contribution is encouraged and rewarded from an early stage. They are also more likely to engage with technological solutions that are adapted to fit the real needs of the community.

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