The Cathedral and Bazaar was a very interesting read. The author, Eric S. Raymond, incorporated his experiences with the success of open source code through his Fetchmail application. I enjoyed reading this article because all the numbered lessons were very insightful into the world of open source software development. Lessons such "Good progammers know what to write. Great ones know what to rewrite (and reuse).", ""Plan to throw one away; you will, anyhow."(Fred Brooks, The Mythical Man-Month, Chapter 11)", "When you lose interest in a program, your last duty to it is to hand it off to a competent successor.", "Release early. Release often. And listen to your customers." and Linus's Law, "Given enough eyeballs, all bugs are shallow."
From the aspect of the lesson of "Good programmers know what to write. Great ones know what to rewrite (and reuse)." I find truth in that. Any programmer that is good can think of what to write and then write it themselves. From this they understand the code at hand and can then understand the bugs that come with it. The great programmers can take a piece of a program, analyze the code, understand it, rewrite it and then reuse that piece of a program for that particular program or another program. From this lesson I believe that greater skill come out of rewriting and reusing someone else's code rather than writing your own, in most cases.
The second lesson I found to be interesting was ""Plan to throw one away; you will, anyhow."(Fred Brooks, The Mythical Man-Month, Chapter 11)". A programmer can tackle a problem when working with an open source project, but whether they fully understand that problem is another thing. If that programmer does not quite understand the problem the first time they come across it and implement a solution, then more than likely they will throw that solution away at least once and have a better grasp of the problem next time. Thus, implementing a solution the next time for the same problem will more likely be a better solution.
Every body in the open source world strikes up an interest in a program; whether they are starting their own or contributing to another. Of course, sometimes over the time of a project, developers lose interest and do not wish to contribute any more to the project. In this case, it is better to hand it off to someone else than it is to let it die. If it is a project that will benefit users in some way, letting it die is probably the worst thing to do. Before reading this article, I would have been one of those developers who just let it die because if I lost interest in it then I would not take the time to pass it off to someone else. However, I guess if someone took interest in it before I let go of the project then I would pass it off.
The idea of "Release Early. Release Often. And listen to your customers" is in my opinion a great idea! If you want your software to be successful release it as early as possible, that way users aren't waiting and waiting for the product. This way users can start using and testing it right away and report bugs back to you. While that is happening you can continue working on other features for the software while working out bugs as well. Bugs with this method are easier to fix, because there aren't thousands of lines of code to search through to find what's wrong and you aren't dealing with tons of functionality.
Raymond's dubbed "Linus's Law" of putting more eyes on a project makes bugs look shallow is great. The more people you have with more backgrounds looking at code and bugs, then someone is bound to find a solution to it. After reading that lesson and before reading it from a large scale close source software project, I thought, "Why do more people on an open source project work better than a team on a close source project?". I found that answer with reading onward. In a closed source project, the more people you add, the later the project will be because all the developers talk with each other individually and try to implement things in smaller groups sometimes without consulting others. In the open source world all the co-developers report their solutions and problems to a small group of developers that then handle everything in a centralized manner. This makes me wonder why this open source method is not used in the closed source world?
I found that this collection of essays really brought me into the open source world and how successful it can be. There were a lot of lessons that I will keep in mind when I'm working on software projects for this Banshee product and more projects to come.
No comments:
Post a Comment