Lên kế hoạch cho tính bền vững

Planning for sustainability

By Gabriel Hanganu, Ross Gardler, Published: 21 June 2011, Reviewed: 11 June 2012

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

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

Lời người dịch: Để có được một dự án phần mềm tự do nguồn mở bền vững, bạn cần phải lôi cuốn được bên thứ 3 tham gia và thực hiện một số việc cơ bản khác như: “Một số vấn đề phổ biến nhất bao gồm việc không lôi cuốn được sự quan tâm của các bên thứ 3, quản lý tồi hạ tầng cộng đồng, thiếu tiền cho dự án và quản lý phát hành không hiệu quả. Để ngăn chặn những vấn đề như vậy trong dự án của bạn, bạn cần đảm bảo rằng các khoản chính, như một mô hình điều hành, các công cụ hạ tầng, bộ nhớ dự án, và quản lý phát hành phải được đưa vào, và được cấp vốn phù hợp, trong vụ thầu dự án của bạn”. Một chỉ dẫn rất tốt cho tính bền vững các dự án phần mềm tự do nguồn mở ở Việt Nam học tập.

Hầu hết các cơ quan câp vốn hàn lâm khuyến khích các dự án mà họ cấp vốn để phát hành phần mềm của họ theo một giấy phép nguồn mở, và để trích lập dự phòng cho tính bền vững phần mềm của họ ngay từ đầu. Điều này không có nghĩa chỉ đơn giản phát hành mã theo một giấy phép nguồn mở. Nó cũng liên quan với việc xây dựng một kế hoạch về tính bền vững ngay từ đầu của dự án và duy trì nó trong suốt vòng đời của dự án.

Trong phần đầu của tài liệu này chúng tôi mô tả các vấn đề chung nhất về tính bền vững mà các dự án chúng tôi tư vẫn đang đối mặt. Trong phần 2 chúng tôi sẽ liệt kê các tài nguyên bạn nên cân nhắc đưa vào trong ngân sách dự án của bạn. Điều này sẽ giúp bạn tránh được những cạm bẫy phổ biến và làm gia tăng những cơ hội của dự án để trở nên bền vững. Tài liệu này sẽ là hữu dụng nhất khi chuẩn bị một vụ thầu dự án, những cũng có thể có lợi khi một dự án vừa mới bắt đầu.

Các vấn đề chính về tính bền vững

OSS Watch thường xuyên được tiếp cận tới các dự án hàn lâm đã thất bại trong giải quyết tính bền vững đối với phần mềm của họ một cách thích đáng hoặc theo một cách thức đúng lúc. Một số vấn đề phổ biến bao gồm: không lôi cuốn được sự quan tâm của các bên thứ 3, quản lý tồi hạ tầng cộng đồng, thiếu bộ nhớ của dự án và quản lý phát hành không hiệu quả.

Không lôi cuốn được sự quan tâm của các bên thứ 3

Các dự án hàn lâm thường điển hình là tốt trong việc làm cho cộng đồng nhận thức được về công việc của họ, nhưng họ ít làm tốt trong việc lôi kéo sự tham gia của cộng đồng vào bản thân dự án. Điều này là sống còn cho tính bền vững dài lâu của dự án. 2 câu hỏi chính để hỏi khi bắt đầu xây dựng một cộng đồng dự án là: Ai là cộng đồng dự án? Liệu tôi có cần phải xây dựng một cộng đồng mới (Bản dịch tiếng Việt), hay liệu một cộng đồng đang tồn tại mà dự án của tôi nên là một phần của nó? Điều này có nghĩa là trước khi làm bất kỳ công việc gì khác có liên quan tới cộng đồng, bạn cần khai thác các dự án đang tồn tại để xem liệu bạn có thể hoặc thúc đẩy công việc của họ hay đóng góp cho nó. Bằng cách làm như vậy, bạn sẽ tránh được việc đúp bản các nỗ lực, và bằng việc nhúng dự án của bạn vào trong một cộng đồng lớn hơn, bạn sẽ cải thiện được tính bền vững tiềm tàng của nó. OSS Watch có thể nhận thức được về các dự án tương tự như của bạn, với nó bạn có thể cộng tác được.

