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?]
(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.)
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.
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.
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 firstname.lastname@example.org
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.
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?
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
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.