What's the missing puzzle piece that improves the open source projects used in the services or products you deliver to customers to bring you profit? Read on to find out |
Over the years I have created some open source projects. In fact, I have created a lot of open source projects. Some of them are seeing very little real-world use but many of them are used by hobbyists and academic institutions and powering companies of all sizes.
Altogether with all these projects I get a lot of bug reports, suggestions, feature requests, questions and so on. In fact, I get a lot more than I could possibly handle. This naturally means that some of them receive less attention, which can of course be very frustrating. But there is actually one simple thing you could do and I would like to offer this one solid advice on how to get my attention for your particular concern. Are you ready? It's actually quite easy. Ok, here it comes. Pay for it!
Now I can hear annoyed mumbling from some of you (*mumble* *mumble* paying?!? *mumble* *open source* *mumble* *mumble* should be free! *mumble* *mumble*) and I also think there's a lot of you who think this is pretty obvious.
The reason why I'm being very explicit about this is not that I'm angry or disappointed with someone or desperate for money, but over the years I have come to understand that a surprisingly large amount of people and companies just never have thought about this possibility. So I think it's good to make a very simple distinction here. The code is free. My time certainly is not.
That's right. The missing puzzle piece is money. You probably shouldn't pay me to do graphical design though. |
Now don't get me wrong. I'm not threatening to kill an open source project every hour until I get a million in unmarked bills and a fueled airplane waiting for me. In fact, I will work on these projects regardless, because I want them to be useful for myself and others, and I really appreciate all bug reports and questions being sent, but if the choice is between getting paid to work on some feature or do it on my spare time, then it's a pretty easy choice to be made. And this is happening already today. I have happy customers who are paying me and my colleagues to work on some of these projects.
And conversely, when I'm working on some project that could benefit from support or a feature addition in an external open source project, I try to enlist the leader of that project when I have the chance. I find it tends to be great value for the money being able to get support from someone who knows every nook and cranny of a particular piece of software and can implement or suggest and desired changes. In fact, it's not just me saying this. A large-scale EU study released in 2021 concluded that the benefit-cost ratio of investing in open source software was above 4, so I say that's a pretty good way to spend your money.
So how does this work in practice? Well, just like any other contract work really. We define the scope, probably sign some NDAs, agree on a fixed price or a T&M setup, shake hands and get to work. Does the finished work product need to be open sourced as well? That's up to you as the customer. For any code that is generally useful, I would typically recommend integrating it back to the open source project where it came from because that saves you from being the only maintainer of that piece of code. But there might also be code that is closely tied to your proprietary work and in that case it's likely best that you keep it to yourself. Most often it's a mix of both and relatively straight-forward to decide what goes where.
And it really doesn't just have to be programming. Most of my projects work perfectly fine as they are, but perhaps you need some training to learn how to use them most efficiently, and I'm happy to supply that as well.
So, this one was a bit shorter than my typically long-winded posts, but I wanted to keep it short and snazzy because time is money, you know.