Việc lên kế hoạch cho việc cấp vốn liên tục của đội cốt lõi hiếm khi là đủ để đảm bảo tính bền vững. Phần mềm nguồn mở (PMNM) thường trở nên bền vững thông qua sự đóng góp của các bên thứ 3 ở các dạng khác nhau. Trong nhiều trường hợp, các lập trình viên của các bên thứ 3 được cấp vốn để làm việc trong những vấn đề bổ sung, và cách nhanh nhất đối với họ để giải quyết vấn đề là làm việc trong mã đang tồn tại rồi. Để tạo thuận lợi cho những đóng góp của bên thứ 3, bạn cần đẩm bảo rằng mã nguồn là sẵn sàng từ đầu và đưa ra chỉ dẫn và cấu trúc rõ ràng trong đó mọi người có thể đóng góp (Bản dịch tiếng Việt).

Nhiều dự án nghĩ rằng không đáng cho nỗ lực có liên quan trong việc xây dựng hạ tầng cộng đồng ở giai đoạn sớm, vì dự án của họ là nhỏ, chưa hoàn chỉnh hoặc bao trùm một thị trường phù hợp. Tuy nhiên, kinh nghiệm chỉ ra rằng dễ dàng hơn và rẻ hơn để làm điều này trước khi cộng đồng bắt đầu chú ý tới. Một hoạt động chủ chốt về khía cạnh này là áp dụng một mô hình điều hành (Bản dịch tiếng Việt). Đây là một tài liệu mô tả rõ ràng cách mà các bên thứ 3 sẽ tham gia vào với dự án và cung cấp các qui tắc và các đường biên đảm bảo rằng dự án vẫn có khả năng quản lý được trong các tài nguyên có sẵn. OSS Watch đưa ra một số tài liệu điều hành mẫu và có thể làm việc với các dự án để giúp họ tùy biến chúng một cách phù hợp.

Mọi người thường quan tâm rằng việc áp dụng một mô hình điều hành có liên quan quá nhiều tới sự quan liêu đối với đội dự án nhỏ. Một lần nữa, vấn đề không phải là liệu đội đang tồn tại có cần nó hay không, mà là liệu một thành viên mới với việc cấp vốn độc lập có khả năng tham gia vào dự án được hay không. Nếu sự quan liêu là mối quan tâm đối với bạn, thì chúng tôi khuyến cáo bắt đầu với một mô hình nhẹ cân thực sự, như nhà điều tra chính yếu có các sức mạnh phủ quyết và ủy quyền, trong khi các quyết định được đưa ra thông qua một quá trình đồng thuận lười (các khái niệm đó cũng được thảo luận trong tài liệu các mô hình điều hành của chúng tôi).

Việc rẽ nhánh, hoặc lấy mã nguồn và thiết lập một dự án cạnh tranh, là vấn đề khác mà các dự án nguồn mở phải được chuẩn bị để làm việc. Nếu có sự không đồng ý trong cộng đồng, thì việc rẽ nhánh có thể dường như sẽ là giải pháp hiệu quả nhất trong các giai đoạn sớm của một dự án. Tuy nhiên, điều này có thể ngăn cản các bên thứ 3 trong việc áp dụng dễ dàng mã của bạn, và sẽ, theo thời gian, tạo ra các vấn đề đáng kể về duy trì đối với đội của bạn. Quả thực, bạn không nên chọn đường lối này mà không có sự hiểu biết đầy đủ về các hậu quả của nó.

Quản lý tồi hạ tầng cộng đồng

Bổ sung thêm vào việc chỉ ra dạng giấy phép (Bản dịch tiếng Việt) sẽ điều hành các kết quả đầu ra của phần mềm của bạn, như được JISC và các nhà cấp vốn khác bắt buộc, bạn nên làm rõ các quyền sở hữu trí tuệ (IPR) sẽ được quản lý như thế nào (Bản dịch tiếng Việt) trong dự án. Cũng là sống còn việc bạn duy trì một hồ sơ rõ ràng và không tù mù về tất cả những đóng góp của dự án, cả mã và không mã. Qui trình này sẽ được đơn giản đi nhiều nếu bạn sử dụng một hệ thống kiểm soát phiên bản, như một phần của một tập hợp các công cụ phát triển mở và các qui trình hỗ trợ (Bản dịch tiếng Việt).

