This post is about how a team or project can benefit from engaging with open source communities related to that project. There are countless, much better, and incredible resources out there on the topic, but I needed to organize my thoughts around it, and here’s the result.
Collaborating with the Experts
One thing I do when I want to go deep in a topic, is to go and contribute to a project related to what I want to learn. The core developers of such a library or project together have the expertise to have such a project up and running. That means if one starts contributing to those libraries, one will get reviewed by those people, and that’s extremely valuable.
If you continue to work on a project, and if the project is truly open and they’re happy to have new contributors on the project, that’ll get you eventually more involved and at some point your voice matters more and you can contribute to the general direction of the project. At some point you will work together with the other contributors and core developers on issues and projects inside this project which are important or more relevant to you.
All of that sounds really nice, but it may not be clear what exactly it brings to the team and company in which you work. For that, think of it from the talent acquisition perspective. Finding the experts of the field in whatever you do is usually not easy. And the more experts you have, the better the quality of the product you design. Now, if we could have access to a pool of experts in a topic and we could get their feedback and have them improve whatever we develop, it’d be pretty nice, wouldn’t it? Working on a relevant open source project can bring you exactly that. You can start working on a topic inside that project which is more relevant to your product/goals, and since those core developers and contributors care about what goes in the library, they’ll do their best to get your contribution to the best state to the best of their abilities. This in effect, means you have their direct engagement in something you need and you’re working on.
This usually, but not always, applies more in libraries which are closer to the edge of science and technology rather than the more established ones. There are other motivations for why contributing to the more established libraries is beneficial to your team/company in general.
To give you an example, as a part of our work on model cards at Zalando, we
need to work on a way to standardize the way we use fairness related metrics’
names across our teams. The fairness community in general is still evolving
around metrics and their names and use cases, and you can see several names
referring to the same metric, or a common name which doesn’t refer to any
specific metric at all. This happens to be something we also care about in
fairlearn (which is a library originally developed by people at Microsoft and
is now a community project), and therefore I’d work on it to be added to our
documentation on the
fairlearn side. This means I’d get the feedback of all
those experts in the field who contribute to the library, before my
contribution would be added to the documentation.
When you leave your bubble, whether that be your company or your team in academia, you realize how much brain-power is out there, and how effective working with people from all around the world in improving your work is!
This is somewhat related to the previous point. The innovation as a result of people with very different backgrounds working together is high quality and fast. Open source may seem quite slow if you look at an individual pull request or an issue, especially if you look at the more established projects, but even in those projects you have changes every once in a while which change the whole landscape. This is more pronounced in new and under development libraries especially if you manage to have quite a few people with very different interests and backgrounds onboard.
A couple of people living and working in the same city in the same environment, almost never can match the creativity coming out of a group of people who live in different continents, and work in different parts of the industry and academia.
It happens so very often that a solution which sounds pretty cool and creative is started in a company, but very soon the project will look and feel outdated and the new ones out there look much more attractive. Joining the forces with the work done outside your bubble, will keep you up to date and relevant.
People aren’t going to be attracted to your team unless they know what you do and they like it. If you work on something used by people who are your target audience, soon they’ll notice you and would like to work in a place which contributes to their beloved tools and ideas.
If I want to add a new member to my team, it’ll be much easier for me to go and say “hey, we need people, and we also work on XXX in case you were wondering”, rather than having to explain what exactly we do and how it’d be interesting to the potential candidates.
This is independent of whether you start your own open source project or if you contribute to an existing one, and each come with their own benefits and challenges.
This is on top of the open attractive culture you create once you work openly on projects. But bare in mind that the open source culture has many diversity and inclusion related issues and you need to actively work on them if you want a diverse set of people working around the project; it doesn’t happen on its own.
Sustainability of your Dependencies
If your project depends on something, you want that thing to stay up to date and under development. No matter how well developed a library is, if its development is stalled, it’ll be a risk to your operations.
There are many ways a company can support those dependencies, one is by sponsoring the project to make sure maintainers stay on the project, another one is to have employees contribute to the project and make sure it stays active.
The benefits of working with a community on open source projects aren’t necessarily obvious if you haven’t really worked with them in the past. I definitely wasn’t aware of all of this before I started being more engaged with a few communities, and I’m sure there’s still a ton for me to learn.
I would also like to emphasize how important the “community” aspect is. Having an open source library where you’re the only contributor doesn’t necessarily bring much. Most of what I talked about in this post are things you get out of the community, not just because you work on something which is open source. That also means you should be aware of the challenges of creating a community or working with one. For example, you can’t have a meeting behind closed doors and then create a pull request and change something in your library. You need to make sure anybody who comes to your repository/website, feels welcome and included in all discussions. It also means you actually need to take those inputs into account and keep them engaged.
Also, when engaging with an existing community, you should realize it takes a while for them to trust you and take you more seriously. You need to work on things they have agreed for a while, before you can start having a more substantial influence on the project.
All in all, I truly believe being engaged with those projects is worth the challenge and in the end you’ll benefit from it.