I've built two open source startups, totaling a decade of my life. Take it from me: the only way to do this sustainably is open core.
That means you make the core software open, but you sell the features that businesses will pay for or that allow other people to make money. Think of it as two distinct products for two distinct userbases.
In effect, the open source software becomes lead gen; the closed software is your actual business. They're both integral, and obviously feed into each other, but most of your open source users will never, ever be customers.
How do you handle contributions to the open core? Do you require a CLA?
I've been wondering about this for a project of mine. If one goes for an AGPL license but offers a commercial license for those that can't comply then a CLA is necessary from any contributors.
You absolutely do need a CLA.
Can you point me to your startups? I'm not entirely sure I understand how to implement this.
Not the OP and not the maintainer, but an open core example product that I love (and pay for at some companies) is MUI: https://mui.com/pricing/
They're a React UI framework with many free and some paid components.
Odoo is ERP/CRM software that comes to mind when open core is mentioned.
PS Also look into Cesium, they approached it in a smart way as well, by offering a web services tightly coupled wity, but optional from their open source product.
Their monetisation strategy is from cloud hosting and being a data provider, very different from open core.
Can you switch the licenses? I'm assuming since no consideration is exchanged, there's no contract, so you can change to a less permissive license.
Depends on the license: e.g. the GPL can't be revoked, so once something gets GPL'd it remains so forever.
No it doesn't. If you're the sole copyright holder of the code (e.g. it's a project you did by yourself), you can do what you want with it, including switching to a proprietary license. You can't retroactively un-GPL any copies that other people already have, of course, and it probably would look bad to take away older GPL versions from your GitHub page or wherever they're hosted, but you absolutely can make all new versions proprietary if you want.
> You can't retroactively un-GPL any copies that other people already have
That's what I meant when I said that you can't revoke the GPL. Of course with new versions you have more freedom, but what was relased under the GPL remains available under the GPL.
> but what was relased under the GPL remains available under the GPL.
Not necessarily. The copyright holder only has to provide source to those who got it from them under a GPL license. Others may not be able to get a copy, as those who can ask you for it aren’t obliged to give it to them on request (https://www.gnu.org/licenses/gpl-faq.html#CanIDemandACopy)
There also is the issue as to what happens when a license holder dies or is dissolved. I think that’s a gray area. Let’s say company Foo releases a product with a GPL license and later goes bankrupt. If Bar buys the source code from the bankrupt company, I don’t see how they would have to release it under the GPL, or should legally be obliged have to give the source code to those who got a license from Foo, and Foo can’t provide it anymore, as it doesn’t exist.
Similarly, if you only give (or sell) your GPL-licensed software to an individual who later dies, does their estate inherit the right to ask you for the source code?
>> > but what was relased under the GPL remains available under the GPL.
perhaps, in line with what you are saying, t would be better to express this as;
"but what was obtained under the GPL remains obtained under the GPL."
In other words, at a moment in time, a user can request the source of the (GPL) product they are using. They have rights and obligations for that code as it exists then.
It does not give them a right to any later versions of that code. And it does not allow the author to retroactively "deny" the rights they have.
One of the rights they have is to publish that code. (more accurately they can publish something based on the code, and hence by extension pass on the code to more users.)
Nothing says the original author as to keep the GPL version in any kind of public place. And the original author (assuming he has 100% copyright) can of course build on that code himself, and release the new code (or indeed the same code) under a different license.
>The copyright holder only has to provide source to those who got it from them under a GPL license. Others may not be able to get a copy, as those who can ask you for it aren’t obliged to give it to them on request
That's true, but if the software is at all widely distributed, then there's lots of people who have a copy theoretically, and any one of them could distribute their copy. So, in practice, once the cat is out of the bag, it's very hard to get it back in. But if the copyright holder changes the license (even on older versions) and no one still has a copy of those older GPL-licensed versions (or isn't willing to send a copy), then sure, in effect the copyright holder could retroactively un-GPL the whole thing.
You provided some interesting points. But now this discussion is going off-rails, as the potential issues you pointed at don't seem relevant in the case discussed here.
But only for existing code. If I am a developer and I release this code under GPL:
console.log("hello world")
And then I as the only contributor to the project releases the code and new changes under a new license:
console.log("hello world")
console.log("and space")
Then that code is under the new license. Yes, you can still use the first version under GPL license. But nothing stops me from granting a new license in addition to GPL. Remember GPL is only a license. It doesnt take away the underlying ownership to the IP. It becomes more problematic of course if the first version isnt 100% written by me. Then I would need any contributors permissions too.
Get an overview of the things they want changed and determine if it's something you have time for, or are willing to set aside time for. Can you deliver in a reasonable timeframe, for their definition of reasonable.
Assuming that's a go, then decide how it should be paid for. You have the option of time based (hourly/daily/weekly rates) payment, where you should charge the higher of what's normal for your area or the potential client's.
Or a project-based payment. If you're new to this, and it sounds like you are, I would stay away from this. Done right, you can make far more than time-based billing, but it takes experience to get it right.
Never forget: profitable businesses have money and expect to use it to get what they want. Despite what other comments say, it's exceptionally unlikely that they expect you to do it for free. They expect a bill that's at least a month of a developer's fully burdened salary.
After you've gone through this experience, you may have a better idea if it's something other businesses are likely to ask for. If so, make sure you indicate on the site that customizations are available.
Totally agree with this advice. The only caveat would be that there can be legal issues with charging money to work on a product that has specific licenses, whether or not you own it. You need to do some research (or maybe you could ask the company to do that research) to make sure you don't have to do some copyright wrangling to do this legally.
That's interesting. What licenses have you seen that prohibit charging for work on the associated product?
Don't know if it's what GP means but without a clear contract there's room for the paid work to be considered "work for hire" which means the company owns the change and OP wouldn't be able to incorporate it into the open source version of the project.
if the company uses the original product under a GPL license, then any changes they make (or pay the original developer (or anyone else) to make) have to be GPL too. the company would still own the copyright for that code, but it would be no different from any other contribution to the project.
if the company uses the product under a different license, then making the change public would have to be negotiated. a consideration for the company among others is that the company thinks that the change would be a competitive edge they would like to keep themselves (although most often that is an illusion, and the extra cost of maintaining that branch is not worth the advantage. this is something the developer needs to communicate)
if the nature of the changes make maintaining a separate branch difficult then i would make it clear up front that such a change can only be made if it is incorporated in the FOSS version of the product.
alternatively, i remember from the early days of zope, one of the project owners told me that they would offer companies a 10% discount if they would allow them to make the change public.
Only if they distribute the software.
that is technically correct, but what is distribution in the context of complex business relationships is not clear. even giving software to a contractor to work on could be considered distribution, so if the software is GPL then it is safer to just assume that any changes are going to have to be GPL too. if you do not want that then you better make sure you get the software under a license that does not risk your paid changes being under GPL.
Obviously the contract needs to specify the license.
Obviously. And yet these things are left un-/under-specified all the time.
I'll look into it. thanks a lot.
Great advice. Thank you very much.
I agree with some of the advice, but will offer a different take to give you something to think about.
For this single large company enquiry, don't worry about monetising the app yet. Having a single license sold is not really monetisation.
Think about it as a consulting gig on making changes to an OS project. The fact that you are the maintainer is a knowledge and familiarity advantage, not a control one.
Work out how much time it will take to make the changes, double it, and send them a quote. If they buy, make the changes, push an update, and invoice.
Take your time to decide how to monetise the product. For now, just get a good fee for your time. See if you fall back into the project before focussing too much on the business side.
I've built a few open source things in the past, a couple of which got popular. One was an open data project and it's just stayed the same (free API etc). Community look after it mostly.
Another was what became Certify The Web, which is now the most popular UI for automated certificate management on Windows and is most definitely now a commercial product (but 90% of users use the free version). I originally had a donate button and did get a couple of donations, maybe 4 or 5.
It was getting thousands of downloads per week and the company I was working for went into administration, so on the same day I added a Paypal button to the website for people to buy a license key and got my first sale later that evening. It's now had around 10K customers over 7 years and they renew their license key each year. Some people/companies do indeed want support and updates (I offer email support only, or there is a community forum). Nowadays most purchase via Stripe,
What did the license key gives in Certify The Web when you maintained it?
For a start, tell the company your hourly rate for custom changes; and see how bad they need them.
SaaS is typical, people like recurring
revenue. It really depends on what the project does. Can you share a link?
Look up COSS and Open Core to get an idea of how others have monetized.
I love the simplicity, but can't imagine a lot of scenarios where this gets used in the real world, just out of curiosity what are the use cases for this app?
In general its used by remote devs who need to share things like API keys, tokens, credentials and other sensitive or auth related code.
It's actually used a lot.
We're working to move away from managing sensitive credentials in this way. Mostly by removing humans from the process and handling.
If this is the primary use-case, I would emulate something like bitlocker and enterprisey features for $
That's a pretty basic service
I guess one way to monetize it would be to sell integrations with enterprise products (preferably only the ones which are already not free).
You could well make the integrations open source as well, just with a different license (I'd personally require payments only for businesses with more than x revenue).
Oh yeah I've seen variants of this concept, Safenote, comes to mind which expires based off X views or Y days, but nice to see an open source one like yours!
Recently started experimenting with Polar[^1] (OSS themselves). They offer a platform for OSS authors to sell perks (e.g. newsletter, digital assets, access to private repositories/discord, README ads) and handle billing/VAT for you.
Quite happy with the experience so far.
[^1]: https://polar.sh/
Nice work on your open-source project! I have seen serval effective ways to monetize via open-source project:
Community funding is a great starting point. Set up a GitHub Sponsors account or use platforms like Open Collective or Ko-fi. Many developers are happy to support projects they find useful. You can check the open source repo with Sponsors enabled.
I have seen a monetization case from a popular Chrome extension - I cant remember the extact name. While free for users, it displays sponsor logos in its GitHub repo and within the extension itself.
Finally, take inspiration from Tailwind CSS, which is a famous open source project. They offer Tailwind UI, a paid, advanced component library built on their free core framework.
From my personal experience, monetizing a SaaS project isn't easy, but it's certainly possible. However, establishing a steady income stream is a different case altogether.
Good luck! Look forward to hearing more your experiences from this!
From the FAQs of https://burnernote.com
"
How does this product make money?
It doesn't. Making money isn't the point of this product.
"
Usually the case that people set out with lofty ambitions of being above the money, but this changes when something gets popular.
Do consulting/contracting work for the large company with the stipulation the work stays open source.
I wouldn't recommend you start selling support tiers and you don't need to start selling a "product" here. Just give them a rate you're comfortable with.
Historically, Cygnus Solutions was very successful at this with custom development on the GNU toolchain.
https://en.wikipedia.org/wiki/Cygnus_Solutions
I don't know if there's something specific about compilers that makes this model work especially well. They would get paid to add specific features to the toolchain that customers wanted, and also to help the customers fix bugs or understand how to do what they wanted.
Hey I run a consultancy that helps solve exactly this kind of problem. Our main business is connecting open source freelancers with companies, but we've often see this use case where a company has a specific open source need and we help facilitate this. Let me know if you want to chat more - we could take over everything and we take a 10% cut. This is us: https://www.hydraoss.io/
Ensure that you’re either increasing someone’s revenue or decreasing their costs. In both cases, it should be possible to somehow convince people to pay you. How exactly is a bit of an art and requires some creativity but should be possible. For example if a company earns or saves 100k dollars per year from your software, it should not take much convincing to negotiate them giving you 1k-5k.
If companies and people already use it heavily it provides value.
Have you tried sending the large company a quote for how much you'd want to make the changes for them? They want you to do something, you're not free. It seems like the monetisation opportunity is staring at you in the face. It might not give you the constant, passive income stream you might be hoping for, though.
Do you want to work for the company asking for the changes? Because you have one potential customer. One prospect. And from what I see in the question, they haven't offered you a large pile of money to make the changes. The question reads they have asked you to work for free.
Where are you at in all this? Are you already a contractor with existing processes, relationships, and infrastructure for negotiating contracts, getting paid, and supporting large companies? Have you already paid the dumb tax beginning contractors pay for things learned the hard way?
How much money do you need to support the project long term? Does the person who asked for changes have a budget and the discretion to pay you? Good luck.
You want to request features? Great, pay me. You want support? Great, pay me.
Companies will almost never sponsor you if they get the product for free. We're using open source DBs, analytics tools, libraries, etc. and we're paying nothing for them.
How much do you make from 'Buy Me a Pizza'?
I have a small project that gets a few thousand hits per month, and get a few coffees every other month.
Offering paid support and custom work is also something I see often. I don't have personal experience with this though.