A company with a solid open source project competing against a traditional closed-source product seems impossible to beat.

I read this article wherein the author lays out this scenario:

Suppose one could divide a software market—say network management—between two products. One did everything possible and cost $1 million, and the other only did 10% as much, but was free and open.

The price tag of the commercial solution would automatically filter out a large number of users, and those people would have to turn to open source. But some users would be satisfied with the 10% functionality and choose it outright.

For example, I have an original Macintosh computer on my desk. It runs a word processor called MacWrite. It does everything, with the exception of spell check, that I need a word processor to do. I can format paragraphs, choose fonts, make text bold or italic, and even paste in pictures and graphs. All in a "what you see is what you get" user interface.

It takes up 76K of disk space. That's "K" as in "kilobyte."

Compare that to Microsoft Word. I think the last time I installed just Word it was around 30MB, many times larger than MacWrite, but I don't use it for much more than I use MacWrite. Like me, many users are happy with basic functionality. They don’t need all the bells and whistles.

But back to my analogy. In the beginning, the commercial company would probably ignore the open source project. It represents no threat to their revenue stream, so why should they pay attention to an upstart?

If this project is healthy and sustainable, however, in a year or so perhaps it does 15%-20% of what the commercial product does. This should bleed a few more users from their business, and maybe now they start to pay attention.

Most likely, this attention would take the form of marketing against the project. They would claim it is too small or too underpowered to take seriously. And in the short run this would probably work. But the mere fact that they acknowledged the project would pique interest. Some people would determine for themselves that it was neither too small nor too underpowered and would start using it.

Another year or two goes by and now the project is up to 50% of the functionality of the commercial product. People start joining the project in droves. The commercial company now has to do something. What do they do? They add more features.

Remember, the commercial product already did 100% of what people needed. So what kind of features could they add? Unnecessary ones. They might change the look of the user interface or add features outside of network management. In any case, this development will cost money, and that will start to eat into the company's margins.

Finally, with a healthy community and this influx of new users, the open source project will eventually approach 80%-90% of what the commercial product does. Having exhausted all avenues of generating revenue, the commercial company still has one final option: put the screws to their remaining customers. Find ways to charge them more, to eek out what they can from their investment, which ultimately will drive their clients away.

Farfetched? I don't think so. There are only two main requirements:

First, find a market where open source provides a compelling alternative, such as network management.

Second, build a sustainable community around the open source project.

It seems very plausible. If you were the closed-source company, how would you compete??

  • 2
    Commenters: comments are meant for seeking clarification, not for extended discussion. If you have a solution, leave an answer. If your solution is already posted, please upvote it. If you'd like to discuss this question with others, please use chat. See the FAQ for more information.
    – user8
    Commented May 25, 2011 at 22:06
  • 8
    In a subjective answer like this, some of the best information is in the comments.
    – richard
    Commented May 25, 2011 at 22:31
  • sue the users of the open source product en.wikipedia.org/wiki/SCO/Linux_controversies
    – Ewan
    Commented Feb 24, 2016 at 15:59

15 Answers 15


Since you can't compete on price, then compete on all of the other selling points that the software has:

  • features
  • quality
  • effectiveness
  • integration with other software
  • service
  • support
  • direct selling

Basically, you do what every other company does when they're in price competition: keep pace, or change the game.

  • 2
    +1 for "Change the game", if you cannot beat your opponent on its terms, then you just have to find terms that suit you more. Commented May 21, 2011 at 14:42
  • 1
    Once you start having an open source competitor which is actually worth paying attention to, a good way to think of business strategies to use is to pretend that you're about to open source your project, too. Change your business so it will stay profitable under that condition, and you're in the clear, whether you've actually open sourced it or not Commented May 21, 2011 at 22:07
  • I would add : Ask "who runs the asylum"? Don't let the in mates run the asylum. If it's programmers, the inmates are.
    – mattnz
    Commented May 24, 2011 at 0:18
  • I think change the game did it for me. I think that's all you have in the end.
    – richard
    Commented May 25, 2011 at 22:32
  • 1
    Of course, you need to prioritize your efforts, and I think they're backwards in this list. Open source can probably compete on features, quality, and effectiveness, and sometimes on integration with other software, but service, support, and sales are weak points in open source, and important points for Big Co. markets. Commented Jul 18, 2011 at 3:10

