Ask HN: Is it foolish to open source your SAAS business source code?
66 comments
Sidekiq (http://sidekiq.org/), a Rails job queueing system, works on related model: open core, paid subscription if you want to host a version with all the commercial bells-and-whistles plus get support. The author does well for himself, deservedly.
I'd consider shipping a bare bones version of the back-end under MIT, letting people spend their own two weeks getting one ready if they want to have it more useful in production, or give them the option of paying $500 per year for your back-end. That's an easy, easy call for a lot of companies to make.
Just to set expectations: just OSSing your thing is not going to cause the world to beat a path to your door. You're going to have to go bang down doors to get this adopted, whether it is 100% free, 100% paid, or some combination of the two. Unless you put in the marketing and "sales" work, you will probably build no community, receive no buzz, acquire no press mentions, and get no meaningful support from other developers. Be ready for this, because three months from throwing most projects on Github you can expect a deafening cacophony of absolutely nothing at all unless you find the people it solves a problem for and, with the best of intentions, shove it down their throats.
I'd consider shipping a bare bones version of the back-end under MIT, letting people spend their own two weeks getting one ready if they want to have it more useful in production, or give them the option of paying $500 per year for your back-end. That's an easy, easy call for a lot of companies to make.
Just to set expectations: just OSSing your thing is not going to cause the world to beat a path to your door. You're going to have to go bang down doors to get this adopted, whether it is 100% free, 100% paid, or some combination of the two. Unless you put in the marketing and "sales" work, you will probably build no community, receive no buzz, acquire no press mentions, and get no meaningful support from other developers. Be ready for this, because three months from throwing most projects on Github you can expect a deafening cacophony of absolutely nothing at all unless you find the people it solves a problem for and, with the best of intentions, shove it down their throats.
We did exactly this with ShareLaTeX.com (https://github.com/sharelatex) we are a bootstrapped SASS business that started a couple of years ago and now supports 3 people full time.
We have open sourced 95% of our code, which gives people a really great product they can install on their own servers. Along with our hosted version, we have a premium self hosted version with a few things that only the big users would want. I would not personally want to build my business around support/contracts as it is really pretty close to being a contractor.
We were already an established company before we open sourced so I can not speak for how many users it got us. I don't think its foolish todo but at the same time it is not going to make your business.
Be aware open sourcing will add extra burden to everything you do. But starting open source is going to be easier than doing it retrospectively.
discourse.org started life open source and they are doing very well but have some big hitters and finance.
We have open sourced 95% of our code, which gives people a really great product they can install on their own servers. Along with our hosted version, we have a premium self hosted version with a few things that only the big users would want. I would not personally want to build my business around support/contracts as it is really pretty close to being a contractor.
We were already an established company before we open sourced so I can not speak for how many users it got us. I don't think its foolish todo but at the same time it is not going to make your business.
Be aware open sourcing will add extra burden to everything you do. But starting open source is going to be easier than doing it retrospectively.
discourse.org started life open source and they are doing very well but have some big hitters and finance.
ShareLaTeX is awesome - thanks for creating such a cool service.
I'm interested to hear more of the story.
How long did it take to start making money?
Do many people download and install?
Have you ever felt concerned you'd be forked by competition?
Where does the income come from primarily?
How long did it take to start making money?
Do many people download and install?
Have you ever felt concerned you'd be forked by competition?
Where does the income come from primarily?
We didn't start charging until we had been live for about 10 months, this is where it went from a cool side project to realising that we had something here. Once we started charging we were making a tiny amount of money straight away because we already had a lot of users.
A lot of people do run their own versions, these are generally universities who do not want their data going to 3rd parties. Its impossible for us to get exact numbers on it though.
We were worried about other people stealing our code, some other people do run our site however your self hosted version is always going to be best, it will have all the SEO, more users, get the updates quickest.
Most of our income is via self hosted.
A lot of people do run their own versions, these are generally universities who do not want their data going to 3rd parties. Its impossible for us to get exact numbers on it though.
We were worried about other people stealing our code, some other people do run our site however your self hosted version is always going to be best, it will have all the SEO, more users, get the updates quickest.
Most of our income is via self hosted.
Do you have any qualms about having the name of the open source project in your company name?
How did the LaTeX project owner feel about the project name being in your company name? Did it ever come up?
How did the LaTeX project owner feel about the project name being in your company name? Did it ever come up?
How does open source add extra burden to everything?
If we want to change things we have to think about what effect it will have on everyone else. Backwards compatibility becomes a bigger issue. People run ShareLaTeX in all sorts of different setups and environments which our changes can conflict with.
I'm as well currently thinking about open-sourcing components of my web application. "Open sourcing" comes in many flavors, and the one I'm mostly favoring right now (for one of my particular components) is a dual license, "GNU AGPLv3 / commercial" combination.
https://en.wikipedia.org/wiki/Affero_General_Public_License
Metafizzy's Isotope goes a very similar dual-licensing way: http://isotope.metafizzy.co/license.html
Isotope's author has written about how commercial support has worked for him in his particular context, search for "support" on his blog archive: http://metafizzy.co/blog/archive.html
While an MIT and BSD license is (among other things) good for monetizing on consultancy (... not easy for a one-person project), a GPL-including multi-license may additionally allow to monetize on third party modifications of a software component (... that's way easier for a one-person project).
If someone sees a fallacy or gotcha in my monetization reasoning, please comment.
https://en.wikipedia.org/wiki/Affero_General_Public_License
Metafizzy's Isotope goes a very similar dual-licensing way: http://isotope.metafizzy.co/license.html
Isotope's author has written about how commercial support has worked for him in his particular context, search for "support" on his blog archive: http://metafizzy.co/blog/archive.html
While an MIT and BSD license is (among other things) good for monetizing on consultancy (... not easy for a one-person project), a GPL-including multi-license may additionally allow to monetize on third party modifications of a software component (... that's way easier for a one-person project).
If someone sees a fallacy or gotcha in my monetization reasoning, please comment.
One problem with dual-licensing though is that open source contribution becomes unnecessarily hard. Every contributor will have to sign a Contributor License Agreement, that at the very least allows you to dual-license their code. Many CLAs even have the contributor sign over her copyright to you.
Not everyone will be happy to sign something like that. And integrating a pull request on github suddenly becomes a tedious excercise in international copyright law :)
So dual-licensing gives you all the publicity-related and try-before-you-buy advantages of open source. But you will probably miss out on other great aspects, especially community-wise.
Not everyone will be happy to sign something like that. And integrating a pull request on github suddenly becomes a tedious excercise in international copyright law :)
So dual-licensing gives you all the publicity-related and try-before-you-buy advantages of open source. But you will probably miss out on other great aspects, especially community-wise.
It's prudent to have a CLA anyhow. Even if a whole project were AGPL, an employer of some contributor could claim ownership and IP theft.
And the right to fork a project also means the right to put conditions on accepting contributions.
And there are more advantages than publicity and free demo, namely that users have freedom to run the app themselves, find another service provider, find another project maintainer, etc. I'd see it as a far less risky situation than anything proprietary. Compared to Apache/BSD/MIT it's less risky in the sense that people aren't going to be introducing proprietary forks.
And the right to fork a project also means the right to put conditions on accepting contributions.
And there are more advantages than publicity and free demo, namely that users have freedom to run the app themselves, find another service provider, find another project maintainer, etc. I'd see it as a far less risky situation than anything proprietary. Compared to Apache/BSD/MIT it's less risky in the sense that people aren't going to be introducing proprietary forks.
Another approach is to dispense with CLAs and copyright assignment, and let the community edition diverge from what you run for your paid service.
If you do that, you can't incorporate improvements from the community edition back into your code by simply copying them, but you can use them for inspiration to guide your parallel development for the paid version. That's more work than simple copying, but less work than developing new features from scratch.
If you do that, you can't incorporate improvements from the community edition back into your code by simply copying them, but you can use them for inspiration to guide your parallel development for the paid version. That's more work than simple copying, but less work than developing new features from scratch.
This is a problem for all those 0.1% of FLOSS projects which actually get contributions. If yours are one of those, then donations or grants is something to look into in favor of dual-licenses.
Could that be fixed by having a technical architecture that supported additional functionality by plugins? So the core product is dual licensed and contributions are done as plugins that can be licensed separately?
Doesn't Affero turn people off?
Affero means you really can't work with the code in any effective way cause anything it touches becomes Affero.
Personally I found Affero repellent when considering which open source software to download and install.
Affero means you really can't work with the code in any effective way cause anything it touches becomes Affero.
Personally I found Affero repellent when considering which open source software to download and install.
I am not a lawyer, but as long as someone uses a AGPL-licensed software stand-alone, I don't see a reason for that Someone to be turned off. Many AGPL-licensed components/applications run standalone and don't have caused trouble for their users, e.g. MongoDB users (also see https://en.wikipedia.org/wiki/List_of_AGPL_web_applications ).
At the moment someone starts editing/working on the code, he/she does so with a reason, either commercial or non-commercial in nature.
So you, as the copyright holder, could license your software under the following conditions:
"If you use our software commercially, then you have to pay for it by purchasing a commercial license.
If you use our software non-commercially, then you may use it under the terms of AGPL.
For private, evaluation, and research purposes possibly leading to a commercial use, you can evaluate, use, and modify our software up until the point where you decide to publicly use it in a commercial or non-commercial way. At that point you will have to decide on either of the two aforementioned licensing options."
At the moment someone starts editing/working on the code, he/she does so with a reason, either commercial or non-commercial in nature.
So you, as the copyright holder, could license your software under the following conditions:
"If you use our software commercially, then you have to pay for it by purchasing a commercial license.
If you use our software non-commercially, then you may use it under the terms of AGPL.
For private, evaluation, and research purposes possibly leading to a commercial use, you can evaluate, use, and modify our software up until the point where you decide to publicly use it in a commercial or non-commercial way. At that point you will have to decide on either of the two aforementioned licensing options."
MongoDB made an explicit exception to AGPL. Normally a driver wrapping an AGPL database would have to be AGPL too. In turn every app using the driver would be AGPL. But Mongo, as owners of the driver and DB, made an exception for users.
The only situation where AGPL wouldn't affect other components is where you're using industry wide standard APIs. E.g., I can use Firefox to connect to an AGPL website, but that doesn't make Firefox AGPL. This is what Stallman is getting at when he talks about intimacy of API communication. He points to a simple call to main as an example that's not intimate communication and thus has no licensing consequences.
Also you can't say "we license this as AGPL for non-commercial use". That violates the rights of the user to not have additional restrictions placed on the AGPL. And if you think through the practicalities of how that would work, it's not feasible anyhow.
Edit to add: AGPL does not prevent private modification of code. Your are required to license the code as AGPL and distribute the AGPL licensed project to users, but if the user is just you, there's no practical effect. However, once you start sharing it internally in a company, it's a giant grey area especially if you have contractors or any non-employee ever access your infrastructure. Employees might also be able to claim they are entitled to an AGPL copy of it. The only thing that's allowed internally is having someone "make modifications exclusively for you, or provide you with facilities for running those works", which would be effective for a trial or POC. Essentially you should either plan to abide by the AGPL or plan on buying the dual license at some point (the license allows violations to be fixed within 30 days).
(This post is for entertainment purposes. I am not a lawayer, and this is not advice.)
The only situation where AGPL wouldn't affect other components is where you're using industry wide standard APIs. E.g., I can use Firefox to connect to an AGPL website, but that doesn't make Firefox AGPL. This is what Stallman is getting at when he talks about intimacy of API communication. He points to a simple call to main as an example that's not intimate communication and thus has no licensing consequences.
Also you can't say "we license this as AGPL for non-commercial use". That violates the rights of the user to not have additional restrictions placed on the AGPL. And if you think through the practicalities of how that would work, it's not feasible anyhow.
Edit to add: AGPL does not prevent private modification of code. Your are required to license the code as AGPL and distribute the AGPL licensed project to users, but if the user is just you, there's no practical effect. However, once you start sharing it internally in a company, it's a giant grey area especially if you have contractors or any non-employee ever access your infrastructure. Employees might also be able to claim they are entitled to an AGPL copy of it. The only thing that's allowed internally is having someone "make modifications exclusively for you, or provide you with facilities for running those works", which would be effective for a trial or POC. Essentially you should either plan to abide by the AGPL or plan on buying the dual license at some point (the license allows violations to be fixed within 30 days).
(This post is for entertainment purposes. I am not a lawayer, and this is not advice.)
> Also you can't say "we license this as AGPL for non-commercial use". That violates the rights of the user to not have additional restrictions placed on the AGPL. And if you think through the practicalities of how that would work, it's not feasible anyhow.
Are you referencing "further restrictions" in AGPLv3's "additional terms"? http://www.gnu.org/licenses/agpl-3.0.html#section7
Good point! (Maybe) to fix this problems, for dual licensing with a non-commercial AGPLv3-like tier and a commercial tier, we would require a "modified AGPLv3" on the non-commercial tier. That "modified AGPLv3" would explicitly prohibit commercial use.
There is a Stack Overflow question asking on how to prohibit commercial use: http://stackoverflow.com/q/3485750/923560
Are you referencing "further restrictions" in AGPLv3's "additional terms"? http://www.gnu.org/licenses/agpl-3.0.html#section7
Good point! (Maybe) to fix this problems, for dual licensing with a non-commercial AGPLv3-like tier and a commercial tier, we would require a "modified AGPLv3" on the non-commercial tier. That "modified AGPLv3" would explicitly prohibit commercial use.
There is a Stack Overflow question asking on how to prohibit commercial use: http://stackoverflow.com/q/3485750/923560
Yes, I was referring to that section. Eventually restrictions on commercial use completely nullifies the AGPL... no one ends up with anything that's AGPL in the end.
Your alternative approach here would work. Maybe specifically a tri-license: non-commercial, commercial, and plain AGPL. For non-commercial licenses, this list mentions some: https://www.gnu.org/licenses/license-list.html
Also consider that the AGPL strongly discourages modifications directly to it. The proper way to "modify" it is by adding extra permissions. Those permissions can come with strings attached (from the original developer only), but any user should be able to discard those terms and choose the original AGPL instead. So instead of dual or tri-licensing you could add permissions that say, you can bypass requirements X, Y, and Z of the AGPL but only if either: (1) you use this non-commercially or (2) you buy a license. But in that event you basically can't have either one of those people sharing their code or it pollutes everything and might destroy the original project. Meaning, not only could a project be forked, but forked as many wildly different and incompatible licenses with the original author having no control of it.
Your alternative approach here would work. Maybe specifically a tri-license: non-commercial, commercial, and plain AGPL. For non-commercial licenses, this list mentions some: https://www.gnu.org/licenses/license-list.html
Also consider that the AGPL strongly discourages modifications directly to it. The proper way to "modify" it is by adding extra permissions. Those permissions can come with strings attached (from the original developer only), but any user should be able to discard those terms and choose the original AGPL instead. So instead of dual or tri-licensing you could add permissions that say, you can bypass requirements X, Y, and Z of the AGPL but only if either: (1) you use this non-commercially or (2) you buy a license. But in that event you basically can't have either one of those people sharing their code or it pollutes everything and might destroy the original project. Meaning, not only could a project be forked, but forked as many wildly different and incompatible licenses with the original author having no control of it.
In some situations, that's exactly the point. When I want a license that everyone can use without thinking twice, including you, I take MIT/BSD. When I want people to consider their position on software freedom before they use my software, I use AGPL.
Perhaps other people don't use it that way, but for me: yes, Affero turns some people off. That's why I use it. To remind people: Hey, there is a world of aggressively free(dom) software where many people are happy. Why not join us?
No hard feelings, of course. I love MIT/BSD and use it in almost all my projects.
Perhaps other people don't use it that way, but for me: yes, Affero turns some people off. That's why I use it. To remind people: Hey, there is a world of aggressively free(dom) software where many people are happy. Why not join us?
No hard feelings, of course. I love MIT/BSD and use it in almost all my projects.
Well, isn't the point to turn competitors off? If one is a die-hard Free Software advocate, you have no problem with Affero. If you want to set up a fork, then you might have a problem.
If you refuses to download and install software because of personal believes in license, I wish you good luck. Its hard to do on a personal level, and RMS has got a lot of heat for documenting about it.
I've been asking myself the same question.
The conclusion I'm leaning towards is that the Saas version should, on top of the hosting/maintenance, offer some distinctive features ( it depends of your product, but on an Saas model, your architecture can be more complex than a Backend/Frontend/DB architecture, thus allowing more advanced features ).
In my view there is three layers, that could be seen as three steps ( but maybe I'm wrong ) : open source ( great for WOM if well managed, great to harden the software ), enterprise-behind-the-firewall license to make recurring revenue and build a sales pipeline, Saas once the architecture is stable enough to handle hundreds/thousands of customers with acceptable costs of operations.
Someone can take your code and set up in competition to you using the OSS version, just changing the logo. But the software is at the end only 30% of a company. What makes a great company is how it evolves with its market to serve and nurture better its customers. Economy is not about selling products, it's about exchange between humans. The real product is in the experience ( the software, the tone, the customer service, the email, the documentation, the ads... every little byte, pixel, sound that your company emits ). A company that steals your OSS and monetize on it without making it a new experience is just like a guy around the corner selling Rolex replicas.
The conclusion I'm leaning towards is that the Saas version should, on top of the hosting/maintenance, offer some distinctive features ( it depends of your product, but on an Saas model, your architecture can be more complex than a Backend/Frontend/DB architecture, thus allowing more advanced features ).
In my view there is three layers, that could be seen as three steps ( but maybe I'm wrong ) : open source ( great for WOM if well managed, great to harden the software ), enterprise-behind-the-firewall license to make recurring revenue and build a sales pipeline, Saas once the architecture is stable enough to handle hundreds/thousands of customers with acceptable costs of operations.
Someone can take your code and set up in competition to you using the OSS version, just changing the logo. But the software is at the end only 30% of a company. What makes a great company is how it evolves with its market to serve and nurture better its customers. Economy is not about selling products, it's about exchange between humans. The real product is in the experience ( the software, the tone, the customer service, the email, the documentation, the ads... every little byte, pixel, sound that your company emits ). A company that steals your OSS and monetize on it without making it a new experience is just like a guy around the corner selling Rolex replicas.
And let's be clear - you can open source license it however you want. So you can, in fact, allow corporations to run their own installs while still disallowing those companies from reselling the software.
disallowing those companies from reselling the software.
No licence that is recognised as open source/free software by the Open Source Initiative, the Free Software Foundation, or the Debian Project, etc would allow that restriction.
You would have to write your own licence for that, and you may call it "open source" if you like, but that would be misleading and you'd almost certainly get called out for it.
No licence that is recognised as open source/free software by the Open Source Initiative, the Free Software Foundation, or the Debian Project, etc would allow that restriction.
You would have to write your own licence for that, and you may call it "open source" if you like, but that would be misleading and you'd almost certainly get called out for it.
Anyone that wants to "call you out" for making source code available, for free, to what was a closed-source application is petty at best.
I get the pedantic nature of calling it "open source," but the idea that OP has to not only make the source available, but also allow others to resell it in order to be a good citizen in the OS community is disappointing to me.
Your point is well taken, I just find it unfortunate that people think this way.
I get the pedantic nature of calling it "open source," but the idea that OP has to not only make the source available, but also allow others to resell it in order to be a good citizen in the OS community is disappointing to me.
Your point is well taken, I just find it unfortunate that people think this way.
There is a huge difference between an "open source" code and an "available" code. The whole point of open source is that you can reuse, modify and redistribute the modification on the code, so that the community's knowledge in the domain can be globally increased. It's all about improving the way we work as a community.
Now, of course, I am free to not want anyone to reuse my code, even if it's publically available. That is just not Open Source.
To be clear on the "calling you out", it's not about calling you out because you made your code available only instead of full OSS, it's about calling you out because you made your code available only and you pretended it's OSS. That is just a lie and calling you out on this is perfectly justifiable.
Now, of course, I am free to not want anyone to reuse my code, even if it's publically available. That is just not Open Source.
To be clear on the "calling you out", it's not about calling you out because you made your code available only instead of full OSS, it's about calling you out because you made your code available only and you pretended it's OSS. That is just a lie and calling you out on this is perfectly justifiable.
but the idea that OP has to not only make the source available, but also allow others to resell it in order to be a good citizen in the OS community is disappointing to me.
Why? The "freedom to redistribute" stuff has been part of the essence of the "open source" movement about as long as it's had a name, and is also part of the fundamentals of the "free software" ideology as well. Making "source available but you can't resell / redistribute" has pretty much always been seen as occupying a weird "not quite completely commercial, not quite open source" space. I think most people use the term "shared source" for that.
Of course, doing "shared source" instead of "open source" doesn't make someone a bad person or anything. But I think it's important to be accurate in how we refer to things, as this distinction really does matter.
Why? The "freedom to redistribute" stuff has been part of the essence of the "open source" movement about as long as it's had a name, and is also part of the fundamentals of the "free software" ideology as well. Making "source available but you can't resell / redistribute" has pretty much always been seen as occupying a weird "not quite completely commercial, not quite open source" space. I think most people use the term "shared source" for that.
Of course, doing "shared source" instead of "open source" doesn't make someone a bad person or anything. But I think it's important to be accurate in how we refer to things, as this distinction really does matter.
You can license it that way, yes. It wouldn't be considered open source as defined by the OSI[1], though, so some people might feel it's somewhat deceitful to call it so; I would.
[1] http://opensource.org/
[1] http://opensource.org/
That is one of those "free as in beer, not as in freedom" strategies. :)
Is there a well-known license that has that baked in?
And if they are better at you at the experience side?
Sentry is both SAAS[1] and open source[2], but has an interesting history.
It was originally started as an internal tool at Disqus[3]. Its developers were able to open-source it, and spin it off into a side business. The developers then moved on from Disqus to other companies but kept getsentry.com running till it was profitable enough them to go full-time on it.
I'm using the open-source version as part of a solution at $dayjob. So how does this benefit getsentry.com? Well first of all, I'm talking about it here. They could also potentially sell my employer a professional services contract if I needed some level of customization that I can't do myself. Finally, I've contributed bug fixes and code changes which benefit my use cases, but also make it a better product for other sentry users.
So, win/win.
As an aside, the sentry developers are great to work with. Very responsive to issues on github and they seem to be available on the sentry IRC channel almost all the time.
[1] http://getsentry.com/
[2] https://github.com/getsentry/sentry
[3] http://blog.getsentry.com/2013/07/17/sentry-at-disqus.html and http://stackshare.io/posts/founder-stories-how-sentry-built-...
It was originally started as an internal tool at Disqus[3]. Its developers were able to open-source it, and spin it off into a side business. The developers then moved on from Disqus to other companies but kept getsentry.com running till it was profitable enough them to go full-time on it.
I'm using the open-source version as part of a solution at $dayjob. So how does this benefit getsentry.com? Well first of all, I'm talking about it here. They could also potentially sell my employer a professional services contract if I needed some level of customization that I can't do myself. Finally, I've contributed bug fixes and code changes which benefit my use cases, but also make it a better product for other sentry users.
So, win/win.
As an aside, the sentry developers are great to work with. Very responsive to issues on github and they seem to be available on the sentry IRC channel almost all the time.
[1] http://getsentry.com/
[2] https://github.com/getsentry/sentry
[3] http://blog.getsentry.com/2013/07/17/sentry-at-disqus.html and http://stackshare.io/posts/founder-stories-how-sentry-built-...
Thanks! I've just updated my applications license to match Sentry's since it seems to cover everything you'd need being in the same situation?
> Is there any examples out there of companies that have actually made money taking this approach?
There are many, whether it fits depends a lot on the product but this open source first, business second approach is definitely not new. See for example MongoDB, WordPress, Vanilla Forums or Discourse.
Or here: http://en.wikipedia.org/wiki/List_of_commercial_open-source_...
And see also: http://en.wikipedia.org/wiki/OpenSaaS
There are many, whether it fits depends a lot on the product but this open source first, business second approach is definitely not new. See for example MongoDB, WordPress, Vanilla Forums or Discourse.
Or here: http://en.wikipedia.org/wiki/List_of_commercial_open-source_...
And see also: http://en.wikipedia.org/wiki/OpenSaaS
[deleted]
+1 for the Wikipedia link.
Mongodb uses the Affero GPL license which is distasteful to many and my concern is using Affero would not REALLY be going open source but would be a way of trying to protect my business/my source code from being hijacked and renamed. Thoughts?
Mongodb uses the Affero GPL license which is distasteful to many and my concern is using Affero would not REALLY be going open source but would be a way of trying to protect my business/my source code from being hijacked and renamed. Thoughts?
How is using AGPL not really open source? Or do you mean it in the "open source" vs "free software" sense? Even then I don't see how it doesn't fit in the OSI definition...
The AGPL is an open source license: you give people access to your source code and they're free to modify it and redistribute it as long as the code stays under the same license.
The main (only?) difference with GPL is that providing a service based on AGPL code is considered the same as redistributing the software so you can't make proprietary changes to the code and say "but I'm not redistributing the code, I'm only running it on my own hardware so I don't have to make the source code available" as you can with GPL code. I believe the OSL3 allows protection from that too btw.
Businesses are still free to take your code and provide a service based on it, they just have to contribute back if they make changes which seems only natural.
Just like the GPL, it's there to ensure that the code stays free. It's only plugging a loophole which makes the GPL less relevant in the age of services.
The AGPL is an open source license: you give people access to your source code and they're free to modify it and redistribute it as long as the code stays under the same license.
The main (only?) difference with GPL is that providing a service based on AGPL code is considered the same as redistributing the software so you can't make proprietary changes to the code and say "but I'm not redistributing the code, I'm only running it on my own hardware so I don't have to make the source code available" as you can with GPL code. I believe the OSL3 allows protection from that too btw.
Businesses are still free to take your code and provide a service based on it, they just have to contribute back if they make changes which seems only natural.
Just like the GPL, it's there to ensure that the code stays free. It's only plugging a loophole which makes the GPL less relevant in the age of services.
From my understanding, AGPL doesn't stop people from "hijacking and renaming" your code. It stipulates that, if someone were to do so, they need to make the source code available to anyone who accesses the application (even over a web browser).
Your developing process with opensource model will be much faster, you will always be few steps ahead with your community.
Theoretically yes, but those people who will fork and "steal" your project are not your clients you are not targeting such audience, they will never pay for your product (hosted service, support etc...).
If they are capable to fork you project, improve and change you code, develop the product faster then you, become your competition, you should hire them :). This is a signal you are failing, something is wrong in your organization/team and you should quit.
Ask your self,Do i ever heard for such story ?
Ask your self,Do i ever heard for such story ?
Open-sourcing your code is a big step, and in doing so, you're essentially gambling on the fact that the services you provide are what's worth money, not the platform you do it on and even if someone else had your tools, you could still do what you do better.
Additionally, I think it depends on how likely your clients are to use that code, IE the model of your business. For example, if you have a time tracking software, a good portion of your clients are probably not strong technology companies. In this case, open-sourcing it, while continuing to develop it, could create an excellent open-source project that is maintained through paying subscribers.
A few examples:
OpenStack[0], is a huge open source[1] cloud operating system. Rackspace runs on them. They've fostered a huge community, all through original backing by Nasa and Rackspace[2]. Essentially, OpenStack is now used by Rackspace to fund their for-profit business, while OpenStack is being actively developed by thousands of people.
Sidekiq[3] is an background job processor, that sells a pro[4] version on top of the open source library. This pro version provides additional user functionality at a cost, allowing funding for future development of the open source library.
Essentially, both these platforms use open source to sustain for-profit businesses, and both had a long term plan for why they wanted to open source a big part of their business. While I think a lot of planning needs to go into open sourcing it, it's definitely sustainable and doable.
[0] https://www.openstack.org/ [1] https://wiki.openstack.org/wiki/Getting_The_Code [2] http://en.wikipedia.org/wiki/OpenStack#History [3] http://sidekiq.org/ [4] http://sidekiq.org/pro/
Additionally, I think it depends on how likely your clients are to use that code, IE the model of your business. For example, if you have a time tracking software, a good portion of your clients are probably not strong technology companies. In this case, open-sourcing it, while continuing to develop it, could create an excellent open-source project that is maintained through paying subscribers.
A few examples:
OpenStack[0], is a huge open source[1] cloud operating system. Rackspace runs on them. They've fostered a huge community, all through original backing by Nasa and Rackspace[2]. Essentially, OpenStack is now used by Rackspace to fund their for-profit business, while OpenStack is being actively developed by thousands of people.
Sidekiq[3] is an background job processor, that sells a pro[4] version on top of the open source library. This pro version provides additional user functionality at a cost, allowing funding for future development of the open source library.
Essentially, both these platforms use open source to sustain for-profit businesses, and both had a long term plan for why they wanted to open source a big part of their business. While I think a lot of planning needs to go into open sourcing it, it's definitely sustainable and doable.
[0] https://www.openstack.org/ [1] https://wiki.openstack.org/wiki/Getting_The_Code [2] http://en.wikipedia.org/wiki/OpenStack#History [3] http://sidekiq.org/ [4] http://sidekiq.org/pro/
It depends on the business. That model definitely works, and another variant on the model where paid solution users get additional enterprisey features also works (single sign on, Active Directory integration, etc). Take for example Chef, which has a paid version and an open source version. Paid Chef comes in 2 flavors, hosted and on-prem. There's also Nagios and several other IT monitoring solutions.
You may want to double check on which license is best to use in this scenario, but it definitely is possible to grow a business using it.
You may want to double check on which license is best to use in this scenario, but it definitely is possible to grow a business using it.
Does Chef make money though?
GitLab B.V. CEO here, our business model is to charge the largest organizations that run GitLab on their servers. Our SaaS GitLab.com is free to use for almost all (there is a plan if you want personal support). More than 100,000 organizations use the open source version for free. But our paid offering that offers features that are most useful for organizations with more than 100 people is where we generate revenues. Don't underestimate the needs of larger organizations to run software on their own servers.
In December, I open sourced SageMathCloud (https://cloud.sagemath.com), after it had been closed source for years. SageMathCloud (SMC) is a "SaaS product" in which you collaboratively edit IPython notebooks, LaTeX documents, Sage worksheets, R code, etc., in a browser. It is not yet a business, though it may become a business soon. Here's what happened with open sourcing.
It was politically contentious for SMC to be closed source, due the connection with the Sage open source math software project (see [1] for a big thread attacking SMC for being closed, and [2] for a rebuttal). SMC was closed source for years, primarily because my university commercialization office wouldn't work with me unless SMC was closed source.
In December 2014, I discovered that SMC had received some development support from NSF grants that had explicit requirements that all code written under those grants be released under the GPL (very few NSF programs have open source requirements, but the SI2 NSF program recently added them [3]). As soon as I realized this, I complied with the conditions of those grants and open sourced everything. This has had no real impact on SMC development. This didn't surprise me -- many of the other responses in this thread express the same expectation. I wasn't surprised because I started the Sage math software project back in 2005, and grew it from 0 to hundreds of developers (over many years), so my expectations for what it would take to get useful contributions to SMC were realistic -- massive, insanely hard work over many years, many workshops, writing lots of documentation, recruiting developers, arguing for why my project is better to contribute to than the many competitors, etc. Building an open source project is like building a company -- you have to recruit and train every new "hire" (contributor), build up process, sell a vision, etc.
My situation is unusual, since I am balancing simultaneously being both a (tenured) mathematics professor at a university and founding a company. Technically the university can assert ownership over anything I write using university resources (see [4]). However, due to the viral nature of the GPL, it doesn't matter who owns what I write, since I (and everybody) can still use it. I didn't want to use the GPL for SageMathCloud (I much prefer the BSD license), but technically I have no choice.
[1] https://groups.google.com/forum/#!topic/sage-devel/ojLOJaxIh... [2] http://sagemath.blogspot.com/2014/08/what-is-sagemathcloud-l... [3] http://www.nsf.gov/pubs/2014/nsf14520/nsf14520.htm [4] http://www.washington.edu/admin/rules/policies/PO/EO36.html
It was politically contentious for SMC to be closed source, due the connection with the Sage open source math software project (see [1] for a big thread attacking SMC for being closed, and [2] for a rebuttal). SMC was closed source for years, primarily because my university commercialization office wouldn't work with me unless SMC was closed source.
In December 2014, I discovered that SMC had received some development support from NSF grants that had explicit requirements that all code written under those grants be released under the GPL (very few NSF programs have open source requirements, but the SI2 NSF program recently added them [3]). As soon as I realized this, I complied with the conditions of those grants and open sourced everything. This has had no real impact on SMC development. This didn't surprise me -- many of the other responses in this thread express the same expectation. I wasn't surprised because I started the Sage math software project back in 2005, and grew it from 0 to hundreds of developers (over many years), so my expectations for what it would take to get useful contributions to SMC were realistic -- massive, insanely hard work over many years, many workshops, writing lots of documentation, recruiting developers, arguing for why my project is better to contribute to than the many competitors, etc. Building an open source project is like building a company -- you have to recruit and train every new "hire" (contributor), build up process, sell a vision, etc.
My situation is unusual, since I am balancing simultaneously being both a (tenured) mathematics professor at a university and founding a company. Technically the university can assert ownership over anything I write using university resources (see [4]). However, due to the viral nature of the GPL, it doesn't matter who owns what I write, since I (and everybody) can still use it. I didn't want to use the GPL for SageMathCloud (I much prefer the BSD license), but technically I have no choice.
[1] https://groups.google.com/forum/#!topic/sage-devel/ojLOJaxIh... [2] http://sagemath.blogspot.com/2014/08/what-is-sagemathcloud-l... [3] http://www.nsf.gov/pubs/2014/nsf14520/nsf14520.htm [4] http://www.washington.edu/admin/rules/policies/PO/EO36.html
Ghost is probably a good example to investigate.
Their software is open sourced and easy for anyone with a server and some technical knowledge to get up and running. They offer a paid for hosted product which is reasonably priced and offers automated updates.
Here's[0] a report on their progress in 2014, as you can see their model is working very well for their product.
[0] http://blog.ghost.org/2014-report/
Their software is open sourced and easy for anyone with a server and some technical knowledge to get up and running. They offer a paid for hosted product which is reasonably priced and offers automated updates.
Here's[0] a report on their progress in 2014, as you can see their model is working very well for their product.
[0] http://blog.ghost.org/2014-report/
btw Ghost is a not for profit organisation. Does that make any difference?
Like the other responder caw I think it depends on your business, and it also depends on your target audience.
Open sourcing the wordpress blog platform? Sure that makes sense, the target audience for wordpress are largely technical (to a greater or lesser degree), and want to see what they're putting on their servers. More importantly they want to customise it without limitation.
Open sourcing a productivity application? Hmm, not quite so clear cut. If the majority of your users are technical that's good. But are your users going to want to fiddle with it to the extent that they want it open sourced? I'm really not confident that they will unless you know something about them that I don't? In other words, what is the benefit to your customers in your app being open source?
To answer your other questions...I don't think that you'll get more press coverage about your project just because it's open source. Open source isn't a new thing.
My personal view is that I would launch your app paid for using one of the standard pricing models. See if you can gain traction on the benefits of the app alone, rather than trying to put an open source twist on it at the outset.
Open sourcing the wordpress blog platform? Sure that makes sense, the target audience for wordpress are largely technical (to a greater or lesser degree), and want to see what they're putting on their servers. More importantly they want to customise it without limitation.
Open sourcing a productivity application? Hmm, not quite so clear cut. If the majority of your users are technical that's good. But are your users going to want to fiddle with it to the extent that they want it open sourced? I'm really not confident that they will unless you know something about them that I don't? In other words, what is the benefit to your customers in your app being open source?
To answer your other questions...I don't think that you'll get more press coverage about your project just because it's open source. Open source isn't a new thing.
My personal view is that I would launch your app paid for using one of the standard pricing models. See if you can gain traction on the benefits of the app alone, rather than trying to put an open source twist on it at the outset.
(Disclaimer: I work for one of partner companies)
Odoo[1] (an all-in-one platform for companies) has been having plenty of success using the open source model. There's a community of partner companies which contributes bug reports, fixes and modules, and builds upon the base platform, and then when selling those solutions to other companies, those contracts often include an yearly support fee for Odoo (the company) itself.
Regardless of the technical merits of the platform (I think it's actually pretty decent, but some disagree), the business model has been working. Some of the clients using it for core business functions include companies with revenues in the hundreds of millions, as well as official organisms.
Odoo (the company) has also recently raised $10M from European VCs.
[1] https://www.odoo.com/
Odoo[1] (an all-in-one platform for companies) has been having plenty of success using the open source model. There's a community of partner companies which contributes bug reports, fixes and modules, and builds upon the base platform, and then when selling those solutions to other companies, those contracts often include an yearly support fee for Odoo (the company) itself.
Regardless of the technical merits of the platform (I think it's actually pretty decent, but some disagree), the business model has been working. Some of the clients using it for core business functions include companies with revenues in the hundreds of millions, as well as official organisms.
Odoo (the company) has also recently raised $10M from European VCs.
[1] https://www.odoo.com/
There are plenty of businesses running on this model. Wordpress is probably the biggest.
I always wanted to try and test this approach, as I am convinced that a lot (most?) of the value in SaaS is in hosting. Operating your own servers is a huge hassle, and many people will gladly pay someone to do it for them.
Also if you open source your code and offer customers a full export of their data you have two advantages over closed source SaaS: Customers do not need to worry about vendor lock-in. And they can depend on being able to continue using your software even in case you ever go out of business.
Also if you open source your code and offer customers a full export of their data you have two advantages over closed source SaaS: Customers do not need to worry about vendor lock-in. And they can depend on being able to continue using your software even in case you ever go out of business.
For the Open Bank Project ( http://www.openbankproject.com and https://github.com/OpenBankProject/ ) we use AGPL + commercial + Harmony CLA. We have tech partners but so far we've done most of the master development ourselves. Time will tell if this is a good approach! :-)
I wrote a piece on open source business models that you might find useful:
http://blog.imranghory.org/open-source-business-models
The big risk with your suggested approach is that you have no defensibility as there's nothing stopping someone else offering a hosted version of your software. Because of this it's hard to maintain the high-margins typically required to grow a software businesses.
Open sourcing your product also isn't going to magically make it more popular; unless there's strong reasons why a customer would prefer an open source version (i.e. if you're making infrastructure software which you're asking your customers to bet their business on) it's unlikely to have a significantly greater marketing impact than other freemium strategies.
It sounds like what you really need is a go-to-market strategy. Most SaaS is sold through traditional online marketing (ads, seo, whitepapers, etc.) and sales and those are probably the main options you should be evaluating.
http://blog.imranghory.org/open-source-business-models
The big risk with your suggested approach is that you have no defensibility as there's nothing stopping someone else offering a hosted version of your software. Because of this it's hard to maintain the high-margins typically required to grow a software businesses.
Open sourcing your product also isn't going to magically make it more popular; unless there's strong reasons why a customer would prefer an open source version (i.e. if you're making infrastructure software which you're asking your customers to bet their business on) it's unlikely to have a significantly greater marketing impact than other freemium strategies.
It sounds like what you really need is a go-to-market strategy. Most SaaS is sold through traditional online marketing (ads, seo, whitepapers, etc.) and sales and those are probably the main options you should be evaluating.
Are you selling Service as a Service or Software as a Service ?
If you're selling Service, you're selling the infrastucture, the ease of use, the support, the knowledge in the domain, and the scale you have as being the original player gives you insight into the changes needed in the software. At this point the Software is only a tool for your business, but that's not what your clients want.
Maybe some people will use the Open Source version without paying you. Maybe they will install it for their pet project, or for a prototype at $dayjob. And maybe one day they will want to go in production, won't want to be hassled by all the sysadmin gory stuff associated with running their own machine, and will just come to you.
You have to remember that you're selling a service, competitors will come and challenge you whether they have your code or not. Make your service awesome, the people will still be coming for you.
If you're selling Service, you're selling the infrastucture, the ease of use, the support, the knowledge in the domain, and the scale you have as being the original player gives you insight into the changes needed in the software. At this point the Software is only a tool for your business, but that's not what your clients want.
Maybe some people will use the Open Source version without paying you. Maybe they will install it for their pet project, or for a prototype at $dayjob. And maybe one day they will want to go in production, won't want to be hassled by all the sysadmin gory stuff associated with running their own machine, and will just come to you.
You have to remember that you're selling a service, competitors will come and challenge you whether they have your code or not. Make your service awesome, the people will still be coming for you.
As mentioned in the comments here, there are companies like MongoDB, Wordpress & Spring Framework (of which its parent company was sold for 420 million dollars) which have open source products at their core and have been successful companies financially.
I would argue though, that many of these successful companies are more platform providers than SASS.
I would argue though, that many of these successful companies are more platform providers than SASS.
We are asking ourselves the same question.
We have developed for a few years a "more than email" server that we have already licensed to one major customer.
The open source or not question is one main right now, and until we decide, we have prepared a free to download offer based on Docker. If you're curious: https://github.com/MLstate/PEPS
We haven't really launched yet, but think that open sourcing (using for instance the AGPL license) might bring:
- more visibility,
- more confidence for the customers who would buy support and maintenance instead of licenses,
- the opportunity of creating a community (if not on the core product, at least on extensions)
- the loss of a few potential customers that would just use the open source version instead of work with us.
We have developed for a few years a "more than email" server that we have already licensed to one major customer.
The open source or not question is one main right now, and until we decide, we have prepared a free to download offer based on Docker. If you're curious: https://github.com/MLstate/PEPS
We haven't really launched yet, but think that open sourcing (using for instance the AGPL license) might bring:
- more visibility,
- more confidence for the customers who would buy support and maintenance instead of licenses,
- the opportunity of creating a community (if not on the core product, at least on extensions)
- the loss of a few potential customers that would just use the open source version instead of work with us.
The example that springs to mind is Spree (https://spreecommerce.com/). Spree itself is open source, but Spree Commerce make their money from support, implementation and premium offerings.
The issue with Spree is that they rely on Wombat for connectivity to other systems and Wombat is NOT open source, it's a hosted SAAS solution. So by choosing Spree, you are inherently locked into using Wombat as well.
A programm is made of code and setup/tweaking.
If you make a program for interconnecting element together (by definition a complex system) it can yield chaotic behaviour. What will be important will not be your code for doing so, but your setup.
You may not want to spread your specific setup, but you can release good brick of your code that may benefit from externalities (the more it has adoption, the more it enforces your position on the market). (virtuous cicle)
You can also release on purpose shitty free softwares blocking the devs from easily be able to use their platform if there are not «pro» of your complex solution... like systemd (vicious circle, the more it is adopted, the more you block competitors)
If you make a program for interconnecting element together (by definition a complex system) it can yield chaotic behaviour. What will be important will not be your code for doing so, but your setup.
You may not want to spread your specific setup, but you can release good brick of your code that may benefit from externalities (the more it has adoption, the more it enforces your position on the market). (virtuous cicle)
You can also release on purpose shitty free softwares blocking the devs from easily be able to use their platform if there are not «pro» of your complex solution... like systemd (vicious circle, the more it is adopted, the more you block competitors)
IMHO, your source code is not what makes your product special, it's your service and support that counts and is valuable to customers. There's plenty of examples where at least a core product is open source under very liberal open source licenses, but a company behind it sells support, services, extensions etc around the open source core product. I think that at least companies are more interested in buying your services around the product (guaranteed support response times, customization, training, ...). However I mostly know infrastructure tools which follow this philosophy (e.g. Vagrant, Chef, puppet, various database products etc...).
For an application to be ready for customers there is usually a lot more around it. I've met the guys from codebox.io and gitbook.com and what they did with codebox was, they open sourced the web-ide, however, all the infrastructure they build around the SaaS offering was what actually made it work. While users have the possibility to help improve the essential part of your offering, it will still be a lot of work for someone else to be the copycat.
An example of this is Travis CI. Most of their platform is open-source, still they are pretty successful with their companys SaaS and Hosted solutions.
webhook.com is open source, and an amazing tool. Could a Russian or Chinese developer basically recreate their service for a different market? Yes, but not without significant work. And then, unless they are as committed to making their product awesome as the webhook.com team is, they'll always be looking over their shoulder. E.g as webhook.com internationalizes, etc.
Is it likely someone would try that in the English-speaking market? I just doubt it. Technology that someone else is using and improving but also made available to you will never be a competitive advantage.
Is it likely someone would try that in the English-speaking market? I just doubt it. Technology that someone else is using and improving but also made available to you will never be a competitive advantage.
I'm grateful for you asking this as I'm in the same scenario now.
This is exactly what we're doing at Scalr (http://www.scalr.com/). Our experience has been the following:
+ An open-source version that folks can download, install, and trial is a great way to get your software in as many hands as possible. However, that's also more work for you: if folks download your software and it doesn't install / has bugs they can't troubleshoot, you're providing a very bad experience, and that will reflect badly on your commercial offering.
+ Research your market first. In our case, it's increasingly difficult / unpopular today to provide developer / IT tools that aren't open-source. In other words, being open-source is becoming a requirement.
+ Open-source offers reassurance to enterprise customers who might not have considered your product otherwise (you're small, and they don't want to tie their success to your survival, but if your product is open-source, this concern is more limited). There again though, it depends on who're selling to.
+ Our product hasn't been forked / used by a competitor. This wasn't really ever a concern. Note that we're following a model where we do open-source releases on a 3/6 month basis (we don't develop in the open); that's a reason, too.
+ We did lose several prospects to our own open-source software, but we also acquired several customers who transitioned from the OSS edition to the commercial edition. the only incentive at this time to choose the commercial edition instead of the open-source one is "support and more frequent updates" (which is good, but not always enough to get prospects to sign you a check). Before you decide to open-source your product, think very hard about how you'll differentiate your open-source and commercial editions (options include delaying updates, differentiating on features, support...).
+ Most of our revenue is now coming from the commercial single-tenant edition, whereas it used to be the SaaS edition. This happened after we pivoted to the enterprise, and made it much easier to deploy your own Scalr installation (it used to be a pretty daunting task).
+ We're not getting that many contributions (probably largely because of the model I mentioned above), and because so far we haven't had the energy to encourage them. In other words: just putting your product out on GitHub doesn't mean some folks from the internet will suddenly start working on it for free. That just doesn't happen. We did get a few very-well-thought-out bug reports, though!
Ultimately, I'd conclude with saying that open-sourcing your product is a solid way to get more attention. However, it's also more work: you're creating a competitor (your own product) that you must somehow beat in deals, all the while making sure that that competitor is solid enough that it doesn't turn people off your product.
Hope this helps!
You can reach me at [email protected] if you have questions you think I could answer!
----
One last thing that isn't stricly-speaking sales related is people. We have an open-source culture here at Scalr, and there are employees (including myself) for whom that matters a lot.
+ An open-source version that folks can download, install, and trial is a great way to get your software in as many hands as possible. However, that's also more work for you: if folks download your software and it doesn't install / has bugs they can't troubleshoot, you're providing a very bad experience, and that will reflect badly on your commercial offering.
+ Research your market first. In our case, it's increasingly difficult / unpopular today to provide developer / IT tools that aren't open-source. In other words, being open-source is becoming a requirement.
+ Open-source offers reassurance to enterprise customers who might not have considered your product otherwise (you're small, and they don't want to tie their success to your survival, but if your product is open-source, this concern is more limited). There again though, it depends on who're selling to.
+ Our product hasn't been forked / used by a competitor. This wasn't really ever a concern. Note that we're following a model where we do open-source releases on a 3/6 month basis (we don't develop in the open); that's a reason, too.
+ We did lose several prospects to our own open-source software, but we also acquired several customers who transitioned from the OSS edition to the commercial edition. the only incentive at this time to choose the commercial edition instead of the open-source one is "support and more frequent updates" (which is good, but not always enough to get prospects to sign you a check). Before you decide to open-source your product, think very hard about how you'll differentiate your open-source and commercial editions (options include delaying updates, differentiating on features, support...).
+ Most of our revenue is now coming from the commercial single-tenant edition, whereas it used to be the SaaS edition. This happened after we pivoted to the enterprise, and made it much easier to deploy your own Scalr installation (it used to be a pretty daunting task).
+ We're not getting that many contributions (probably largely because of the model I mentioned above), and because so far we haven't had the energy to encourage them. In other words: just putting your product out on GitHub doesn't mean some folks from the internet will suddenly start working on it for free. That just doesn't happen. We did get a few very-well-thought-out bug reports, though!
Ultimately, I'd conclude with saying that open-sourcing your product is a solid way to get more attention. However, it's also more work: you're creating a competitor (your own product) that you must somehow beat in deals, all the while making sure that that competitor is solid enough that it doesn't turn people off your product.
Hope this helps!
You can reach me at [email protected] if you have questions you think I could answer!
----
One last thing that isn't stricly-speaking sales related is people. We have an open-source culture here at Scalr, and there are employees (including myself) for whom that matters a lot.
Foolish? That covers a lot of ground. So much that the only answer is "it depends."
The first thing it depends on is where one is wandering on a spectrum from Coca-Cola brown beverage trade secrets to full on Stallmanism. People can and will disagree about "the right thing" using plausible arguments based on reasonable assumptions [this doesn't preclude implausible arguments based on unreasonable assumptions or the other corners of the 2x2 grid]. We all decide what sort of person to be.
Since this is a common conundrum, Spolsky has encountered it and being Spolsky has clearly thought about the issue. My understanding, and he can correct me if I'm wrong is:
Wasabi is FogCreek's VBscript compiler. It performs a specific task. That task doesn't require a math library so Wasabi doesn't have one. The only people who need it are Fogbugz customers for the purpose of using Fogbugz. They don't need Wasabi to have a math library. [wasabi]
The compelling rationale for not open-sourcing it is that it basically sucks as a compiler for the way people usually use compilers. In the very limited use case of Fogbugz, it doesn't suck. It's even good enough for Spolsky. If someone wants to learn about compilers The Dragon Book is better. If they want to learn from example code, there are much better compilers in open source. Is the world better if using Wasabi in the wild just plain sucks and studying the source code leads to poor conclusions about writing compilers? Probably not.
Why not just open source all of Fogbugz? It uses technologies which are licensed under terms incompatible with various open source licenses. The same is true of StackOverflow. They both have free as in beer options. It's a more generous business model than used car lots operate under.
Since you are asking the question, you're in the land of utilitarianism. Utilitarianism is hard because it requires weighing potential harms against potential benefits. That's engineering for you.
I think the world is better for what StackOverflow provides right now than it would be if it provided less but was entirely open source. The pace of improvements that not having to patch bugs on other people's systems allows outweighs the benefits of it going the route of PHPbb.
Good luck.
[wasabi]: http://www.joelonsoftware.com/items/2006/09/01b.html
The first thing it depends on is where one is wandering on a spectrum from Coca-Cola brown beverage trade secrets to full on Stallmanism. People can and will disagree about "the right thing" using plausible arguments based on reasonable assumptions [this doesn't preclude implausible arguments based on unreasonable assumptions or the other corners of the 2x2 grid]. We all decide what sort of person to be.
Since this is a common conundrum, Spolsky has encountered it and being Spolsky has clearly thought about the issue. My understanding, and he can correct me if I'm wrong is:
1] open-sourcing should be done because it benefits users.
2] open-sourcing doesn't always benefit users.
Wasabi is FogCreek's VBscript compiler. It performs a specific task. That task doesn't require a math library so Wasabi doesn't have one. The only people who need it are Fogbugz customers for the purpose of using Fogbugz. They don't need Wasabi to have a math library. [wasabi]
The compelling rationale for not open-sourcing it is that it basically sucks as a compiler for the way people usually use compilers. In the very limited use case of Fogbugz, it doesn't suck. It's even good enough for Spolsky. If someone wants to learn about compilers The Dragon Book is better. If they want to learn from example code, there are much better compilers in open source. Is the world better if using Wasabi in the wild just plain sucks and studying the source code leads to poor conclusions about writing compilers? Probably not.
Why not just open source all of Fogbugz? It uses technologies which are licensed under terms incompatible with various open source licenses. The same is true of StackOverflow. They both have free as in beer options. It's a more generous business model than used car lots operate under.
Since you are asking the question, you're in the land of utilitarianism. Utilitarianism is hard because it requires weighing potential harms against potential benefits. That's engineering for you.
I think the world is better for what StackOverflow provides right now than it would be if it provided less but was entirely open source. The pace of improvements that not having to patch bugs on other people's systems allows outweighs the benefits of it going the route of PHPbb.
Good luck.
[wasabi]: http://www.joelonsoftware.com/items/2006/09/01b.html
You put it on github under an MIT or BSD or similar license. So corporations or anyone else can download and install your software and use it at no cost.
On your main website, you offer the software but on a per-user fully hosted, running online basis. So your revenue will come from people signing up to use your fully hosted service where they don't need to make any effort to install or configure - it just works. You also make money offering support contracts to people who have downloaded and installed their own copies of the software.
The reason you have open sourced it is to spread the word, gather interest and build community around your product. The theory being that the vast number of free users will be the impetus that leads to a small number of paying people discovering and using your product. Maybe free and open source is more newsworthy, more likely to get press and blog coverage?
Theoretically anyone could take your code and set up in competition to you. Anyone could fork your code and rename it to something else.
So is open sourcing your SAAS application a good way to do business, or is it foolish and giving away the farm?
Is there any examples out there of companies that have actually made money taking this approach?
I'm scared that if I fully open source then I will somehow have given the value away.