Mọi người thường nghĩ rằng một dự án nguồn mở có liên quan tới việc chi tiêu một số lượng khổng lồ thời gian thông báo cho mọi người về những phát triển đang diễn ra. Nhưng điều này không cần thiết phải thế. Nếu bạn chọn đúng các công cụ và qui trình (Bản dịch tiếng Việt), thì giao tiếp bên ngoài sẽ đơn giản là một sản phẩm phụ của các hoạt động phát triển.

Nhiều dự án nguồn mở làm cho phần mềm của họ sẵn sàng để tải về và sử dụng lại thất bại về mặt tài liệu. Một dự án nguồn mở đúng thực sự đảm bảo rằng tất cả các giải pháp được áp dụng, bao gồm cả qui trình ra quyết định được sử dụng để đạt được chúng, được chia sẻ cởi mở và được ghi lại đầy đủ để tham chiếu sau này. Điều này là vì những lý do đằng sau một quyết định đặc biệt thường là quan trọng hơn, với sự tôn trọng đối với tính bền vững của dự án, hơn là bản thân phần mềm. Tài liệu (Bản dịch tiếng Việt) như vậy làm giảm các cơ hội lặp đi lặp lại các sai lầm trong quá khứ, và đảm bảo rằng nền tảng cũ không cần phải được đề cập tới một cách lặp đi lặp lại.

Các dự án vì thế nên tiến hành tất cả sự phát triển bằng việc sử dụng các công cụ có khả năng trong việc giữ lại bộ nhớ của dự án (Bản dịch tiếng Việt). Tiếp cận này sẽ cho phép họ tập trung vào sự phát triển, trong khi đảm bảo rằng tất cả các quyết định là mở cho bình luận trong cộng đồng, đã và đang được ghi lại theo một cách thức mà từng người có mong muốn hiểu được ngữ cảnh và động lực của dự án đằng sau từng quyết định có thể làm được thế.

Thiếu bộ nhớ dự án

Tại OSS Watch chúng tôi khuyến khích các dự án tạo ra một môi trường cộng đồng vì điều này là cách để đảm bảo tính bền vững cho PMNM. Đó là, phần mềm được các nhóm phân tán được cấp vốn cho các dự án chồng lấn nhau nhưng tiềm tàng không có liên quan tới nhau, phát triển một cách cộng tác.

Đối với chúng tôi, chìa khóa cho tính bền vững là phải đảm bảo rằng dự án lôi cuốn được sự chú ý từ cộng động rộng lớn nhất có thể. Điều này có nghĩa là một bộ nhớ dự án cần phải được tạo ra cho những người tới sau nỗ lực được cấp vốn ban đầu. Không có hạ tầng cộng đồng thì sẽ không có bộ nhớ dự án; không có bộ nhớ dự án thì cách duy nhất để giữ cho dự án sống được là có thêm nữa việc cấp vốn cho đội khởi xướng ban đầu. Thất bại trong thiết lập bộ nhớ dự án trong quá trình phát triển được cấp vốn sẽ ảnh hưởng tới sự tạo ra những dự án mới dựa vào dự án cũ. Nó cũng làm cho khó khăn hơn nhiều đối với những người đóng góp bên ngoài có tiềm năng để đánh giá dự án của bạn và hiểu được đầy đủ về dự án.

Việc duy trì bộ nhớ dự án liên quan tới những điều như việc làm tài liệu những thảo luận và các quyết định được đưa ra bằng việc đưa chúng vào danh sách thư, ghi lại và xếp đặt ưu tiên cho các vấn đề trong trình theo dõi các vấn đề, nói chuyện với những người sử dụng để hiểu các nhu cầu của họ... Tất cả chúng là các hoạt động mà nên được bất kỳ dự án nào cũng thực hiện. Sự khác biệt duy nhất ở đây là việc điều này được thực hiện trong những cánh cửa mở, chứ không phải đóng. Sự trả giá là bạn sẽ tạo ra được một bộ nhớ dự án cho các thành viên tiềm tàng của cộng đồng trong tương lai, họ tiết kiệm được thời gian nếu dự án trở nên thành công.

Quản lý phát hành không hiệu quả

