This is why we love open source

We try to contribute to open source libraries, to improve the quality of those packages and (our) applications using them. We understand the benefits of using Open Source code and give back to the community. We would like to explain why and to inspire you to do the same!

(Battle) Tested Code

Of course you need to test your code, regardless if it's open or closed source. Popular libraries tend to have a good set of tests. Code contributions are not accepted unless they adhere to the defined coding style, best practices and the changes are coverered by new tests. These tests and the results are publicly available for everyone to see, so we can take this into account when selecting a library to use.

When you create the functionality for a problem, the use case can be very limited. Open sourcing the code will lead to more usage and you will encounter edge-cases more often. Every edge-case can be submitted with a (failing) test and a solution, to prevent the same bug from happening again.

Proudly Invented Elsewhere

We don't need to reinvent the wheel over and over again. As developers, we like to take on new challenges and build exciting features. We should focus on the customisation and not create the same thing over-and-over again. Of course not every package is exactly how we would have build it ourselves, but most of the times it is better to continue work on existing code and learn why they did it that way. If we're sure we can do better, we can always fork the package or create an alternative package, but we prefer not to.

Not everyone needs to be an expert in the underlying technologies, as long as the package abstracts the difficulties away. Using the documentation, tests and code, we can get a clear understanding of the technology and how to use the package. Coupled with a stable public interface, we don't have to worry about small changes breaking our code when a feature is changed.

Reusability First

When creating a package, we tend to have higher standards. We know other people will be using and reviewing our code. Once it's out there, it doesn't go away, so we make sure it's coherent, adhering to a Code Style (PSR-2), has unit tests and proper documentation. Also, extensibility and seperation of concerns is clear from the beginning, not an afterthought. From the ground up, our code has to be created to be shared with other projects in different use cases.

And even when the code isn't great, it's probably helpful for others. Instead of creating the same thing over and over again, others can improve our code, add tests/documentation or create awesome features that we are unable to find the time for!