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.