It is a while that I think about monetizing open source.<p>Honestly, I do not believe that companies will pay to use open source software when they can just download it.<p>Developers will prefer to just download instead of waiting for the legal department and the budget approval.<p>On the other hand, if it was simpler to just download the code/executable and then pay later, without any hassles from the legal department it could be the standard way to use Open Source.<p>However, there is still the problem of what to sell.<p>A great idea could be to distribute the executable when it applies, thinking about golang, C/C++, any compiled language.
For languages that are interpreter you could distribute the ruby gem, or the python egg or the JS packet.<p>Now if we combine this mechanism with some rate-limiting and price structure.<p>Stuff like:<p>* 10€ for one time download of the current version.<p>* 50€ for one time download of any version forever, when a new version comes out you can download it too.<p>* 10€/month for 30 downloads/months of the current version<p>* 50€/month for 30 downloads/months of any version<p>* 100€/month for unlimited downloads.<p>... and so on.<p>This could already provide several benefits, and be enough for several projects.<p>However we could also go a little forward.<p>We could provide an incentive to the buyers to buy the software and that incentives could be to do not distribute the building instruction or the dependencies list as open source.<p>Of course it will be possible to reverse-engineer the build instructions or the dependencies, however, it will be so time-consuming that any sane actor will prefer to just pay a little fee.<p>Finally, we could provide, under a restrictive license, the above-mentioned build instruction to whoever wants to contribute to the code base in a non-automatic way.
Just send an email, ask for them, explain what you are going to do, promise to do not use them to by-pass the above restriction and you are ready to go.<p>In this way:<p>1. We maintain most of the code open.<p>2. There will be incentives to just pay for open source.<p>3. There will be a trade-off between new contributors and time/resource the current maintainer will be able to support the project. (I don't believe that somebody willing to dive into the complexity of an open source project to add features will be scared off by contacting the maintainer, explain to him what he wants to add, maybe wait his feedback, and finally get the build instructions. Honestly, I see mostly benefits in this project)<p>I would love to hear feedback about this idea.<p>So please share your thoughts and if you are interested in trying something like that feel free to contact me via email :)