Ask YC: What are the downsides of open source?
11 comments
What is the challenge to make open source software successful in terms of making revenue?
In discussions about open source software, I'm frequently reminded of the following PG quote:
To be a startup, a company has to be a product business, not a service business. By which I mean not that it has to make something physical, but that it has to have one thing it sells to many people, rather than doing custom work for individual clients.
Open source is inherently not a product -- at least, not in the sense of being something you can sell to many people. The frequent cry of "but we'll make money selling support" ignores a critical fact: There aren't enough hours in the day to get rich by selling support contracts.
The one "open source" company which was successful at making lots of money -- MySQL -- wasn't in fact an open source company: They made their money selling a commercial product, and they just happened to use releasing a GPLed version as a cheap advertising mechanism.
I strongly support open source software; but a startup which builds open source software? It ain't a startup.
In discussions about open source software, I'm frequently reminded of the following PG quote:
To be a startup, a company has to be a product business, not a service business. By which I mean not that it has to make something physical, but that it has to have one thing it sells to many people, rather than doing custom work for individual clients.
Open source is inherently not a product -- at least, not in the sense of being something you can sell to many people. The frequent cry of "but we'll make money selling support" ignores a critical fact: There aren't enough hours in the day to get rich by selling support contracts.
The one "open source" company which was successful at making lots of money -- MySQL -- wasn't in fact an open source company: They made their money selling a commercial product, and they just happened to use releasing a GPLed version as a cheap advertising mechanism.
I strongly support open source software; but a startup which builds open source software? It ain't a startup.
SourceFire circa 2002, purveyors of Snort via OSS and hardware appliance, now IPO'd? Not a startup.
Sleepycat software, purveyors of Berkeley DB under dual GPL and commercial license, acquired by Oracle? Not a startup.
Splunk, purveyors of Splunk, open source core and proprietary commercial extensions, with over 20MM in VC funding? Not a startup.
Hyperic, purveyors of Hyperic, which is OSS end-to-end, with a 6MM B from Accel? Not a startup.
Zimbra, purveyors of OSS Exchange clone Zimbra, acquired by Yahoo!? Not a startup.
Astaro, purveyors of one of the top 5 "UTM" (IPS+firewall) boxes, now profitable? Not a startup.
None of these companies are services businesses.
Your characterization of MySQL is laughable, too. The "cheap advertising version of MySQL" you mention accounts for 99% of the real-world usage of MySQL in the marketplace, and anybody on Hacker News wishes they had the market power MySQL did.
So, my response to you: name an equivalent number of companies any of us has heard of with an open-source product that is services-driven that isn't Red Hat or IBM.
Sleepycat software, purveyors of Berkeley DB under dual GPL and commercial license, acquired by Oracle? Not a startup.
Splunk, purveyors of Splunk, open source core and proprietary commercial extensions, with over 20MM in VC funding? Not a startup.
Hyperic, purveyors of Hyperic, which is OSS end-to-end, with a 6MM B from Accel? Not a startup.
Zimbra, purveyors of OSS Exchange clone Zimbra, acquired by Yahoo!? Not a startup.
Astaro, purveyors of one of the top 5 "UTM" (IPS+firewall) boxes, now profitable? Not a startup.
None of these companies are services businesses.
Your characterization of MySQL is laughable, too. The "cheap advertising version of MySQL" you mention accounts for 99% of the real-world usage of MySQL in the marketplace, and anybody on Hacker News wishes they had the market power MySQL did.
So, my response to you: name an equivalent number of companies any of us has heard of with an open-source product that is services-driven that isn't Red Hat or IBM.
You could add TrollTech, purveyors of Qt, to that list as well.
> The frequent cry of "but we'll make money selling support" ignores a critical fact: There aren't enough hours in the day to get rich by selling support contracts.
Speaking of ignoring critical facts:
1) You can hire more people to do support, which increases the total available amount of hours in the day.
2) Most support contracts are barely used and bought purely for comfort, so you can oversubscribe your support team to increase profit margins.
3) Every year software companies make billions on support contracts. MySQL made many millions on support.
Speaking of ignoring critical facts:
1) You can hire more people to do support, which increases the total available amount of hours in the day.
2) Most support contracts are barely used and bought purely for comfort, so you can oversubscribe your support team to increase profit margins.
3) Every year software companies make billions on support contracts. MySQL made many millions on support.
Regarding 1) - yes... that's true, but it's a very linear model, which means it's of less interest to people like VC's. 2) is true, but lots of people realize that they don't need the support. The better you can bundle it, like Redhat does, the better off you are, because it means sticking more people with fees for something they don't need.
It's not an easy road.
It's not an easy road.
Agreed. You should have a very proven path to generate revenue, outside of licensing, if you go the open source route. Companies who try to go it "halfway" by releasing a core product as OSS and then try to introduce closed-source addons have a tough time getting by on services while they try to prove that the addon is worth the extra cost: ArsDigita had to try this route in order to grow the business, and they burned through $20M before getting sold for pennies on the dollar to Red Hat.
In short, fantastic tools with which to build a business, but as a selling point of a product...once you take the genie out of the bottle, you often find yourself wishing you could put it back in later.
In short, fantastic tools with which to build a business, but as a selling point of a product...once you take the genie out of the bottle, you often find yourself wishing you could put it back in later.
Phil Greenspun wrote at painful length about what killed ACS, and it certainly wasn't open source.
Now, provide another example of a company that screwed up by "halfway" doing OSS without "proving the addons were worth the cost". I've provided plenty of specific counterexamples.
Now, provide another example of a company that screwed up by "halfway" doing OSS without "proving the addons were worth the cost". I've provided plenty of specific counterexamples.
Ha ha ha, how about Sun open-sourcing Java way too late to be of relevant use to anyone?
I'm more or less in agreement. The problem is scarcity - what you can make people pay for because it's scarce:
http://journal.dedasys.com/articles/2007/02/03/in-thrall-to-...
Looking at several successful "open source" oriented companies, we can see what kind of scarcity they introduced:
- Mysql, as you say, had their wonky licensing and a commercial product.
- Redhat decided to not license the 'branding' component of their distribution under a free license, so while you can copy the software, you have to remove a lot of bits and pieces (which CentOS has done), and it's not really Redhat anymore... If you want the support, you have to pay their licensing fees.
- Cygnus was relatively successful, a while ago, and were successful because they seemed, IMO, to stick to the letter of the law rather than the spirit: they'd give their clients full source code, but didn't make it public. They did a lot of 'billing' work, too, IIRC.
Still - I think there are a lot of advantages to using open source, and in many cases there are even business cases for developing it, but it is hard to base a business exclusively on open source.
http://journal.dedasys.com/articles/2007/02/03/in-thrall-to-...
Looking at several successful "open source" oriented companies, we can see what kind of scarcity they introduced:
- Mysql, as you say, had their wonky licensing and a commercial product.
- Redhat decided to not license the 'branding' component of their distribution under a free license, so while you can copy the software, you have to remove a lot of bits and pieces (which CentOS has done), and it's not really Redhat anymore... If you want the support, you have to pay their licensing fees.
- Cygnus was relatively successful, a while ago, and were successful because they seemed, IMO, to stick to the letter of the law rather than the spirit: they'd give their clients full source code, but didn't make it public. They did a lot of 'billing' work, too, IIRC.
Still - I think there are a lot of advantages to using open source, and in many cases there are even business cases for developing it, but it is hard to base a business exclusively on open source.
If you make a development component, you can dual GPL/commercial license your product, like Sleepycat.
If you make an enterprise product, you can sell an appliance or a VM that runs it, and GPL the programs themselves, like SourceFire.
If you make a web product, you can GPL the code and sell the hosted version, like WordPress.
If you make an extensible product, you can GPL the core and sell the bells and whistles, like Splunk.
If you make an end-user product, you can GPL the core and sell the UI.
If you make an enterprise product, you can sell an appliance or a VM that runs it, and GPL the programs themselves, like SourceFire.
If you make a web product, you can GPL the code and sell the hosted version, like WordPress.
If you make an extensible product, you can GPL the core and sell the bells and whistles, like Splunk.
If you make an end-user product, you can GPL the core and sell the UI.
Good examples, which confirm what I said: you have to introduce an element of scarcity somewhere, that is not the software itself (with the possible exception of GPL'ed libraries, but that's sort of a special case).
When you make the decision to go open source obviously it's not from the product it self you are making money directly, only when sell licenses with support probably, but I am not excited with that model due to the fact that is not really clear how you can succeed reaching businesses to pay.
Thats my concern basically, while also the probabilities are mostly against you, and probably the product will disappear.
Of course, you seize to be considered a startup anymore, because a startup is about rapid growth.
So probably thats why te best way to go is to have a free version of the product and more advanced features for those who pay, and a seperate license to have access to the source code, like Symbian does?
Thats my concern basically, while also the probabilities are mostly against you, and probably the product will disappear.
Of course, you seize to be considered a startup anymore, because a startup is about rapid growth.
So probably thats why te best way to go is to have a free version of the product and more advanced features for those who pay, and a seperate license to have access to the source code, like Symbian does?
But portions can be open source, as long as you keep what makes you as a business closed initially, you can retain control over your bloodline, while either open sourcing chunks or utilizing other open source projects.
Also: by your definition, Reddit and Octoparts? Not startups. Good call, Colin.
How does that follow from the above definitions?
I don't agree that if you build open source software, you aren't a startup -- but I do think that a big part of being a (VC) backed startup is the potential to achieve "hockey stick" growth, and that can be hard to do through support contracts, consulting, and certification alone.
I don't agree that if you build open source software, you aren't a startup -- but I do think that a big part of being a (VC) backed startup is the potential to achieve "hockey stick" growth, and that can be hard to do through support contracts, consulting, and certification alone.
"To be a startup, a company has to be a product business, not a service business."
Reddit and Octopart are product businesses, not service businesses.
By some tortured definition, sure. You win!
In what sense do are those sites "service businesses"?
The whole point of the service vs. product distinction that PG was making is that a service business is less scalable: its revenue is basically linear in the number of employees that it has, because a human being has to do more work for each new customer. That is not the case for product businesses or for Reddit or Octopart (or most other web startups) -- if Reddit's traffic increases 100x overnight, they don't need 100x the employees to capitalize. Craigslist is an example that makes the difference pretty clear. Whether you want to call them "product businesses" or not misses the point.
The whole point of the service vs. product distinction that PG was making is that a service business is less scalable: its revenue is basically linear in the number of employees that it has, because a human being has to do more work for each new customer. That is not the case for product businesses or for Reddit or Octopart (or most other web startups) -- if Reddit's traffic increases 100x overnight, they don't need 100x the employees to capitalize. Craigslist is an example that makes the difference pretty clear. Whether you want to call them "product businesses" or not misses the point.
It's all a question of where you draw the line, I guess. There are consultancies, which scale 1.5x. There are service providers, which scale 2-3x. There are ASPs, which scale 5x. And there are product companies, which scale 10x.
Reddit is still different from an actual product company. The Reddit product scales independantly of the number of redditors or subreddits, because the Reddit product isn't hosted.
This is all a tangent, though. My fault.
Reddit is still different from an actual product company. The Reddit product scales independantly of the number of redditors or subreddits, because the Reddit product isn't hosted.
This is all a tangent, though. My fault.
To be honest, open source doesn't really benefit the company doing it nearly as much as it benefits the users. Most of them essentially get something for nothing. And nowadays, it's no news story to be open source, so the extra marketing you get for being open is much less than it was 5 years ago.
Unless you reach a certain level, external developer contribution will be minimal as well (compared to what's done internally), so you can't depend on that for benefit either. And as for selling support, forget it. If your product is stable, 99% of people will opt for the "we'll just call you when we need you" option and take the hourly billing rate (even a jacked up one for emergencies), because they'll only need it maybe once a year.
I've run a successful albeit very small open source company for 7 years, and we're gearing up to release another major version by end of summer (www.simian.ca). I really don't mean to come off cynical or unappreciative of certain users (we have a number of users who have been amazingly helpful, and those are the users that make it all worthwhile), but as a model for a new business you have to look at the reality of how well it can work and grow into a sustainable model. Open source is a big risk for little potential gain these days.
My advice, start a company that offers a subscription-based service or boxed product (closed source). You can always provide APIs for 3rd parties to interact with, and you can open source libraries and other useful but non-essential bits. But giving away the central thing that defines your company is a difficult sell.
Unless you reach a certain level, external developer contribution will be minimal as well (compared to what's done internally), so you can't depend on that for benefit either. And as for selling support, forget it. If your product is stable, 99% of people will opt for the "we'll just call you when we need you" option and take the hourly billing rate (even a jacked up one for emergencies), because they'll only need it maybe once a year.
I've run a successful albeit very small open source company for 7 years, and we're gearing up to release another major version by end of summer (www.simian.ca). I really don't mean to come off cynical or unappreciative of certain users (we have a number of users who have been amazingly helpful, and those are the users that make it all worthwhile), but as a model for a new business you have to look at the reality of how well it can work and grow into a sustainable model. Open source is a big risk for little potential gain these days.
My advice, start a company that offers a subscription-based service or boxed product (closed source). You can always provide APIs for 3rd parties to interact with, and you can open source libraries and other useful but non-essential bits. But giving away the central thing that defines your company is a difficult sell.
I think it matters who your customer is and the value they derive from your product.
Open source makes a huge difference when your product is intended to be embedded in your customer's product. When their business depends on yours it's obvious they need to pay you or ultimately suffer the higher cost to them of having to maintain your code-base themselves.
When you're talking about some dinky utility a non-technical end-user may use then you're probably smarter to go the shareware route.
One thing to worry a little about is how to protect yourself from competitors that may try to compete with you using your own code. If you're the sole owner of your core technology and there isn't any significant secret factual information in it then you're probably safe going open source with the appropriate licensing.
Open source makes a huge difference when your product is intended to be embedded in your customer's product. When their business depends on yours it's obvious they need to pay you or ultimately suffer the higher cost to them of having to maintain your code-base themselves.
When you're talking about some dinky utility a non-technical end-user may use then you're probably smarter to go the shareware route.
One thing to worry a little about is how to protect yourself from competitors that may try to compete with you using your own code. If you're the sole owner of your core technology and there isn't any significant secret factual information in it then you're probably safe going open source with the appropriate licensing.
We do have a number of companies that depend on our software for some pretty core processes within their businesses. Still, because our software is stable, over time the value of an under-used support contract goes down in their eyes. In several cases, they simply haven't renewed support because the product didn't need it. So we only really hear from them when upgrades are available for them. So I'm hesitant to recommend a support-based business model for that reason (unless they're making unstable software ;), and for the fact that most software falls outside of the "core business process" category, which would likely make support a really tough sell.
There's where subscription-based services shine, because support is expected with it, but it's distributed over exactly one installation instead of hundreds, so fixes are made once and apply to everyone. This way you're essentially selling access to the software plus support over time, making residual income, and cutting down the amount of effort it takes to support many customers.
While that's not the right model for every type of software obviously, many companies have shown it can be made to apply to a surprising number of cases you wouldn't think it suitable for at first :)
There's where subscription-based services shine, because support is expected with it, but it's distributed over exactly one installation instead of hundreds, so fixes are made once and apply to everyone. This way you're essentially selling access to the software plus support over time, making residual income, and cutting down the amount of effort it takes to support many customers.
While that's not the right model for every type of software obviously, many companies have shown it can be made to apply to a surprising number of cases you wouldn't think it suitable for at first :)
That makes a lot of sense and fits in with some of the experiences I've had. In fact a lot of large companies don't want to be in the business of code development if they can help it. It's just not their core business. What they would want is open source or open apis so that they can integrate into their infrastructure on their own terms.
I've written at length about this in the past:
http://inthebox.webmin.com/open-source-and-business-a-precar...
And here at HN:
http://news.ycombinator.com/item?id=131662
http://news.ycombinator.com/item?id=81351
And many more. I'm on my second Open Source based business, and I think we've found a combination of factors that's going to be successful this time around: Huge and rapidly growing market, our Open Source offering is uniquely capable of filling niches that have never been served before, and...we offer a proprietary product on top that makes it really clear (to investors, to our customers, to our Open Source contributors) where and how we make money.
http://inthebox.webmin.com/open-source-and-business-a-precar...
And here at HN:
http://news.ycombinator.com/item?id=131662
http://news.ycombinator.com/item?id=81351
And many more. I'm on my second Open Source based business, and I think we've found a combination of factors that's going to be successful this time around: Huge and rapidly growing market, our Open Source offering is uniquely capable of filling niches that have never been served before, and...we offer a proprietary product on top that makes it really clear (to investors, to our customers, to our Open Source contributors) where and how we make money.
We decided to write our new architecture from scratch as an open source project to support our commercial business offering (online storage and backup). There are several factors to consider, roughly in order of importance (according to me):
* target audience
* marketing advantage or disadvantage
* peer review importance
* publicly enforced project management
* contribution from open-source community
Our target audience is composed of consumers who want a simple product to backup their computers and a more sophisticated audience that wants to design and maintain their own distributed backup service. For the consumers, open-source isn't necessarily a plus or minus (see marketing below) but for the more sophisticated users (enterprise IT folks) open-source is great if they need to make modifications for their special needs.
Similar to above, marketing your project/product/service as open-source may be very attractive to some audiences (enterprise IT, hackers who want their own storage grid), irrelevant to some (consumer PC user), and negative to others (some investors, some potential buyers).
One very strong benefit that we've received is peer review by experts in the field. Because our system must securely and robustly store sensitive information, the more people who read through our design and implementation and comment on it the better. Several design and implementation suggestions have helped us fix or improve our system immensely.
Because our project is open-source the peer pressure placed upon good design, documentation, and code is much higher than in my previous experiences with proprietary software. Though not perfect, it means that our team has worked hard to make the system usable and not pushed off important items that might not be visible to a busy project manager.
Code contribution has not been a major focus of our project, though we have received several very good additions to our project. I believe (but not backed up with data yet) that our particular project does not lend itself to large amounts of people coding on it as it is not (yet) a platform.
Hope this helps, Peter
Our target audience is composed of consumers who want a simple product to backup their computers and a more sophisticated audience that wants to design and maintain their own distributed backup service. For the consumers, open-source isn't necessarily a plus or minus (see marketing below) but for the more sophisticated users (enterprise IT folks) open-source is great if they need to make modifications for their special needs.
Similar to above, marketing your project/product/service as open-source may be very attractive to some audiences (enterprise IT, hackers who want their own storage grid), irrelevant to some (consumer PC user), and negative to others (some investors, some potential buyers).
One very strong benefit that we've received is peer review by experts in the field. Because our system must securely and robustly store sensitive information, the more people who read through our design and implementation and comment on it the better. Several design and implementation suggestions have helped us fix or improve our system immensely.
Because our project is open-source the peer pressure placed upon good design, documentation, and code is much higher than in my previous experiences with proprietary software. Though not perfect, it means that our team has worked hard to make the system usable and not pushed off important items that might not be visible to a busy project manager.
Code contribution has not been a major focus of our project, though we have received several very good additions to our project. I believe (but not backed up with data yet) that our particular project does not lend itself to large amounts of people coding on it as it is not (yet) a platform.
Hope this helps, Peter
LiveJournal seems to have done well by open sourcing their product and charging to host it. Even though a lot of baby LiveJournals have sprung up, LJ still has 15 million users. The social aspect has probably helped a lot by making it harder to leave.
Are there other companies that have succeeded with this model?
Are there other companies that have succeeded with this model?
If I was going to be devil's advocate, I'd point out that LJ is an also-ran in their category, and that LJ didn't open source until way late in the game. WordPress was open source from day one, and Automattic scored 25+MM in funding.
I seem to remember it being open source at least as early as 2001.
Usually the success stories are products built on top of, or around, open source software. Suites that include support, integration services, and add-ons. Often these companies contribute back to the open source projects, while also keeping some of their own work proprietary. Then charge on a subscription model.
The key is not to remember that Open Source should not be a central business model. It can be part of a broader strategic platform.
To make open source work, you need to either (a) believe that opening up source is not a big competitive disadvantage, e.g. your customers will still come to you for services, consulting etc (the kind of business you can build on top of an open source platform) or (b) have enough of a community where you can go the MySQL route. There you need to be part of the community as someone else has pointed out.
To make open source work, you need to either (a) believe that opening up source is not a big competitive disadvantage, e.g. your customers will still come to you for services, consulting etc (the kind of business you can build on top of an open source platform) or (b) have enough of a community where you can go the MySQL route. There you need to be part of the community as someone else has pointed out.
If you sell to large companies, open source is an awesome business model.
The #1 and #2 problems you have with large businesses is lead generation and qualifying prospects, so that you aren't wasting $5,000-$10,000 of time and expenses on sales leads that don't pan out, or $50,000 going to conferences that won't result in a single sale.
With open source software, the geeks that infest every Fortune 1000 company bring your software in house just to play with it. If you get them to register their email addresses, and you follow up with them inside-sales style, and just 10% of them love what you built, you just converted 100 Fortune 1000 companies to customers.
This is exactly the model SourceFire used. It's not a "strategic platform"; it's a go-to-market plan, pure and simple.
The #1 and #2 problems you have with large businesses is lead generation and qualifying prospects, so that you aren't wasting $5,000-$10,000 of time and expenses on sales leads that don't pan out, or $50,000 going to conferences that won't result in a single sale.
With open source software, the geeks that infest every Fortune 1000 company bring your software in house just to play with it. If you get them to register their email addresses, and you follow up with them inside-sales style, and just 10% of them love what you built, you just converted 100 Fortune 1000 companies to customers.
This is exactly the model SourceFire used. It's not a "strategic platform"; it's a go-to-market plan, pure and simple.
It's not quite "software" (you've already been provided with answers covering that) but Ruby on Rails is open source but still makes lots of money for people, whether in writing books, doing consultancy, and the creator of Rails, David Heinemeier Hansson, could (and probably does) make tons of cash from RailsConf, speaking engagements, endorsements, etc.
Just because Rails costs nothing doesn't mean a big economy can't surround it.. and if you were the creator of the technology, you get first dibs on making that cash.
Just because Rails costs nothing doesn't mean a big economy can't surround it.. and if you were the creator of the technology, you get first dibs on making that cash.
Anyone care to comment on SugarCRM? They have taken on $46M in funding and have a current valuation around $134M.
Actually they are not truly open source - their license is just called "open source", but the open part of their CRM is just a Demo without reports and lots of other neccessary features, so their "open source" is just a marketing, not the reality.
That's a new aspect of SugarCRM. In the past, all of their code was available under an Open Source license...and that Open Source code worked well for a lot of people for a lot of purposes. Just because you need or want the stuff that isn't Open Source doesn't mean they aren't building some "true" Open Source software (and some plugins that are not).
Open Source is a license and a community, and SugarCRM has both. It also has some extensions that are not Open Source, and the fact is, extracting money from Open Source fanatics is like getting blood from a turnip...so they will never be a customer anyway. So, it's about the only model that works for a large class of problems.
However, you still get a lot of benefits of Open Source from SugarCRM: Open data formats and no possibility for them to lock you in; as long as the core always remains Open Source you can never be "stuck" with your business based on an end-of-lifed product, as with some of the mergers in that field over the years, because it can fork if SugarCRM stops being developed for some reason; community of helpful users and developers means that the level of expertise available is high and affordable.
Over 10 years of building businesses based on Open Source software, I've grown to be pragmatic rather than ideological about how best to produce Open Source software and make money with it. I still prefer to produce and use Open Source tools...but I also know that a thriving business-backed OSS project can build thoroughly kickass software at a rate that a purely community-backed project rarely can. It's not impossible, of course, but it's rare and requires several factors to converge: one or more smart developers who need and use the software being developed and who can devote significant time to it, small core of useful functionality that can be implemented and launched quickly, and a large community of users to help support the product so the developer doesn't burn out.
Open Source is a license and a community, and SugarCRM has both. It also has some extensions that are not Open Source, and the fact is, extracting money from Open Source fanatics is like getting blood from a turnip...so they will never be a customer anyway. So, it's about the only model that works for a large class of problems.
However, you still get a lot of benefits of Open Source from SugarCRM: Open data formats and no possibility for them to lock you in; as long as the core always remains Open Source you can never be "stuck" with your business based on an end-of-lifed product, as with some of the mergers in that field over the years, because it can fork if SugarCRM stops being developed for some reason; community of helpful users and developers means that the level of expertise available is high and affordable.
Over 10 years of building businesses based on Open Source software, I've grown to be pragmatic rather than ideological about how best to produce Open Source software and make money with it. I still prefer to produce and use Open Source tools...but I also know that a thriving business-backed OSS project can build thoroughly kickass software at a rate that a purely community-backed project rarely can. It's not impossible, of course, but it's rare and requires several factors to converge: one or more smart developers who need and use the software being developed and who can devote significant time to it, small core of useful functionality that can be implemented and launched quickly, and a large community of users to help support the product so the developer doesn't burn out.
I agree that its'a subject to discuss, however it may be you can find this article interesting: http://www.opensource.org/node/163
You don't stop being open source when you start selling closed-source software. Is GPL'd SugarCRM worthless?
I've been wondering about open source software as a service. Could you make web software, theme it, and offer it as a pay for service. Think amazon or maybe ebay. What would happen if they opened their software.
This is exactly what Wordpress does.
I doubt anything very interesting would happen if Amazon or eBay opened their source, because their internal applications are likely such a rat's nest of interdependencies. It would take 6 mo - 1 year of full time study (i.e. the amount of time it takes a new hire to ramp up) for anyone to even begin to understand exactly how the systems fit together.
Even with the time and energy to learn how their code works, you'd still need to replicate their internal environments to be able to run their apps.
I doubt anything very interesting would happen if Amazon or eBay opened their source, because their internal applications are likely such a rat's nest of interdependencies. It would take 6 mo - 1 year of full time study (i.e. the amount of time it takes a new hire to ramp up) for anyone to even begin to understand exactly how the systems fit together.
Even with the time and energy to learn how their code works, you'd still need to replicate their internal environments to be able to run their apps.
> What is the challenge to make open source software successful in terms of making revenue?
Acceptance in enterprise.
Acceptance in enterprise.
Has anyone from here done it before? Would you make the same decision again to go open? What problems did you come across?