Open source

Can a startup based on open source code be as disruptive as a close code?


June 2nd, 2015

Open code has advantages and drawbacks. 
Can a disruptive and innovative startup be build using open source?
Can a patent be issue based on open source code?

Paul Paetz Startup Advisor, Consultant in Disruptive Innovation, Adjunct Professor

June 3rd, 2015

Market disruption has little to nothing to do with technology or how it is implemented, UNLESS the market you are targeting to disrupt is a b2b technical market to which the source code and how it is written is core. In all other cases, technology is a feature that supports disruption, and the business model, design, and product and marketing strategy are all critical. Even with the exception noted above, it is still possible to disrupt in many cases based on the business model alone.

If you seriously are intent on disrupting, first make sure your product is solving the right problems for the right people. How you do it is not relevant, as long as nothing you do subverts your ability to price correctly, reach your market, or defend the novel elements of your business model.

I know this is high-level, but since you haven't provided any details about your solution, that's the best I can offer. Feel free to ping me for clarification or expansion of any of this.

Others have answered the patent question perfectly well.

Nick Gray Co-Founder / Sales / Data Architecture

June 2nd, 2015

IMHO it makes little difference if your code base is open source or more proprietary with regard to a product's potential disruptive value. 
Indeed an open source CMS (such as Drupal) should significantly shorten development time. 
A start-up's ability to be innovative or disruptive will come down to the unique features and novel approaches which the final product employs.  
I would think that you would seek to patent actual innovations (for example unique algorithmic processes) rather than a generalised code base.   

Karl Schulmeisters CTO ClearRoadmap

June 2nd, 2015

Depends on what you are disrupting.

If you are disrupting how a particular piece of core software technology works - then Open Source, which requires you to republish the derivative work - makes such disruption harder.  Think about what Tivo had to do to build its video player on Open Source.  Essentially they had to build a generic video driver and storage using the open source stuff  - and publish that back. 

THEN they had to build a separate device driver for video and storage completely from scratch with a different team that did not know or could look at the Open Source source code.  So that they could say "its not derivative so we don't have to republish"

OTOH, if you are disrupting something via business process-  say a building the next Uber - which is basically just a automated dispatch system - then none of what you are writing is "derivative" and hence you don't owe republishing the code.

So if you are looking to patent something that is based on the Open Source technology it self, you cannot.   That's the purpose of Open Source

IF otoh you are looking to patent say the idea of using big data analytics to determine what prices taxi passengers are willing to pay while keeping all your cars fully occupied, that you could use open source for and not have a problem with the patent since you are patenting your analytics, and not the code tool


June 2nd, 2015

Dear Karl Schulmeisters,
You got it! It is true that I MUST re-publish if I am developing new code based on open source BUT I am disrupting on the business model!
My solution creates a market by offering people something that they don't know they want it YET!
Global market with several monetization solutions, such as ads, big data, direct revenue and even e-commerce!

Theodore Vaida Founder/CTO at Exact Assembly

June 3rd, 2015

The terms of the "Open Source License" are much more relevant than the service or function. The open license could be as limited as Apple's BSD/darwin license (giving Apple all leverage over deciding what is and what is not open), or as binding as GPL v3.0 (taking away rights of derivative developers to withhold their source code).

Lets turn the question on it's head - why do you think GitHub, WordPress and RedHat/Ubuntu are NOT proof that open source businesses can be disruptive and profitable?

GitHub has disrupted the market for Version Control software, is partly open source, AND makes a solid profit running both free and paid hosting

WordPress is the number one CMS by volume, is completely open source, AND makes a bundle of money with their hosted services

RedHat and Ubuntu own the lions share of Linux installs, operate nearly 100% open source (and RedHat runs a LOT of other software under their banner like JBOSS), and they are quite profitable enterprises.


June 3rd, 2015

