How to make your project Open Source

Things to consider when creating open source

• Ensure your resources have capacity to maintain the code.
• Ensure you have a process for responding to feedback from the open source community.
• Decide where you will host your code.

The basic principles for Open Source Initiative presented HERE.

Recomended Open Source Solutions:

Useful links:

• OpenAPI Specification v3.1.0 | Introduction, Definitions and More
• OpenAPI Specification – Version 3.1.0 | Swagger
• REST API Documentation Tool | Swagger UI

If you aren’t going to open source your project, the principles outlined in this guide can still be applied when developing code, to ensure good practice. This is known as inner source. Learn more about inner source in this GitHub article.

1) Choose a Open Source licence

An open source licence is a type of software licence that allows source code to be used, studied, modified and shared according to defined terms and conditions.

There are a variety of open source licences each with differing terms and conditions in relation to using, modifying and sharing source code.

Most, if not all, open source licences will require anyone who uses the open source work to acknowledge the copyright owner. You should specify who the copyright owner is in a copyright notice attached to your work.

The following selection is an example of popular open source licences with sustainable communities:

• Apache License 2.0
• MIT license
• BSD 3-Clause “New” or “Revised” license
• BSD 2-Clause “Simplified” or “FreeBSD” license
• GNU General Public License (GPL)
• GNU Library or “Lesser” General Public License (LGPL)
• Mozilla Public License 2.0
• Common Development and Distribution License
• Eclipse Public License version 2.0
• Creative Commons v4.0

More information about licence types is available on the web page.

When choosing an open source licence, it is important to consider any open source packages you have used from other creators. Some licences require you to use the same licence when you release packages that contain work from other creators. For example, if your package includes code that was licensed under a GNU General Public License you must release it under a GNU General Public License.

You may want to seek legal advice to determine whether the licence you have selected provides the protection you require for your work and complies with the licences of any work you have used.

2) Prepare your code for release

1. Get your code into version control.
2. If your project is already in version control, consider creating a new version for public release.
3. Commit early and often. This is an important workflow pattern to utilise while developing a project. It promotes openness, transparency and provides an opportunity for regular feedback and review.
4. Clean your code of any proprietary information.
   Before making the repository publicly available make sure the code is peer-reviewed and audited for any proprietary information. It is essential to ensure that personal access tokens and other private data is not inadvertently made public.
   Things to consider when reviewing the code include:
   • Contributions are attributable to the user account configured by the version control. Consider the identity of the account making commits because these are viewable to anyone with access to the repository.
   • Remove all passwords, API keys, secret keys and credentials from the source (and the repository’s history).
   • Remove any internal URLs that should not be discoverable by the outside world. These should be in properties files and not checked in to the source code repository.
   • Code should be scanned using automated audit tools (e.g. NodeJS provides npm audit). These find security vulnerabilities in your packages and upgrade and fix them where it can.
   • Latest versions of dependent libraries should be used. Where possible incorporate automatic updates into your continuous integration pipeline.
   • Any third-party applications that are embedded in the code (Google Analytics or similar) should be declared. This includes any accounts that are required to use the technology.
   • The Essential 8 and OWASP Top 10 should be consulted to ensure the appropriate security is up to date.
   • You may also want to check your dependencies are up to date and have no further vulnerabilities that you are going to pass on to others.
5. Ensure your project contains a readme file with the following information:
   • project background and purpose
   • how to get started (with examples)
   • any known issues or bugs
   • licence
   • attribution
   • contact information
   • contribution guidelines

   Providing the readme file ensures people can reuse and contribute to the project. These files help people understand the project and reduce barriers to adoption.

3) Develop a maintenance, continuous improvement and support plan

It’s a good idea to have a plan that outlines how you are going to evolve and continue to contribute to your open source project. This should include:

• maintenance (patching)
• continuous improvement
• support

Small, incremental updates to your project are preferred. This benefits peer reviews by keeping the scope to a smaller context and making them easier to perform. It can also improve the ‘pulse’ of the project. The amount of activity on a project improves user confidence in its community and maintenance.

If you can’t continue maintenance, you could try to find an alternative maintainer from the community. If a suitable maintainer can’t be found and the project does need to be abandoned a notice in the project readme should state this.

4) Release your project

Once you’ve followed the steps above you can make the project available on your platform of choice.

You can also consider packaging your code as a dependency artefact which makes it simpler for others to include within their projects. The dependency list publishing process differs between programming languages and applications. The following dependency and package managers are popular and freely available:

• Node.JS -> NPM
• Java -> Maven Central
• .Net -> NuGet
• Python -> PIP
• PHP -> Composer
• Perl -> PPM
• Ruby -> Gems

Using these tools as a distribution method makes your code far easier to deploy and maintain, as well as providing semantic versioning for package management and extra documentation capabilities.

If you want to publish your code to the opencode.md account, contact the opencode.md@gmail.com to express your interest.