Yet Another Review: The Book "Producing Open Source Software"

Running an open source project is not at all what I expected. I started out with one small open source project, Microlog. I have now founded several other projects and the Microlog project has grown. As the time has passed a lot of decisions has to be made, ranging from pure development issues to questions about how to handle project members. Finally I started to think along these lines; "There must be someone who has been running an open source project and written a book about it". Most book that I found was related to license issues. However I found one book that seemed to fit my purposes which is "Producing Open Source Software" by Karl Fogel. I have finished reading the book and I would like to tell you my opinions and thoughts about this book.

The book starts with guidelines how to start an open source project when you have some code that you want to share. Although I have started several projects, the book gave me insight into several issues that I have not been aware of or neglected. The author goes through all the documentation that is needed to get started. The list is comprehensive and contains some documentation that I have missed out, for example developer guidelines. Fortunately most of the documentation seems to be in place for my own projects, even though there are some subjects missing. Consequently I think that I will spend some time on improving the documentation. I will keep the book nearby to get everything in place. The next part is " Technical Infrastructure". As the name implies, this goes through how to setup things like mailing lists, forums etc. The books briefly mention canned hosting, such as SourceForge, but I would like to get more information on the subject. This is one the weak spots of the book. There are millions people out there running a project on SourceForge, or a similar site. The "Social and Political Infrastructure" is by far the most interesting part of the book. The expression "Benevolent Dictator" is explained, which is the final decision-making authority within the project. Since I am more or less the benevolent dictator in the Microlog project, I really enjoyed reading this part. I found myself laughing and people on the bus looking like a was from Mars or something. The next subject in line was "Money". This was totally new for me since none of the projects that I am involved are sponsored by a company, but they are only spare time projects. The author on the other hand is one of the founders of the Subversion project, which is sponsored by a company. This part is well written and it seems that the author does know what he is speaking about. What I am missing is a part on how to fund a project that started out as a spare time project. This is one of the questions that I was looking for an answer to. So I guess that I will have to find the answer elsewhere. The "Communications" part describe how you should handle the communication within the project, including how to handle rude people or people that are creating to much noise in the forums. Not one of the most interesting subjects in the book, but still worth reading. The part about "Packaging, Releasing and Daily Development" was rather familiar to me. In the era of Agile development, this is of great significance. If the "daily development"-part is not working correctly, the project runs a big risk loosing developers. The users may abandon the project if the release process is not working the way it should. Imagine if your project has an unclear release strategy, or the version numbering is dodgy. Managing volunteers is not always as easy at it would seem. To learn this, you should read the chapter with the same name. The last part of the book covers a subject that in itself could fill a whole book; "Licenses, Copyrights and Patents". This is the motivation for keeping the chapter short, the author only included a short introduction to the subject. If you wish to deep diver into this subject, choose a book on the subject.

For those of you who have not started an open project, I think that this book is a very good "getting started guide". For people like me that is already running a project, the book gives invaluable tips. Even people that are participating in open source project could get something out of this book, even though this is not the primary audience. One last thing to mention, the book is under open copyright. In other words you could download it and distribute is as you like. Nice!

Short Review of "The Productive Programmer"

I have just finished reading the book "The Productive Programmer" by Neal Ford. For those it may concern; this is a short review of this book.

The first thing that struck me is that the book was not very thick. In my eyes this is a good thing. I have seen to many bloated books, that does have a problem to focus on the subject at hand. It appears that the book is inspired by the excellent book "The Pragmatic Programmer" by Andy Hunt & Dave Thomas. In fact it is recommended by Neal Ford.

The book consists of two parts; "Mechanics" & "Practice". The "Mechanics" part is about the tools you should use, and some tips & tricks on how to use them. For example, there are examples on how you could use Ant for more than building your software. The section "Focus" is the most interesting section. This is where you learn how to kill distractions, something along the lines of "Gettings Things Done" by David Allen.

The "Practice" part contains some best practices that Neal consider important to know, like Test Driven Design. I really like the YAGNI section, where YAGNI stands for "You Ain't Going To Need It". This part is all about a problem that many developers has encountered, namely speculative programming. For example, a class that contains "good to have"-methods, that is there to be future proof. The leason is; do not add anything that you do not need because "You Ain't Going To Need It". This is not something new, but it is still a common problem. Another section of the "Practice" part is the "Ancient Philosopheres". Neal uses ancient knowledge and adopts it software development. This is an unusual approach that I really liked.

If you want to be a more productive programmer, this is a good start. The book is short and easy to read. No fluff, just stuff kind of book.