By making your product better than the open source offering. That's how Photoshop can compete with GIMP.

  • 2
    So it's sheer resource domination?
    – richard
    Commented May 21, 2011 at 2:52
  • 12
    No - resources don't necessarily make a better product.
    – Stephen C
    Commented May 21, 2011 at 3:03
  • 5
    @TheLQ: Applications like Notepad++, EditPad Pro, even Emacs/Vim show just how far you can go to differentiate your "text editor" in the market. Commented May 21, 2011 at 3:25
  • 9
    Photoshop is a good example of keeping the clones at bay simply by being a very good product.
    – user1249
    Commented May 21, 2011 at 15:24
  • 4
    There's no such thing as exhausting all possible things you can do.
    – Kyralessa
    Commented May 21, 2011 at 17:55

I think the piece you mention is greatly misleading, in that it completely disregards the quality of the open-source offer. Ask yourself a slightly different but related question:

How can a company survive survive selling open-source software?

Being a frequent contributor to a few open-source projects myself, I feel reasonably entitled to sling a few rounds of mud where it deserves it.

None of what follows applies to star OSS projects such as Linux, Firefox, MySQL or PostgreSQL, mind you. These are untypical, in that they're backed by companies and/or seasoned coders.

Anyway, as to the reasons customer will pay for software:

OSS is prone to feature creep / Customers will pay for simpler software

OSS contributors all have their pet feature. These will eventually find their way into the code base. It takes an extremely seasoned, firm and charismatic leadership to avoid the problem, and like any other guy many an OSS core dev lacks at least one of these traits.

Adding insult to injury, for every non-essential feature that creeps in, another won't want it and this will result in adding options. Coders tend to love options, but from a UI standpoint they are a sure path to a slow and painful death by a thousand cuts.

End-users want simple tools. They need to get their job done with no learning curve or fuss. They want their tools to make the right decisions for them; not options. If you can deliver something simpler than the standalone OSS implementation, you'll get paying customers.

OSS tends to be of low quality / Customers will pay for higher quality

There's nothing inherently wrong with learning to code by contributing to OSS, mind you.

It must be said, however, that for every high quality OSS or library that is backed for all sorts of reasons by corporations and seasoned coders, there is a ocean of bug-prone spaghetti code written by inexperienced coders who are contributing OSS in an effort to learn programming, and who have little if any idea of what they're doing.

WordPress, for instance, was forked from B2 (itself designed by a student) by a student. Multiple versions and untold amounts of duct tape later, it gets the job done. But under the hood, it is a deluge of bugs with little if any quality control. (Last I tried, it did not successfully pass its own test suite.)

Customers will pay for well-maintained and well-tested software. They'll almost all try the free stuff, mind you, and many will even tolerate bugs up to a point. But if their revenue depends on it, they will eventually seek out higher quality software and pay for it.

OSS tends to have too short a development cycle / Customers will pay to avoid hassles

This is inherent to the development process. Pet features that get shoved into the code base need to be released in a reasonable time scale. If they're not, the risk is that the OSS project will lose some of its contributors.

In the long term, however, companies prefer long release cycles; the longer, the better. It's less planning and less work for the IT department. It's no big deal if end-users upgrade their browser every three months or so. It's a completely different story if you're upgrading mission-critical applications.

There was a recent discussion on accelerating the release cycle in the PostgreSQL hackers list. The closing argument against was not about the QA and need for extended beta-testing periods. It was that some companies were already skipping every other release, because the current (1-year) release cycle was already too fast for them.

Contrast with WordPress, which is debating a 3-months release cycle every now and then in spite of an already too short cycle. (Their betas are, for all intents and purposes, the x.y.0 version of each release.)

Having a few customers who use WordPress, I can assure you that they're more than happy that I'm looking after them to ensure that their sites don't blow up in their face when they do upgrade. Customers will pay for not needing to worry this kind of hassle.

OSS tends to mindlessly embrace open standards / Customers just need things to work

The HTML5 video tag is a case in point here.

Mozilla's case for rejecting h.264 is that they want an open source codec. And they're absolutely correct in this sense: the last thing they want, is to be on the hit list of patent trolls; so they push for Ogg.

Apple's case for embracing h.264, by contrast, is practical: it's widely supported already, and there's hard-ware acceleration for it (thus allowing to extend the battery life of iPhones); there's no such thing for Ogg.

Millions of iOS devices sold later, sites worried about delivering video to these iOS users support html5/h.264. Put another way, customers have spoken: they do not care about open formats.

