As someone who has used lots of open source software, in fact making my livelihood off of open source software, I've often wondered what happens when the guiding forces behind an open source project decide to make that project closed source? Under what circumstances is that even possible.

I'm the lead developer for my simulation baseball league's web site. That is a very small venture, so I often say no to requests for additions and changes because, well, I can. It's okay to be an asshole sometimes instead of just bottling it up all inside. Sometimes I don't feel like putting in the work to implement certain functionality. Or I don't feel like the request adds anything to the web site. But if I were the lead developer for a fairly large open source project, I'm pretty sure I would get to some point where the complainers and moaners would get to me and cause me to want to consider closing the source. It's an easy thing to complain about a bug or missing feature, but it takes real courage to complain *and* go and fix it, showing why and how you fixed it.

So, what would happen if you closed the source? I guess you'd say that you would still accept patches but nobody could distribute or implement those changes without your permission. I believe that Dan Bernstein does this for his immensely popular qmail project and explains that qmail is not open source. I also imagine that the license you release your code under would have a huge impact on this as well. If you took something close sourced, what about all the changes that others had contributed while the project was open sourced? Are they out of luck? Do they remain in the closed source with you giving them credit? Many, many questions to be answered when taking an open source project closed.

The key feature of open source, to me, seems to be that you can get the source, change it, and then distribute those changes. There is nothing wrong with you taking an open source project, make a bunch of your own changes and then using it yourself without distributing those changes. That's how a lot of cool functionality ends up in an open source project. I seem to remember the systems group at a previous employer hacking on qmail and making some changes to it that were only used internally and, although I am not a lawyer, I can't imagine that being a problem. Distributing those changes to others is a different story, as that would appear to violate the license that qmail has been released under.

The perception on many open source projects is that the leadership is running things like a closed source project by limiting access to people to commit their changes to whatever central version control repository they are using. Is that a bad thing? I would have to say no because when a project gets to a certain level of complexity (such as, say PHP itself) you don't want just anyone going in there and making changes that would cause things to break all over the place. CakePHP does exactly that: there is a "core" team of developers who have write access to the subversion repository, and they either change code themselves or go over patches submitted by others, committing them if it's agreed that the patch fixes a problem.

From my own perspective as a developer, I don't know if I would stop using an open source application if it would go closed source. As long as it continued to work the way I needed it, I don't think I would complain too much. But if I needed to make changes and are skilled enough to do so, that's when it would become really annoying if there was a bug I could obviously fix but have no access to do so. My experiences with some PHP applications that were encoded using IonCube showed me how much time and money was wasted trying to get problems that could've been fixed in-house. That's as closed-source you can get in the PHP world.

Tell me in the comments your thoughts on taking an open source project closed and what you think the ramifications of that would be.