I was contacted by a large company last week asking for changes to be made. This prompted me to go check the DB, analytics etc and I see its being used a lot.
I've (as of today) stuck a sponsorship link on it. Any suggestions as to how else I can monetise?
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.
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.
They're a React UI framework with many free and some paid components.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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,
Look up COSS and Open Core to get an idea of how others have monetized.
It's actually used a lot.
If this is the primary use-case, I would emulate something like bitlocker and enterprisey features for $
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).
⁽¹⁾ https://github.com/jhaals/yopass
[^1]: https://polar.sh/
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!
" 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.
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.
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.
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.
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.
I have a small project that gets a few thousand hits per month, and get a few coffees every other month.