Trong các dự án nguồn mở điều cự kỳ quan trọng là phần mềm được phát hành sớm và thường xuyên. Việc phát hành sớm và thường xuyên cho phép mọi người dùng thử phần mềm dễ dàng hơn và làm gia tăng các cơ hội có được những người đóng góp mới. Một qui trình quản lý phát hành (Bản dịch tiếng Việt) là sống còn để giúp các lập trình viên phối hợp các hoạt động của họ hướng tới việc đưa ra các phiên bản mới của phần mềm, trong khi giải quyết các vấn đề cấp phép và quyền sở hữu trí tuệ IPR với nhiều đóng góp của họ. Một tài liệu về các chi tiết kỹ thuật của qui trình phát hành (Bản dịch tiếng Việt) đưa ra một số chỉ dẫn thực tế tốt nhất, cùng với một danh sách kiểm tra.

Các tài nguyên của tính bền vững

Lý tưởng mà nói, phiên bản đầu tiên của kế hoạch bền vững nên xuất hiện càng sớm càng tốt ở giai đoạn đấu thầu dự án. OSS Watch có thể giúp bạn chuẩn bị điều này, như được mô tả trong Tư vấn cho các vụ thầu dự án (Bản dịch tiếng Việt). Sau đó, kế hoạch bền vững nên được cập nhật định kỳ để phản ánh việc mở rộng các cơ hội cho sự cộng tác và những đóng góp của các bên thứ 3 khi cộng đồng dự án lớn lên.

Hầu hết các dự án không có khả năng đánh giá lượng thời gian cần thiết để xây dựng một cộng đồng bền vững. Nếu họ nghĩ về nó, thì họ có xu hướng ước lượng quá cao lượng thời gian cần thiết, hoặc quyết định cái giá phải trả là không đáng và vì thế bỏ nó khỏi kế hoạch.

Tuy nhiên, điều quan trọng để nhận thức rằng hầu hết công việc phát triển cộng đồng đóng góp cho một dự án được quản lý tốt theo nhiều cách thức. Trong ngắn hạn, nó đảm bảo rằng có một cấu trúc được xác định cho việc quản lý các khía cạnh phần mềm của dự án. Trong trung hạn, nó đảm bảo rằng thời gian không bị bỏ phí vào các nhiệm vụ được lặp lại, là mở đầy đủ và những người đóng góp có khả năng tham gia vào với dự án với hiệu quả tối đa.

Để giúp bạn lên kế hoạch, bảng bên dưới liệt kê một số hoạt động mà bạn nên đặt lịch trình trong vụ thầu của bạn, những lợi ích mà chúng mang lại cho dự án và thời gian ước lượng cần thiết để hoàn thành chúng.

Đầu đề | Số giờ | Hoạt động | Lợi ích

Mô hình điều hành |30| Hiểu các mô hình điều hành (Bản dịch tiếng Việt) khác nhau. Lấy một mẫu template tài liệu điều hành từ OSS Watch và tùy biến nó cho dự án | Xác định phạm vi của dự án và qui trình ra quyết định cho quản lý chiến lược. Thiết lập hạ tầng |10-30|. Thiết lập, cấu hình và viết tài liệu cho các công cụ cần thiết cho dự án. Nhanh hơn nếu sử dụng một nhà cung cấp đặt chỗ hosting như Sourceforge or Googlecode, lâu hơn nếu sử dụng các cơ sở đặt chỗ cục bộ. Tối ưu hóa các khía cạnh quản lý phần mềm của dự án và các kênh các thành viên cộng đồng vào trong qui trình quản lý. Bộ nhớ dự án. |8 cho mỗi tháng cho một người đóng góp toàn thời gian| Viết tài liệu tất cả các hoạt động theo một cách thức trực quan. Đảm bảo tất cả giao tiếp của dự án được ghi lại trong các danh sách thư và tất cả các đề xuất được ràng buộc tới các danh sách cho sự thảo luận và phê chuẩn. Ghi lại và sắp xếp ưu tiên cho các vấn đề trong trình theo dõi các vấn đề|. Ghi lại bộ nhớ dự án và khuyến khích sự tham gia của các bên thứ 3. Quản lý phát hành |8 cho một tháng|. Thiết lập một qui trình quản lý phát hành (Bản dịch tiếng Việt) và đảm bảo tất cả các lập trình viên tuân theo nó. Phát triển và duy trì các script xây dựng phiên bản. Đảm bảo tất cả các vấn đề pháp lý được giải quyết và chất lượng từng phát hành là đủ tốt cho những người sử dụng để cài đặt và chạy dễ dàng|. Quản lý yêu cầu “phát hành sớm, phát hành thường xuyên” vì sự bền vững của nguồn mở. Tạo thuận lợi cho sự tham gia của các bên thứ 3 bằng việc đảm bảo họ có thể xây dựng phần mềm của dự án một cách dễ dàng.

