Rules to Better Open Source Software

3rd party tools are awesome. They give us quick out-of-the-box solutions to common problems saving tonnes of dev time.

Unfortunately, with traditional 3rd party solutions, you have limited options for making changes to the product. You can send through feedback, but there is no guarantee that the devs will look at it, and even if they do look at it, they might not action it. So, how can we break through this locked system to get the features we want?

Open Source software is the key to making all your dreams come true 🤩.

Open-sourcing software has become increasingly popular for companies as it can help them innovate, attract talent, and build a good reputation. It also helps the community by providing free software that can be used by anyone.

If you get a tradesman in to fix your tap, and on the way to the kitchen he sees your bookcase is messy and re-order it for you... you probably wouldn't be very happy.

When you contribute to open source projects it is great to fix bugs and contribute features, but it is essential to be respectful of the people that came before you, and possibly have invested lots of time in putting everything where it currently is.

For the original article check out Don't "Push" Your Pull Requests by Ilya Grigorik.

Open source software projects love it when the community get involved and pitch in.

It's great when someone fixes a bug.

A short PR to fix a small problem is easy to review and accept.

It is important that users of your open source contributions are aware if you are maintaining them and keeping them up to date.

The key to building a great open source project is to build a great community around your project.

To do this it is essential that potential contributors can find out how to get involved.

The code within your solution should be consistent. (We all know that)

In an open source project the easy way to ensure that all developers share and are aware of the expectations is to include and ENGINEERING-GUIDELINES.md markdown file that includes important technical considerations like:

More and more projects are being created as Open Source. However just because you’re created an open source project doesn’t mean you give everything in your cookie jar away. You should only release your code subject to a licence agreement. A common confusion when putting projects onto Open Source platforms like GitHub is ‘What License Should I Use?”. We have our own opinions but we aren’t lawyers so if you want to know what’s best for you speak with your lawyer.

Maintaining a clean git history is important for readability and understanding the changes that have been made to a codebase. This is especially important when working in a team, as it allows you to see the changes that have been made to a file over time, and who made them. This can be useful for debugging, and for understanding why a particular change was made.

Things that create a good git history include:

Some companies want to keep their projects closed-source in order to profit from their products. However, there are several benefits to keeping the source open including:

• Community contribution and feedback
• Allowing controlled free use of your products

We want our projects to be financially sustainable while supporting the open-source space. Let's take a look at the licensing options for open-source projects on GitHub.