Since the very start of the Fnk project, I decided it’d be an open source project, as this is usually the approach I take with the stuff I create in my spare time. However, I had also decided this would be done eventually, some time after the project was public, and not at the very start.

The reason for that decision were twofold. First, I had to decide what kind of license to attach to it – either a more permissive open-source license (like MIT) or a more orthodox license (like GPL). While I had not made any kind of decision on that matter, I’m leaning towards GPL, with maybe LGPL for library versions of the Fnk player – this would be the first project I release under those licenses, and the decision is not that easy.

The second reason, and probably most important one, is that I’m simply not a very good open source author. It’s not that I’m completely ignorant of what it is or how it works – I have created open source two projects (MC Tween and Tweener) that have been quite successful, and I had no problem in releasing some other stuff I created as open source code.

The problem, instead, is that I don’t know how to actually run an open source project with more than one people; it’s fairly easy for me to release and update my own stuff, but when it becomes bigger, and people start making requests, or contributing code, or sending suggestions or bugfixes, I’m just out of my league and I don’t know how to deal with the centralization of control and how to manage people under those circumstances. To put it another way, I’m just a bad open source project leader. Even my knowledge of the available tools (CVS/SVN, issue/goal tracking) at administrative level is pretty rudimentary and tend to be restricted to what contributors know.

While I’m not holding my breath over anything, there’s a chance that more people will want to contribute to Fnk, either with bug reporting and suggesting, or with new code for bug fixing or new features. Under that scenario, my fears are that I would not know how to properly deal with them – specially with how to make the project gears spin well enough for the project to work with more than one author contributing to it with no delays. The project has never been about making Fnk’s code public (although it does have its problems currently), but what to do with feedback I could from it.

Because of this, I’ve been researching a bit and reading about how to properly run open source projects before I can make Fnk’s source public. Specially, I have been reading Karl Fogel‘s freely available book, “Producing Open Source Software“, found thanks to this page. And I have to say, it’s been pretty enlightening. Not only does the guy write pretty well, but the book talks about all aspects of free and open source software, including providing historic and contextual information about what’s discussed.

This is what this post is about. If you’re unsure about what open source software is about, or about how you can make a successful open source project, go check the book out. It is rather long, but you can skip some parts you already know and go straight to the topics you are curious about. I’m mostly focused on the technical management issues, and it’s been pretty good so far.