Kết luận

Nhiều dự án hàn lâm không giải quyết được các vấn đề về tính bền vững của phần mềm một cách phù hợp hoặc đúng thời gian. Một số vấn đề phổ biến nhất bao gồm việc không lôi cuốn được sự quan tâm của các bên thứ 3, quản lý tồi hạ tầng cộng đồng, thiếu tiền cho dự án và quản lý phát hành không hiệu quả. Để ngăn chặn những vấn đề như vậy trong dự án của bạn, bạn cần đảm bảo rằng các khoản chính, như một mô hình điều hành, các công cụ hạ tầng, bộ nhớ dự án, và quản lý phát hành phải được đưa vào, và được cấp vốn phù hợp, trong vụ thầu dự án của bạn. OSS Watch có thể giúp bạn làm điều đó (Bản dịch tiếng Việt).

Most academic funding bodies encourage the projects they fund to release their software under an open source licence, and to make provision for the sustainability of their software from the outset. This does not mean simply releasing code under an open source licence. It also involves building a sustainability plan at the beginning of the project and maintaining it during the project’s lifetime.

In the first part of this document we describe the most common sustainability issues confronting the projects that we advise. In the second part we list the resources you should consider including in your project budget. This will help you to avoid common pitfalls and increase the project’s chances of becoming sustainable. This document will be most useful when preparing a project bid, but can also be beneficial when a project has just started.

Main sustainability issues

OSS Watch is frequently approached by academic projects who have failed to address the sustainability of their software appropriately or in a timely manner. Some of the common issues include: failure to attract third party interest, poor management of community infrastructure, lack of project memory and inefficient release management.

Failure to attract third-party interest

Academic projects are typically good at making the community aware of their work, but they are less good at engaging the community in the project itself. This is crucial to the long-term sustainability of the project. Two key questions to ask when starting to build a project community are: Who is the project community? Do I need to build a new community, or is there an existing one my project should be part of? This means that before doing any other community-related work, you need to explore existing projects to see if you can either leverage their work or contribute to it. By doing so, you will avoid duplication of effort, and by embedding your project in a larger community, you will improve its potential sustainability. OSS Watch may be aware of similar projects to yours, with which you could collaborate.

Planning for continued funding of the core team is rarely sufficient to ensure sustainability. Open source software often becomes sustainable through third-party contribution in various forms. In many cases, third-party developers are funded to work on complementary problems, and the fastest way for them to solve the problem is to work on already existing code. In order to facilitate third-party contributions, you need to ensure that the source code is available from the outset and to provide clear guidance and structures within which people can contribute.

Many projects think that it is not worth the effort involved in building community infrastructure at an early stage, since their project is small, incomplete or covers a niche market. However, experience shows that it is easier and cheaper to do this before the community starts to take an interest. A key activity in this respect is to adopt a governance model. This is a document that clearly describes how third parties are to engage with the project and provides the rules and boundaries that ensure that the project remains manageable within the resources available. OSS Watch provides a number of template governance documents and can work with projects to help them customise these as appropriate.

People are often concerned that adopting a governance model involves too much red tape for a small project team. Again, the issue is not whether the existing team needs it, but whether a new member with independent funding is likely to participate in the project. If red tape is of concern to you, we recommend starting with a really lightweight model, such as the principal investigator has veto and delegation powers, while decisions are made through a process of lazy consensus (these terms are also discussed in our governance models document).

Forking, or taking the source code and setting up a competing project, is another issue open source projects must be prepared to deal with. If there is disagreement within the community, forking may seem to be the most efficient solution in the early stages of a project. However, this may prevent third parties from easily adopting your code, and will, over time, create significant maintenance problems for your team. Indeed, you should not choose this path without fully understanding its consequences.

Poor management of community infrastructure

In addition to indicating the type of licence that will govern your software outputs, as mandated by JISC and other funders, you should clarify how IPR will be managed within the project. It is also vital that you maintain a clear and unambiguous record of all project contributions, both code and non-code. This process will be greatly simplified if you use a version control system, as part of a key set of open development tools and supporting processes.

People often think that an open source project involves spending a huge amount of time informing everyone about ongoing developments. But this need not be the case. If you select the right tools and processes, the external communication will simply be a by-product of the development activities.

