Why You Should Open-Source Your Startup(blog.codecombat.com)
blog.codecombat.com
Why You Should Open-Source Your Startup
http://blog.codecombat.com/why-you-should-open-source-your-startup
34 comments
I made the switch to OpenCombat, it's based on the same open source software, but without the spammy ads.
:) Too funny! Just wanted to explicitly comment in case someone who's just skimming this doesn't realize you're joking.
(And I see that the mangled link that was pointing at a version of the page with a dialog box was fixed. Sorry again for that screwup! Totally my fault for submitting the wrong URL.)
(And I see that the mangled link that was pointing at a version of the page with a dialog box was fixed. Sorry again for that screwup! Totally my fault for submitting the wrong URL.)
Love this so much, and it's absolutely persuasive. My startup -- http://beeminder.com -- has been on board conceptually for a while and the only thing holding us back, for now, is the initial work required (as Nick puts it in the article, "writing documentation, automating the developer setup, filing easy issues, paring down the repository, and preparing licenses").
Here are some other costs to consider, courtesy of Yehuda Katz:
1. Reviewing all of the code that you want to open source for secrets that could compromise security.
2. Improving parts of the code that are embarrassing or too coupled to infrastructure that isn't going to be made open source.
3. Additional communication overhead for communicating with the open source community so that contributors don't do work that you're already working on.
4. Time spent triaging and working with features that may not have been high internal priorities (or risk pissing off the open source ecosystem).
5. A general willingness to cede control over the precise direction and priorities to a larger group of open source people.
Aaron Parecki adds:
6. Support costs of helping people get their dev environments set up.
But Yehuda, obviously, is in favor of open-sourcing as long as you understand those costs, and lists these advantages, most of which the article also notes:
1. Gaining additional contributions from open sourcers that would have been expensive or technically impossible to do in-house.
2. A vibrant community of people that are interested in the product, its direction, and are knowledgeable in the implementation.
3. People willing to do cleanup work in order to become familiar with the project and become contributors.
4. Getting insight into product direction by people willing to put their money where their mouth is and dedicate time to implementation (this is the flip side of some of the negative above).
5. A recruitment pool that is already familiar with the product and its implementation.
Here are some other costs to consider, courtesy of Yehuda Katz:
1. Reviewing all of the code that you want to open source for secrets that could compromise security.
2. Improving parts of the code that are embarrassing or too coupled to infrastructure that isn't going to be made open source.
3. Additional communication overhead for communicating with the open source community so that contributors don't do work that you're already working on.
4. Time spent triaging and working with features that may not have been high internal priorities (or risk pissing off the open source ecosystem).
5. A general willingness to cede control over the precise direction and priorities to a larger group of open source people.
Aaron Parecki adds:
6. Support costs of helping people get their dev environments set up.
But Yehuda, obviously, is in favor of open-sourcing as long as you understand those costs, and lists these advantages, most of which the article also notes:
1. Gaining additional contributions from open sourcers that would have been expensive or technically impossible to do in-house.
2. A vibrant community of people that are interested in the product, its direction, and are knowledgeable in the implementation.
3. People willing to do cleanup work in order to become familiar with the project and become contributors.
4. Getting insight into product direction by people willing to put their money where their mouth is and dedicate time to implementation (this is the flip side of some of the negative above).
5. A recruitment pool that is already familiar with the product and its implementation.
Thanks dreeves, I don't have a bunch to add to this list, as we've found it to be pretty comprehensive, but we really appreciate the support!
I think better insight would be derived from analyzing when you should not open source your startup. Where would Microsoft be if Windows and Office were open source and companies could get them for free?
IMO, it makes sense when your strategic advantage is in your community and the service/convenience of hosting the app for people. If your advantage is in your algorithms, I don't think it makes sense, unless you plan to make your money from consulting/enterprise/hosting.
And even then, look at how many general computer repair shops are competing against Cononical for "professional Ubuntu support".
Joel's article from 2002 is highly relevant here http://www.joelonsoftware.com/articles/StrategyLetterV.html
In 1999, Eric Raymond wrote about this in chapter 6 of his book The Magic Cauldron: "Reasons for Closing Source": http://www.catb.org/~esr/writings/magic-cauldron/magic-cauld...
I would be extremely interested in that analysis, but sadly we don't have the data to make any interesting conclusions about big products like that. Our preliminary analysis suggests that for products even several times larger than ours, it still makes a lot of sense to at least seriously consider it.
Parent brings a good point: How do you define your strategic advantage, when you're nullifying the one of your code? It's hard to come to investors if you say "Anyone can make exactly our software within minutes". Do you have Android-like trademarks which would prevent others from doing it?
note that you can open source part of your code, and keep other parts private -- many companies are quite comfortable exposing the user-facing parts of their system without explaining all of the backend
We try to keep things modular and so we open source components and various things in our software that might be of general use. Likewise we try to send pull requests back on components that we use. Several of us have our own open source projects as well so we're very much into open sourcing code.
But, I honestly don't see a ton of value in open-sourcing the entire codebase as-is for my company. Not that I would worry about people stealing our ideas, because like most businesses ours is about relationships, support and various other things rather than the "secret sauce" in our code. I just don't see anybody bothering to contribute since our customers are not programmers (not even very technical in many cases). I have no idea why any programmer in his/her right mind would want to go through our product to fix bugs or add features.
I can see it being a different thing if your product is aimed at other developers and/or it has a broad appeal. If there are developers who would be interested for some reason to participate, then I can see it being a great thing. I just don't think it's necessarily helpful for every company.
But, I honestly don't see a ton of value in open-sourcing the entire codebase as-is for my company. Not that I would worry about people stealing our ideas, because like most businesses ours is about relationships, support and various other things rather than the "secret sauce" in our code. I just don't see anybody bothering to contribute since our customers are not programmers (not even very technical in many cases). I have no idea why any programmer in his/her right mind would want to go through our product to fix bugs or add features.
I can see it being a different thing if your product is aimed at other developers and/or it has a broad appeal. If there are developers who would be interested for some reason to participate, then I can see it being a great thing. I just don't think it's necessarily helpful for every company.
I like open source and I understand you have to make a business case for it but this just feels depressingly like "Open-source your startup so you don't have to pay for employees"
Definitely understand the sentiment there, but at least for us, it's not working out like that. Our first contributor is also our first developer hire, and we have another contributor we are negotiating with to have him do some contract work for us. If anything, it's encouraged us to hire more.
Our move to open source is basically a statement that the people behind a product are where the value is actually built, and so from our perspective, it is of the utmost importance to treat people fairly. If you have any experience with running a big open source project, I'd love to chat with you to see if there are any non-obvious pitfalls we can avoid. You can email me at [email protected]
Our move to open source is basically a statement that the people behind a product are where the value is actually built, and so from our perspective, it is of the utmost importance to treat people fairly. If you have any experience with running a big open source project, I'd love to chat with you to see if there are any non-obvious pitfalls we can avoid. You can email me at [email protected]
What's depressing about that? If people feel they want to voluntarily contribute, how is that not a win-win?
I think he's just bringing up the very real point that we're a for profit company, but accept free work from highly skilled developers. We are almost hyper aware of the need to balance the community and company profitability. The last thing we want is for people to feel exploited, and we think that we can be transparent enough to make that work. But to ignore the risk entirely would be hubris. :)
I open sourced my startup a few months ago (logicpull.com) and it ended up opening up a lot of doors for me. Definitely glad I went that route.
Hey Abeiz, would love to chat with you about your experience if you have time, you can reach me at [email protected].
If I were running a startup like youtube or airbnb should I open source? The problem of clones seems to be quite big (they all already have clones).
The product for YouTube and Airbnb is the community, not the actual code. Although for YouTube they might want to keep some of the video processing stuff to themselves. As for Airbnb a clone wouldn't take it down because the community is the product. Same can be said of Craigslist.
This is basically the same thing as saying you can't open source until you're firmly in the lead?
No one will see the value in doing what you're doing and want to clone you until then. Even if someone saw the genius in your approach early on and decided to clone you and start competing with you, you have to be confident that your version of your idea will continue to be better than their version. You still have all the advantages of branding, community, and users, whereas their version has no advantages except perhaps a lower price (which doesn't apply to many products, like your AirBnb and Youtube examples).
Obviously I'm biased, but I think this is actually a good method of selecting startup ideas. If open sourcing the code removes most (or all) the value you propose creating, that's a warning sign. Eventually companies thrive by automating tasks with code, but most early stage companies don't provide most of their value in that way. With CodeCombat we intend to either monetize through paid content or recruitment. In either case, having the codebase be open source doesn't impact the value add.
> If open sourcing the code removes most (or all) the value you propose creating, that's a warning sign.
I tend to disagree here: if source code provides your core values, that is a good sign for a healthy business opportunity. Creating your own competition (by open sourcing it) might make sense in some scenario, but it is not a universal good.
I tend to disagree here: if source code provides your core values, that is a good sign for a healthy business opportunity. Creating your own competition (by open sourcing it) might make sense in some scenario, but it is not a universal good.
We have been open source from the start, but we actually find it really hard to find the time to support contributors to do more than small features and changes. If you have any advice about how to better integrate open source contributors without making it prohibitively time-expensive in terms of coordinating with the core dev team, I would love to hear it!
Even if we got contributors banging down the door tomorrow, I am not sure we could spare the people-hours to properly make use of them - catch 22! Right now most of our community contributions have come in the form of help translating the app (more than a dozen languages now!) which is great, but only one part of the puzzle.
This is our github: https://github.com/loomio/loomio - as you can see we have pretty basic documentation. What would be the most important information we'd need to help people be able to contribute more easily?
Even if we got contributors banging down the door tomorrow, I am not sure we could spare the people-hours to properly make use of them - catch 22! Right now most of our community contributions have come in the form of help translating the app (more than a dozen languages now!) which is great, but only one part of the puzzle.
This is our github: https://github.com/loomio/loomio - as you can see we have pretty basic documentation. What would be the most important information we'd need to help people be able to contribute more easily?
We aren't experts, so perhaps we'll eventually run into similar problems, but it seems like supporting a contributor to do something major might just be a case where it doesn't always make ROI on the first feature, but the point is to attract that contributor as a member of the core dev team, since every subsequent major improvement that contributor makes will become easier. We are trying the wizard avatars for significant contributions to try to motivate people to really join the Archmage team.
The other ingredient might be excitement to do things. People will spend more time figuring out how to make changes they care about if they're psyched; if they just want to fix some bug, they'll give up more quickly and need more time from you. So highlighting some cool things to do might help. I notice that you link to small tasks issues, but don't have any open right now. Always taking the time to write good issues that explain how to do a thing, even if you think you'll probably do it and aren't planning on doing it soon, is a good practice, because it'll be easier when you go to do it, and some contributor might see that and get inspired–then they'll know how to do it instead of needing to ask you where to start. Here's an example where I wrote up a lot of info on how to do a task and a contributor put in a lot more time to finish it afterward: https://github.com/codecombat/codecombat/issues/23
The other ingredient might be excitement to do things. People will spend more time figuring out how to make changes they care about if they're psyched; if they just want to fix some bug, they'll give up more quickly and need more time from you. So highlighting some cool things to do might help. I notice that you link to small tasks issues, but don't have any open right now. Always taking the time to write good issues that explain how to do a thing, even if you think you'll probably do it and aren't planning on doing it soon, is a good practice, because it'll be easier when you go to do it, and some contributor might see that and get inspired–then they'll know how to do it instead of needing to ask you where to start. Here's an example where I wrote up a lot of info on how to do a task and a contributor put in a lot more time to finish it afterward: https://github.com/codecombat/codecombat/issues/23
Thanks very much for the advice!
This assumes you are not solving hard algorithmic problems, but I certainly agree the open sourcing certain components can be very valuable - you can get more customers if others are extending your work and of course you attract consulting work. Providing a good, usable SDK is a good meeting point.
It's reassuring to know that a product or service your relying on is open source.
Specifically, you get a bunch of benefits: if the provider goes away, you still have the source and the right to fix it. You can hire in a competitive marketplace to have changes made. When you find a bug, you can fix it. When the documentation is unclear, you can read the source. When other people make improvements, you get to reap the benefits. Support often comes from people who actually wrote the code that perplexes you.
Finally, licensing costs are zero, and support costs exist in a competitive marketplace. If you've ever been stonewalled by Oracle or Microsoft refusing to acknowledge that a bug exists, or worse, acknowledging it but marking it WONTFIX, this is worth more than all the other advantages put together.
From a user's point of view, open source is a win all the way around.
I have to say, though, that not every startup is best served by open sourcing all of their work.
Finally, licensing costs are zero, and support costs exist in a competitive marketplace. If you've ever been stonewalled by Oracle or Microsoft refusing to acknowledge that a bug exists, or worse, acknowledging it but marking it WONTFIX, this is worth more than all the other advantages put together.
From a user's point of view, open source is a win all the way around.
I have to say, though, that not every startup is best served by open sourcing all of their work.
So now it looks like the CodeCombat blog is doing some crazy spammy thing with popups when you hit the site. Could a moderator fix the URL?]