Dear Paul Paetz,
What you saying is true if we take the money problem out of the equation! For a startup the technology can be a limiting factor if its cost is quite high from the very start! Sure costs are dropping quite fast, but I think it can be still a limiting factor. As you point out, "as long as nothing you do subverts your ability to price correctly".
Sure disruption comes from providing people with something that they themselves don't know they want it but once present to them they run to it like insects to light in a dark night!


June 3rd, 2015

Dear Theodore Vaida

Sure the licence of an open source code is critical so as not to stuck development or worse! This is probably the worse drawback in open source code if not carefully check prior starting development!

The companies you mentioned are clear cases of success using open source code,. I just wonder if TODAY or in the near future you could do it again? Brands ARE as powerful as anything you can imagine!

Karl Schulmeisters CTO ClearRoadmap

June 3rd, 2015


It takes roughly the same amount of effort to write the code from a "closed source" API as from an open source one.

So if you want to leverage Open Source as your base say for the 25% of your idea that is disruptive here's what you need to do:

  • you sit down and write a full feature spec of what you want to do - highlighting the areas you think are disruptive
  • you then hand this to the dev team that is going to implement on the Open Source platform and have them spec out an API based on the functionality you want, to what they are going to build on open source
  • you then hand this API and the spec of what you want done again with the disruptive areas highlighted - to a second team.  A team that has been hired in part because they have no knowledge of the Open Source code base you are otherwise using.
    • they then write the code to the API spec, 
    • when the Open source team is done you then take their running code and present it as an operational binary to the innovation team
    • they then get to develop and test against the black box
    • if they find any bugs in the black box, they write them up and hand them to you
      • you then take those bugs to the Open Source team and they fix them based on your guidance
      • you then take the fixed code base AS A BINARY back to the innovation team.

mostly this adds a bit of cost in the spec process and in the back and forth on the bugs in the 'black box".    But its not prohibitive.  You just have to be careful with the process.

you can always hire an outside consultant who has experience in doing this (like me :-) )  to help you in some of the crucial points

David Schwartz Multi-Platform (Desktop+Mobile) Rapid Prototyping + Dev, Tool Dev

June 3rd, 2015

I think you may be putting the cart before the horse. First of all, not all open source licenses are the same. They don't all require you to publish your derivative works. So it depends what you're starting with.

Second, consider that Tesla released all of their patents to Public Domain, so they're open source in a sense. So what? Do you have a few billion dollars to compete with them? All they've done is said, "hey, folks, we're not going to waste our time and resources suing you for copying our technology. In fact, save yourself the aggravation and just start from here and build something better! You have our blessings!"

Something that causes a disruption in an industry segment needs to accomplish way more than what simply duplicating some code or IP will do. If Uber suddenly open-sourced all of their code, do you think anybody could conceivably copy them and overtake them? Look at all of the hassles Lyft is having.

And in spite of the fact that Uber and Lyft seem to have access to the brightest and smartest marketers in the known universe, the only thing either of them seems capable of doing to grow their market is to cut fares. If you follow their trajectory, their fares will hit $0 before they've acquired any significant percentage of the population as riders -- at which point, nobody will be able to afford to drive for them.

Neither Uber nor Lyft seem to be listening to their customers or their drivers. In the process, they're driving themselves into the ground by cutting fares, which is increasing driver turnover, many of whom are being replaced by cabbies -- whose personalities are, in large part, what rideshare riders hate most about taking cabs.

I say this to point out that even large incumbents in a market leave themselves open to disruption. And it may have nothing at all to do with the technology they're using. Whether Uber open-sourced their tech will make no difference if they don't come to the realization that stemming driver turnover (due in large part to cutting fares) is not a healthy strategy to long-term growth -- because they cannot cut fares enough to expand their market while simultaneously keeping drivers happy.

Brian Reale CEO / Founder ProcessMaker

June 4th, 2015

If you sell software in a traditional sense or even a SaaS concept of software sales, then building and basing your technology on open source will almost always mean a lower valuation for your company.  If, on the other hand, you use open source software and you are using that software to build a service that does not involved selling software (either on premise or SaaS), then it really doesn't matter.