How to open-source in a closed-source environment
A case study about successfully working on an open-source package for a closed-source application
TL;DR
- ✅ Check if you are about to implement something generic that’s not unique to your business logic.
- ☝️ Suggest to your Product owner / customer to go open-source instead of adding it to your closed codebase.
- 🎉 Enjoy the benefits of using open-source and making the world a better place.
Setting the stage
It’s not a bold move to state that all modern IT wouldn’t exist in the way they do without open-source code. Many people spending their free-time working on stuff they give away for free. This concept seems perfectly reasonable to the IT crowd, but non-IT folk raise more than a few eyebrows to this fact.
One major issue is that companies use open-source to create closed-source software but don’t contribute back (enough). Sure, here and there, companies will invest time and energy in a package or donate money — but the overall amount of work they take out and the amount of work they contribute back, is heavily imbalanced. There are many talks addressing this issue, still nothing seems to change.
Reasons for closed-source
The other day, I talked to a senior software engineer. He told me that they implemented a package to bring dependency injection to the Django framework. It lives inside their monorepo and is used only by their main backend application. I asked why they didn’t bundle it up and released it as a package. The answer was simple: Nobody took the time since it wasn’t seen as something that would add value.
In fact, many projects or features could be implemented and licensed as open-source. Unfortunately, there are some things holding the involved actors back to do so:
- “It doesn’t add value, and it costs us money.”
- “I don’t know how open-source works” / “I don’t feel proficient enough to show my code to the world.”
- “We spent money building this, and now we won’t give it away for free.”
Changing the trajectory
A few months ago I was asked to find a solution for migration file conflicts in one of our Django projects. They were struggling with it due to cherry-picks and a somewhat delayed release cycle.
For reasons, I explained in my blog article, I decided to implement a pattern called “Migration Zero” instead of going with the built-in “squashmigrations” command.
Since this feature wasn’t related to the business logic and could help out other people as well, I suggested to the team to go open-source instead of adding it to our (closed) repo. I started pitching the idea to the product owner and briefed him about the consequences of this approach. After successfully selling it to him (see my arguments below), I got the team on-board, too — usually the easier part.
Instantly, it became clear that creating an open-source package was a wise decision for multiple reasons I’ll explain below. Even though I used them in my case, they are quite generic and should help the motivated developer to go open-source with the next suitable feature.
Separation of concerns
This feature hasn’t been related to the core logic of our application. Therefore, adding it to the codebase would clutter the repo and confuse newly onboarded developers.
Maintenance
From experience, I can tell that such dev-opsy solutions only used by one project will never be touched again if not utterly necessary. People are just happy that it works and that they don’t have to think about how it works.
Having the package at GitHub, other people can find it, contribute or just raise issues. Secondly, having a maintainer (me), they feel obliged to make it compatible with the latest Python and Django releases. In case, they don’t feel that way in the future: Maybe somebody else steps up and takes over. Anf if this doesn’t happen, it’s still not worse than having it unmaintained in their own codebase: The dev team needs to do the chores.
Proper documentation
Since we all know how important documentation is in open-source (“docs, or it didn’t happen”), I felt the need to give it more thought than I would have done in close-source. It helped me, not only to write more documentation, but also to learn how to write it in a better way. This will benefit the closed-source project directly in the long-run by improving the quality and therefore saving time and money in the future.
Building a more generic solution
If you build something just for your application, you tend to just go with the flow and make it work. This means you tailor the solution to your projects needs instead of having something more generic. If you ever start changing / refactoring your application, you mostly will have to change these things as well. Therefore, a more generic solution is the better one which will save you time and money in the long run.
Giving something back
Every application out there wouldn’t be existing if not for close-to-infinite hours of people working for open-source. Being on the idealistic side, this argument might not sell to every money-driven customer. Nevertheless, it’s a simple truth and it should be mentioned.
Conclusion
From my point of view, this case study shows neatly how you can contribute to the open-source ecosystem of your choice while working on regular internal / customer projects.
I believe that this line of argumentation sells quite well to the people giving the money because you don’t do “extra” work — you do what you would have done anyway. Just in a different repository.
I’d be glad to hear your thoughts about past experiences getting open-source contributions aligned with your day-to-day work — and if you manage to apply my approach in your projects, feel free to drop me a line and let me know how it worked out in the end.
