> I re-designed the UI of the app to look more professional and implemented a license key system. From that moment if you wanted to use EmailEngine (the new name for IMAP API), you needed a license key that was only available for paying subscribers. I also changed the license from LGPL to a commercial license. The source code is still published publicly on GitHub. It is no longer open-source by definition but source-available. This change of license was only possible due to requiring outside committers to sign a CLA from the start.
This is the key portion. The open source project was turned into a commercial source available library with a license key.
I am glad this has worked well for the developer who now has a decent income for all the hard work put into this library.
It's a sad irony that CLAs essentially put the project owner in the exact same position as the unicorn that screwed them over, by screwing over those downstream who make contributions, if/when they monetize the project.
I came across some Scheme/Racket/? library recently that attempts to quantify contribution levels and distribute any received funds fairly based on that. Unfortunately, I can't find it at the moment, but it was a cool idea.
You mean I screwed over those 0.1% of commits in EmailEngine (because the other 0.1% is from the Github Actions bot writing the changelog)? Everything else is my own code.
For over 14 years, I've been actively developing Nodemailer, a hugely popular project. There has been no CLA in place, and the main outside commits I get are typo fixes during Hacktoberfest. This is why I'm still the owner of 98% of the committed code in Nodemailer. Usually, if I do not fix or build something, no one else will either.
I'm not picking on you, FOSS projects aren't really set up for anything like shared revenue yet, and almost nobody's thinking about it.
But in the future, monetized FOSS projects need to pay out to their contributors. By default, contributors own copyright to the code they share, and forcing them to surrender that for free won't be acceptable.
The problem for the developer considering a CLA is that if you take any contributions at all, you now have a community of people who A) understand your source code and B) have had their contributions rolled into your proprietary product, possibly against their expectations and possibly leaving them rather upset.
With 0.1% of commits it's not a likely problem, but if developers are making significant contributions then there's a good chance they'll fork your product as of the last LGPL commit and keep developing it as a direct competitor. It's safer to just not take contributions at all.
I would not say that in your case, but the problem is that if a project has a CLA there could be a lot of commits from other people and then it would be screwing them over.
> You mean I screwed over those 0.1% of commits in EmailEngine (because the other 0.1% is from the Github Actions bot writing the changelog)?
I mean... yeah? Correct me if I'm wrong but you profited off their labor without compensating them, right? Why should the number of people you did that to make it less wrong? Obviously a corpo making bajillions of dollars without paying you sucks, but by sheer number of people negatively affected, it's still the same lol, in this case you're just the one with the bag, instead of a corporation.
Well, I guess you're right in a way. While there are no meaningful outside commits in EmailEngine, there are _some_ commits, even if these have minimal impact, by people who do not get paid for it, while I do.
I'm not judging you for this, btw. I find it extremely difficult to meaningfully measure in a dollar amount someone's contribution to a FOSS project, once monetized. The whole thing is messy. Honestly in general I find it quite difficult to measure labor value at all, which is why I guess basically every corporation on earth just lets "the market" decide, but that feels too arbitrary to me, and "the market" doesn't seem real when it gets to arbitrarily pay someone differently based on whether their passport says "India" or "USA."
I've been experimenting with just throwing my hands up and doing flat profit share, but we haven't really had an opportunity to really try this at scale (for a bunch of boring reasons), but I'm curious how it'll look. I don't think we'll have the crazy huge ratios you do on your FOSS though so I can see why that wouldn't be feasible for someone in your position.
> I am glad this has worked well for the developer who now has a decent income for all the hard work put into this library.
Isn't this a rug-pull?
Open source project which others havecontributed to, and whose reputation was earned by nature of being open source.
Than, after you have users, switch to proprietary. Sounds bad to me, but maybe I didn't fully understand?
BTW, Apple used to have a thing with Darwin server where you could disable the license check legally, but only a hacker would do that. Companies still paid for the software. That sounds like a better solution, IMO - at least for those that are two small to pay but growing by the seat of their pants can still use and promote the software.
The main reason CLAs exist is to facilitate this kind of "rug pull", so I think the lesson is to either accept that it will happen or never sign a CLA.
Most EmailEngine's customers are small-ish SaaS providers (different kinds of niche CRMs, etc), and in their position, it is not really an option to spend time / risk breaking copyright protections. Instead, they pay the subscription fee and get into building email integration features for their service.
TBH, I wouldn't dare to use such a model in the B2C market, though. Everyone would pirate it.
For niche applications, it's not that terrible. I've produced an SQL IDE for years with a license key that sold <=100 individual purchases per year. I've only spoken to one person I believed pirated it. I've now went the opposite direction and made it free.
Probably fear that this is the kind of red flag that would show up in due diligence, and that having piracy as part of the foundation of the tech stack that you build your business on is not a worthwhile risk to take.
- you get support by paying, this is important for many businesses - $1k/year is cheap
- risk of getting sued if the word gets out you're using something against its license (and for network-facing code, I'd suspect it's easy enough to miss something)
For me the advantage of source-available is you can always shortcut the support if there's a business critical problem and you can't wait for the author to wake up, so I think it's a great model.
I'm curious how much time a solo dev spends on support for a project like this. I can imagine some companies asking for a tremendous amount of support, or even trying to somehow get free consultation on adjacent concerns that aren't totally related to the product. Maybe it's just a matter of setting clear boundaries and limiting time?
I do support once a day for about an hour. I do monitor notifications for support emails during the day to react faster for urgent issues but there rarely is anything urgent. I guess the self-hosting side keeps support demand lower - if you are already capable of installing and running that software you can probably figure most of your issues out yourself.
This is the key portion. The open source project was turned into a commercial source available library with a license key.
I am glad this has worked well for the developer who now has a decent income for all the hard work put into this library.