The only company that is happy with the outcome of this venomous battle over codecs is Adobe: Firefox users will, de facto, continue to need Flash if they want to play videos. If a major site switches to html5/h.264-only videos, a coder out there will quickly come up with an extension or plugin to convert the needed video tags into flash video players. (It might even exist already.) In the name of supporting open standards (which flash, incidentally, is not).

Nobody ever got fired for choosing IBM

It's an old industry joke, but there is truth in it: when wielding an IT budget, you won't get fired for choosing what peers consider the best of breed.

Large corporate buyers who don't feel like taking a risk will continue to buy Microsoft-based desktops, Office, SAP, and what not; even if there are open source alternatives. Much like shit happens.

When OSS makes its way into large corporate environments, it usually isn't because the CTO saw the light and decided to go with cost-free tools; rather it is being channeled in by a third party who offers (pricey) services on top.

  • 3
    "OSS tends to have too short a development cycle" but if you're using OSS you don't need to keep pace with the latest development, you have the choice to use old version indefinitely and upgrade only when it makes sense to your business. With closed source software, depending on the licensing term, this is sometimes more difficult. Also, if an open source software stops supports for an old version, you have a choice to fork the old version and fix bugs/security issues yourself. With closed source, you don't have that choice so you either upgrade or stuck with the bug forever.
    – Lie Ryan
    Commented May 21, 2011 at 13:06
  • 5
    "Nobody ever got fired for choosing IBM" But what if the best of breed software in the industry is an open source, say, Apache? or, perhaps in a few years, if Android is to beat Nokia?
    – Lie Ryan
    Commented May 21, 2011 at 13:07
  • 2
    You don't have much choice to choose old versions indefinitely when they've security holes. Try installing WP 2.3 on a web server and see how it is before a bot finds it and hacks it. And no, duct tape (i.e. back-porting security fixes) is not a reasonable option for Joe Average. With OSS you're forced to upgrade or be stuck with bugs forever too. Commented May 21, 2011 at 13:18
  • 2
    @Denis: a Joe Average could theoretically hire a Jack Developer to backport security fixes he need; it might not be the best business decision, but he can (and that's what matters). With closed source, once support stops, the program is frozen forever (one can argue that this is sometimes better, since you just have the simple choice of upgrading therefore you don't need to give chance for an attacker to exploit your program while you're contemplating whether or not to upgrade)
    – Lie Ryan
    Commented May 21, 2011 at 13:35
  • 6
    "OSS is prone to feature creep": Absolutely not. Most OSS programs are tiny do-one-thing-right programs, although their public visibility is lower than the large projects trying to mimic a monolithic commercial competitor.
    – tdammers
    Commented May 21, 2011 at 15:39

I think the crux of the argument, that "the commercial product already did 100% of what people needed" is where the argument falls apart. No product can claim to do 100% of what people need and certainly not in the absolute most efficient (in terms of operator efficiency), easy-to-use and universally accepted "best" way.

If such a thing were possible, then of course the only remaining thing to compete on is price. But since an objective "best" and a universally "most efficient" application is impossible, there will always be more things than just price to compete on.

  • Thanks for bursting the bubble a bit for me. That makes good sense. :-)
    – richard
    Commented May 21, 2011 at 3:00

There are some good points in that article, but then again, real world seems plenty of examples where close-source companies are doing just fine. Here's just a few

  1. Linux vs. Windows
  2. PHP vs. ASP.NET
  3. [something or other] vs. Visual Studio
  4. GIMP vs. Photoshop (it was answered before me, but I really needed non MS example :) )
  5. vBulletin vs. 30+ other bulletin board packages

The problem with open source is that it's open. If you have that code produces product A. All of your competition has the same code. So you spend all this time writing software, granted a portion of it could be done by other contributors, but if you run a company, you are expending resources and yet anyone can come along and start selling exactly the same that you've spent years developing. So biggest threat to an open source company may not necessary be a close-source company, but the other 5 open source companies.

On the other hand if I develop closed-source software, yeah you can copy my ideas but I could still be years ahead of you in developing software and by the time you enter the market, I could already own 90% of it.

Lastly, in general, companies that do not share code but charge for their software, generate more revenue than open source projects. As soon as that revenue is generated, a portion of it is reinvested not in engineering (which you could argue could be free if you have many open-source contributors) but into marketing and promoting the product and now you are talking millions of dollars for which there's no such thing as free labor.

