Open-source for the win! Benefits of contributing to OSS

At Tratif we believe that contributing to open-source software has very positive effect on organizations and individual developers. We rely on open-source software in almost every project that we have delivered. This is the foundation of our approach: open and proven solutions of highest quality and the fastest approach to fixing issues, supported by the community. We are very thankful to the OSS movement for multiple great projects. They make day-to-day development of web and enterprise applications easier and more fun.

We try to contribute to OSS whenever possible. This includes contributing to existing projects (via pull requests and issue reporting) as well as maintaining our own open-source projects. Why does it matter so much? There are multiple answers to this question. Let me share ones that are most important to me.

Contributing to growth

Probably the most important reason for contributing open-source code is just becoming a co-author, not only a consumer. Many developers spend their time and effort on improving tools that help you. By reporting issues or creating pull requests, you simply say “thank you”. Also, the open-source software is so powerful thanks to large distributed teams working on it. When a project is open, then theoretically the size of the team is unlimited. By joining the community you make such team even more capable of delivering great software.

Joining the team that develops your favourite projects makes it better. And in turn, it better supports your own endeavours (e.g. commercial projects). Opening your own ideas to the public (as new projects) gives other developers an opportunity to use and optimise them. They can start contributing back. All of this generates a very positive feedback loop.

Exchanging ideas and knowledge

Opening the code to a public audience means that developers from around the world may review it and propose extensions. This can lead to great synergy. Very often delivered results exceed the original author (or authors) vision. We observed this several times during the development of our open-source library. Developers used it and came up with great ideas for improvements. Very often they even provided pull requests with working prototypes or even ready-to-be-released production code and documentation.

Contributing to existing projects has a similar effect. It gives you a chance to join a new team and project. This is an opportunity to learn new approaches and coding standards. Being reviewed by new people might be also a refreshing idea — as they might have different views than your typical peer reviewers.

Presenting your skills to the public audience

Many developers and companies spend most of their time on writing NDA-protected code. Many systems/applications are meant for internal enterprise networks (i.e. they are not exposed to public users via the Internet). This means that very often developers do not have any open portfolio that they can present. In such situation they are limited to just project descriptions in their CVs.

Writing open-source software is a great way of showing your skills to the world. This might be crucial when applying for a new job or talking to a potential customer. A public project can be a showcase of clean code, thorough documentation, version and change management, approach to code review and others.

Self-improvement in a distributed and asynchronous team

As mentioned above, in the open-source world teams may grow quickly. They are not limited by physical locations or time zones. This means that cooperation is typically distributed and asynchronous. There is no easy way to discuss the latest pull request during a water cooler conversation. This means that maintenance of such projects requires the highest communication skills. This includes, but is not limited to:

  • usage documentation — even the best software is useless when it is misunderstood; just opening the project theoretically gives everyone a chance to use it — good documentation makes a difference between theory and practice
  • code documentation — thanks to which developers may easily join the project and create pull requests; I think this is even more critical than in a typical commercial project, where team members work together on regular basis and everyone has a good grasp of rules and conventions used in the project
  • contribution guidelines — an explicit statement of the approach to not only coding standards but also unit and integration test and others
  • clear code review comments — effective collaboration requires clear messages; due to potential time zone differences (and other reasons for which a voice call might be impossible) the asynchronous feedback must be provided (e.g. via review comments). The more precise and insightful it is, the better the outcome (as always, but this is especially true for a distributed team)
  • changelogs and version management — so that users and contributors can track changes and impact on their own code

I believe that a challenging environment is the best when striving for excellence in these areas.

Our recent activity

Here at Tratif, we are especially proud of the Specification Argument Resolver project which is an open-source extension for Spring Framework. It helps building fluent search endpoints for REST API. It was started in 2014, originally by a single developer as a pet project. Now, after 9 years, it has almost 30 contributors and is still actively developed. Over 500 stars, 130 forks and almost 900 usages reported on GitHub assure us that this work is appreciated by the community of developers worldwide.

During last month we made several improvements to this library. We also received a lot of contributions from volunteers. They include new features and important fixes, such as:

  • Spring cache support
  • Swagger/OpenAPI support!
  • JSON body parameters support
  • extended join support (join fetch aliases, better detection of redundant join clauses, better join management in count queries)
  • extended support of multiple date and datetime types
  • supporting Specification builder for testing mappings outside the web environment
  • several other fixes and improvements

We are very excited about the upcoming next big thing of this project: 3.0 release. It will bring Spring Boot 3 and Spring Native support. Stay tuned! And in the meantime… consider contributing to open-source project of your choice!

Leave a Reply

Your email address will not be published. Required fields are marked *