Rules to Better Open Source Software - 8 Rules
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 Source software is a great option, but it's not always the best. Make sure to consider these points before deciding to use open source software.
Video: Utilizing Open Source Software with Brady Stroud (3 min)
- Transparency - when a bug occurs you can look at the source code and easily find the area where the bug occurs
- Usually free - there are some paid open source software options
- Customizable - you can fork and adapt it to your own needs
- Quality - open source projects have thousands of developers going through the code which ensures quality
- Security - Any vulnerabilities are public so they are more likely to be noticed and fixed (This also means hackers could fix and exploit vulnerabilities)
- Lifespan - Open source projects are more likely to be abandoned
- Support - Paid software will typically have a support team you can get in touch with if you have issues. For open source software you can create GitHub issues, but there is a chance the repository owners wont respond
- Different licenses have different requirements. See what to check before installing 3rd party libraries for more info.
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.
Some good examples of companies that open source their code are:
Open-sourcing opens your project to a broad range of people with unique skillsets can help accelerate your project's innovation. It also allows you to leverage the work of others to help your project grow.Every time someone submits a PR fixing a bug, you are getting free software development.
Being a part of the developer community is a great way to discover potential employees. If a developer has been using a company's open source code for years, they are more likely to want to join and keep using that code.
Making your code public shows confidence in your service and can be a great oppurtunity to demonstrate your company's skills and practices.
Open-sourcing your code doesn't have to mean making your whole project public. You can take small chunks of code and make them generic enough so they're useful to others.
Examples of this are:
- jsakamoto/Toolbelt.Blazor.HotKeys - This repo contains a small library that allows you to add hotkeys to your Blazor apps
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.
This issue is described beautifully here Open Source Contribution Etiquette by Miguel de Icaza.
For the original article check out Don't "Push" Your Pull Requestsby 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 pull request to fix a small problem is easy to review and accept.
It's great when someone adds a much-needed feature...as long as the feature fits in with the project the core contributors have for the project...and it meets the existing coding patterns and engineering standards.
This is where frustration often starts to set in on open source projects.
A contributor has a great idea for a feature, or identifies an area where they can add value and does so without consulting with the core contributors who have often spent hundreds of hours working on the project.
Their contribution might solve their problem, but after it has been accepted it will most likely be left for the core contributors to maintain.
# Poor Communication Contribution
- developer has good idea for project
- bashes away and writes 600 lines of code
- submits pull request
- core contributor looks at large pull request she doesn't fully understand purpose of request / the problem it solves she doesn't like that the PR author hasn't followed the existing coding standards she makes a push back comment
Figure: Bad Example - Poor early communication can lead to mis-directed work and pull requests not being accepted
# Good Communication Contribution
- developer (PR Author) has good idea for project
- reviews the list of outstanding issues for the project and confirms that someone hasn't already had the same idea and started a discussion on it
- author creates an issue on GitHub and outlines the problem they are trying to solve, and outlines their suggested solution
- the core contributors and other interested parties can help refine both the idea for the feature and the suggested implementation
- the author can then start working on the feature knowing that their idea for the project complies with the maintainers vision for the project and know it is likely to be merged into the core codebase
Figure: Good Example - Good communication leads to collaboration and better outcomes for the author and the project
# Projects with Internal Teams
- Internal SSW team members should only work on features during work hours that have been assigned to a release by the core contributors for a project
- Features will be assigned to a release during the Community Standup
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.
It is a common pattern for open source projects to contain a CONTRIBUTING.md markdown file that supplies information on 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:
- Copyright header requirements
- Approved external dependencies
- Coding guidelines and standards
- Source control requirements
- Branching strategy
- Solution and project folder structure and naming
- Unit testing requirements
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.