At the end of the day this is the formula for your success: [engineering innovation] x [marketing] = profit. You can have the best product, but if no one knows about it, no one uses it. And clearly if you build something crappy, no amount of advertising is going to save it. I believe many open-source projects have always had trouble with [marketing] when it comes to penetrating general consumer markets.

  • 1
    Most text editors & VS are in separate markets. Commented May 24, 2011 at 0:08
  • @alternative Most IDEs and VS are in separate markets.
    – Andy
    Commented Feb 25, 2016 at 1:56

One area where most open source software can't compete with proprietary software is in the learning curve.

Historically, I've had a hard time incorporating all but a few of the most popular open source software into my toolset. They're usually great when I figure them out, but I typically don't experience this initial frustration with proprietary software.

I'm not sure why this is the case. I can say, however, that I'm more than willing to pay for software that gets the job done with minimal effort on my part. That is the purpose of software after all.

Make it easier to implement than the open source competition and people will pay.

  • different anecdotes, I usually have less problem learning open source software since they often have more manual/documentation and more discussions forum that can be reached from Google. While not all open source software has excellent documentation or aftermarket discussions forums, the ones that do is typically easier to work with than the closed source alternative. For example, I found Python is much easier to learn than Visual Basic .NET. I found more tips and tricks about tweaking/fixing Linux system than I used to have when I was using Windows.
    – Lie Ryan
    Commented May 21, 2011 at 13:16

Usability and features - the one thing that a closed source commercial project wil have that most open source projects don't is the ability to control a strong vision for what the product is supposed to be and do.

This all depends on the size/complexity, but a smaller single-team software product will be able to focus on the market they are trying to appeal to. (That other example - how BBEdit and TextMate are able to appeal to a group of people willing to pay for a text editor given the avaiability of jEdit, gEdit, etc. What does TextMate offer that is attractive enough to get people to fork over $20-$30?)

  • To answer your question - A whole lot of mac-fanboy buzz! I haven't once seen something that truly impressed me in that editor. Commented May 24, 2011 at 0:10

By focusing on specific client problems. Many a times I've seen organizations spend thousands of dollars for 'that one feature'.

As a open source product, they have to focus on masses (unfortunately masses don't buy those 10K+ software), as a close-source for profit organization, if you can satisfy the need of your key/critical customers more business would follow.

As @SnOrfus already mentioned, service and support are critical. I've seen zillions of times, organizations preferring closed source over open source (and even paying extra) to get the comfort of being able to get hold of some one just_in_case!

(this might be a bit to corporate client focused)


The commercial solution can rightly claim that its fortune is aligned with its customer's success. This is what product positioning is about. With some exceptions, generally open source tools are generally seen as hacker's heaven, not exactly a customer focussed point solution.

If your customer needs some feature, you have the financial muscle to deliver it on time. You have the capacity to provide 24x7 support (and charge for it), guaranteed fixing of level-0 critical issues, access to new generation technology far earlier than the open source community if you work with OEMs.

Use these to your advantage. Let the free product too be in the market, don't be hostile. If anything, this expands the market -- at some point the users of the free product may want to try the bells and whistles of your commercial solution.


For the sake of simplicity, let's boil down the success factors of a software into three "investments":

(Here, "investment" is a collective term for activities in which you have to pay now, in order to receive revenues later.)

  • sales and marketing
  • development (includes source code, product/UI design, documentation and training materials. Quantity multiplied by Quality. Any work product produced here can be replicated at low cost to unlimited number of users)
  • services (expertise in the software and domain, and the capability to provide value-added enhancements on a per-customer basis)

The KPI for development is simple: can you develop the same thing better and cheaper than others. Part of this is sheer resource investment and the other part is the wisdom of the architect and designers.

For services, having access to the product's source code is a big bonus. A company that doesn't have access to source code often cannot provide the same level of service as another company that has access.

Now back to the OP's question: does a closed-source company have a survival strategy?

The article quoted by OP seems to be self-limiting because it only considers two extremes:

  • A closed-source company develops all source code out of its pocket and has zero lines of open-source code.
  • An open-source company fully embraces the principle and opens up every line of code ever developed.

How about the middle grounds?

  • Several software companies sign cross-licensing agreements to share part of the source code and/or API? (In which one of the party is services-oriented.)
  • Companies which make good use of BSD-style licensed open-source components or libraries (and make in-kind contributions), without opening up the main product's source code?
  • Companies which provide source code of in-progress software through an time-limited "community preview" arrangement?
  • "Available-source": companies which provide source code to paying customers?

My point of view is that companies can survive if they adopt a partly-open, partly-closed source code strategy, and if they do well on all three fronts (marketing, development and services). Companies that adopt a true-to-the-open philosophy can also survive, and they will also have to do well on the same three fronts.

There is a caveat though: if a software is free, will customers choose it over alternatives even if the software did poorly on some of the metrics?

  • sales and marketing: can you promote a product at almost no cost, through viral marketing?
  • development: can an open-source project get most of its design/development/documentation from unpaid volunteers? Can a company reap benefits from such project?
  • services: can a software project revolutionize its software domain to make it very simple, so that everyone can become an instant expert, lowering the entry-barrier to zero?

The open source project is chasing the commercial project in terms of features. This leaves a sort of temporal arbitrage for the commercial company to compete on features. They have to race to implement features constantly to retain an advantage over the open source company. It's expensive, but it can work.

As other people have mentioned, features can include documentation and ease of use.

The corporation can try to instill vendor lock-in, but that only slows down loss; it doesn't gain you any customers.

This leaves two major ways to keep market share: support, and exploiting managerial distrust of open source software. Sadly, the latter's going to get you pretty far. Selling support will work, though, and even when the open source project catches on enough to get a company selling support for it, the commercial solution will have an advantage by being the incumbent and having more experience, and also from an impression that they are more familiar with their product.

In the long term, you're likely to be screwed, but this can make "the short term" into "the foreseeable future".

  • I agree with you. I really think that in the long run, there is no stopping open source. It's just like the music and movie industry...you can stop the masses, and what the masses demand, the masses get. In the case of open source vs closed source, open source will (I think in the long run) deliver the features with the better price and support.
    – richard
    Commented May 22, 2011 at 0:06

One thing no one else has mentioned is documentation. A lot of programs don't really need much to be usable (Firefox, Openoffice), but if you write a library, some sort of server, a programming language, or just a really complicated program, documentation can make yours stand out.

Improving documentation can reduce your users' frustration (making them more likely to continue using your product and suggest using it in the future), and you can advertise that the money is well spent because your customers won't spend as much time coding (and time == money).

This isn't necessarily open source vs. closed source though -- Pretty much everything is poorly documented. It might be that your competitor is in that 1% of projects that document things well, but it's unlikely ;)


