Disclaimer: I started writing this text over a year and a half ago, and I’m publishing it now because I got tired of seeing it sitting in my list of drafts. Whether you have free time or not, I suggest that, after reading this article, you go find a copy of “The Cathedral and the Bazaar” and read it. It’s worth it and it’s an easy read. There’s even a Portuguese version, but if you know a bit of English, I suggest reading the original.

I recently read the book The Cathedral and the Bazaar, by Eric Raymond. This text was important in the Netscape Corporation executives’ decision to release the source code of the browser that would become Mozilla (and which has since given rise to Firefox). So it’s a text that is, at the very least, interesting. Throughout it, Raymond presents the “bazaar model” of software development, which he learned by watching the development of Linux, which may not be the best operating system out there, but which has certainly become the most popular free one thanks to this style of programming and to its extremely active community. Throughout the book, Raymond presents the lessons learned that can be applied to the development of a Free Software project. So, let’s get to the lessons:

  1. Every good work of software starts by scratching a developer’s personal itch;
  2. Good programmers know what to write. Great ones know what to rewrite (and how);
  3. Plan for a throwaway version; you’re going to do it anyway (saying it another way, you usually don’t really know a problem until you’ve implemented a solution. The second time, you may know enough to do it right);
  4. If you have the right attitude, interesting problems will find you;
  5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor;
  6. Treating your users as co-developers is the least painful path to rapid code improvement and effective debugging;
  7. Release early. Release often. And listen to your customers;
  8. Given a large enough beta-tester and co-developer community, all problems will be quickly characterized and someone will solve them;
  9. Smart data structures and dumb code work a lot better than the other way around;
  10. If you treat your beta-testers as your most valuable resource, they will respond by becoming your most valuable resource;
  11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better;
  12. Sometimes, the most important and most novel solutions come from realizing that your concept of the problem was wrong;
  13. Perfection is achieved not when there is no more to add, but when there is no more to take away;
  14. Any tool should be useful in the way it’s expected to be, but a truly great tool can be used in ways you could never have expected;
  15. When you write gateway software, do your best to disturb the data stream as little as possible – and never throw away information, unless the recipient forces you to;
  16. If your language isn’t computationally universal, syntactic sugar can be your friend;
  17. A security system is only secure if it’s secret; watch out for pseudo-secrets;
  18. To solve an interesting problem, start by finding a problem that is interesting to you;
  19. Given a communication medium at least as good as the Internet and the ability to lead without coercion, many heads are better than one;

I’m publishing these lessons more as a reminder for myself, but I hope they can inspire other people out there. To finish, another quote from the guy: “Show me your code and hide your data structures, and I shall remain blind. Show me your data structures and hide your code, and I will probably not need it.” (To be honest, I don’t remember where I read this, so the quote isn’t 100% accurate)