Many open source projects that make their software available for download and reuse fail on the documentation front. A true open source project ensures that all the solutions adopted, including the decision-making process used in reaching them, are openly shared and appropriately recorded for later reference. This is because the reasons behind a particular decision are often more important, with respect to project sustainability, than the software itself. Such documentation reduces the chances of repeating past mistakes, and ensures that old ground does not need to be covered repeatedly.

Projects should therefore conduct all development using tools that are capable of preserving project memory. This approach will enable them to focus on development, while ensuring that all decisions are open for comment within the community, having been recorded in such a way that everyone who wishes to understand the project context and the motivations behind each decision can do so.

Lack of project memory

At OSS Watch we encourage projects to create a community environment because this is the way to ensure sustainability for open source software. That is, the software is developed collaboratively by disparate groups funded for overlapping but potentially unrelated projects.

For us, the key to sustainability is to ensure that the project attracts interest from the widest possible community. This means that a project memory needs to be created for those who come after the initial funded effort. Without community infrastructure there is no project memory; without memory the only way to keep the project alive is to get more funding for the originating team. Failing to set up project memory during funded development will affect the creation of new projects based on the old. It also makes it much harder for external potential collaborators to evaluate your project and fully understand the project.

Maintaining project memory involves things like documenting discussions and decisions taken by posting them to the mailing list, recording and prioritising issues in the issue tracker, talking to users to understand their needs, etc. All these are activities that should be undertaken by any project. The only difference here is that this is done in the open, not behind closed doors. The pay-off is that you will be creating a project memory for potential future community members, which saves time if the project becomes successful.

Inefficient release management

In open source projects it is extremely important that software is released early and often. Releasing early and often enables people to try out the software more easily and increases the chances of getting new contributors. A well-defined release management process is crucial for helping developers coordinate their activity towards producing new versions of the software, while addressing the IPR and licensing issues associated with their multiple contributions. A separate document on the technical details of the release process provides some best practice guidelines, along with a checklist.

Sustainability resources

Ideally, a first version of the sustainability plan should appear as early as the project bid stage. OSS Watch can help you to prepare this, as described in Advice for project bids. Thereafter, the sustainability plan should be periodically updated to reflect the expanding opportunities for collaboration and third-party contributions as the project community grows.

Most projects are unable to estimate the amount of time necessary to build a sustainable community. If they do think about it, they tend to over-estimate the amount of time required, or decide that the pay-off will not be worthwhile, and thus drop it from the plan.

However, it is important to acknowledge that most community development work contributes to a well-managed project in many ways. In the short term, it ensures that there is a defined structure for managing the software aspects of the project. In the medium term, it guarantees that time is not wasted on repetitive tasks, such as producing and testing releases. In the long term, it ensures that the project is fully open and contributors are able to engage with the project with maximum efficiency.

To help you plan, the table below lists some of the activities you should schedule into your bid, the benefits they bring to the project and the estimated time required to accomplish them.

Title | Hours | Activity | Benefits

Governance model | 30 | Understand the different governance models. Take a governance document template from OSS Watch and customise it for the project | Defines scope of project and decision-making process for strategic management Infrastructure set-up | 10-30 | Set up, configure and document the tools needed for the project. Quicker if using a public hosting provider like Sourceforge or Googlecode, longer if using local hosting facilities. | Streamlines the software management aspects of the project and channels community members into the management process Project memory | 8 per month per full time contributor | Document all activity in a visible way. Ensure all project communication is recorded on mailing lists and all proposals are brought to the lists for discussion and approval. Record and prioritize issues in the issue tracker. | Records project memory and encourages third-party engagement Release management | 8 per month | Set up a release management process and ensure all developers follow it. Develop and maintain release build scripts. Ensure all legal issues are addressed and the quality of each release is good enough for users to install and run easily. | Manages the “release early, release often” requirement for sustainable open source. Facilitates third-party engagement by ensuring they can build the project software easily

Conclusion

Many academic projects fail to address software sustainability issues appropriately or in a timely manner. Some of the most common issues include failure to attract third party interest, poor management of community infrastructure, lack of project memory and inefficient release management. To prevent such problems in your project, you need to ensure that key items, such as a governance model, infrastructure tools, project memory, and release management are included, and properly budgeted for, in your project bid. OSS Watch can help you do just that.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com