This going open source is just wonderful, but I have a feeling this is going to significantly decrease lower the company's revenue and ultimately hurt the product.
So here's my question: how do we avoid that? Outside of freelancers who control their finances directly, most developers probably won't be able to convince their company's money people to pay for something they can get for free. Paying a relatively low annual license can usually be justified for the sake of efficiency, but "donate to the devs to keep the project going" is a much tougher sell.
My only idea is selling a "subscription" to signed binary builds under a non-free license, but I'm not sure that would work very well either...
So far, with far fewer users, the paid tier is a _dramatically_ more effective option: it makes nearly $1000 a month, and increasing, while donations make $50 a month. The latter library is a small package, but it is a small package that's installed 6 million times a week, so there's a huge volume of software depending on this. The former app has a few thousand monthly users but similarly isn't something that your whole business is typically going to revolve around, it's just a useful tool.
Imo, unless you're huge or you're going to become a really fundamental part of people's business, donations aren't going to work. Small libraries or occasional-use tools just won't get there. If you're webpack it's great, and I do think it's super valuable for those cases, but most projects aren't webpack.
However for almost any tool you can separate the power user/enterprise features from the basic features, and then put the former behind a simple paywall. It can remain open source, so the determined can fork the whole project and remove the paywall easily if they prefer, but for any large organisation that doesn't really make sense from a time or ongoing cost perspective, and you either miss out on all future development, or you have constant work to merge upstream changes with yours. Alternatively, you pay $10 a month and the problem goes away.
So far so good, and it feels like a win-win. Hard to translate to libraries I think, but there's interesting developments here like https://gitroyalty.com/.
It sounded to me like they weren't able to get enough revenue going for their work, and are basically throwing in the towel.
To me, it sounded as if they're hoping that their audience increases to a degree that the donations will finally be able to make their livelihood sustainable... Or not, which will make this a side gig
> It sounded to me like they weren't able to get enough revenue going for their work, and are basically throwing in the towel.
I sort-of agree. I don't think they're throwing in the towel completely, but clearly their current model isn't working, and they need to try something else, and they know that that might not work either.
Nonetheless: they want an alternative model that might make this sustainable, and I suspect they'd have better luck trying an open-source with a paid tier model, rather than pure donations.
I've never used the Sourcetrail, but I suspect there are some simpler and more advanced features involved. They could open source it as here, but put the advanced features behind a simple paywall. That would still give the benefits of open sourcing (more community engagement, wider usage of the tool itself) whilst being far more likely to drive the heavy/enterprise users to actually pay for it. Asking people nicely for donations is much less effective than asking for money to use a valuable feature.
So here's my question: how do we avoid that? Outside of freelancers who control their finances directly, most developers probably won't be able to convince their company's money people to pay for something they can get for free. Paying a relatively low annual license can usually be justified for the sake of efficiency, but "donate to the devs to keep the project going" is a much tougher sell.
My only idea is selling a "subscription" to signed binary builds under a non-free license, but I'm not sure that would work very well either...