Quite simply, the trick is to keep re-defining 100%. FOSS just doesn't have the same scale and manpower of a commercial project, and there are limits to how closely you can compete with an existing product. Closed-source company use UI hooks, so that using a competing product feels impossible due to different, for example, keyboard shortcuts. In addition, they keep adding major features which a FOSS competitor simply could never consider. For example, consider Visual Studio. It was just a C++ IDE, but then they started bundling completely new languages and frameworks, like .NET. Or Visual Studio 2010, which packages a commercial-grade (as in, Intel sell an equivalent standalone) threading library for C++. FOSS just can't keep up with that kind of development, and often, reliability. Where open-source software will win is basic product features for cheap, but in a field of software for experts, I doubt they can make a large dent.


Target traditional enterprise markets and get popular.

For a lot of large traditional companies it boils down to three things:

  • a vendor they can enter into a binding contract with for (capabilities and reliability)
  • a vendor they can contractually enforce a specific service level agreement with (speed quality of support)
  • gartner reviews (this is the modern equiv of "nobody gets fired for choosing IBM)

All three are mindlessly followed, and not particularly valid. Capability issues are always oversold, SLAs always have an excuse and gartner only surveys the kind of people who listen to gartner, but when you are middle management in a corp that has a whole lot of upper-middle management who gets in trouble with upper management when senior management finally hears that there has been a boneheaded decision that has cost a big pile of money you need some documentation from a third party that supports your position if you want to save your job. Even if you know full well that from a technical point of view you are flushing big piles of money down the toilet it isn't worth the risk to try to do the right thing.

How many bad uses of SAP or SharePoint have you seen put up in the industry? How many of those would have been better if they were done on something else that was a better fit, but not a big industry name?

I use lots of Microsoft tools, and I have a MSDN account, but I honestly get better help from MS folks on twitter than I do through the MSDN phone center. I cant imagine I would get worse help from the folks behind and open source project than I do from non-support folks tweeting in their spare time, but that does not enter into the Liability/Gartner equation.


As SnOrfus said sell the features we do it.

Eg: We develop plugins with some common features and make it free for download on Wordpress site. At the same we have our paid version plugin which has pro features.

This helps you to introduce your product to masssive people i.e the power of open source and people.

Not the answer you're looking for? Browse other questions tagged or ask your own question.