Greetings. As you can see, this is my first blog post of the many that will soon follow. This is also my first time writing on a blog based site (I am personally more used to forums as a means of online discussion, assuming the users don't troll and flame in your topics). And what a way to start things off, with a synopsis of a reading.
I am currently in OSD600 at Seneca College. This is a course where a series of students band together and work with Open Source mediums such as Mozilla Firefox and OpenOffice. Hopefully, creating software add-ons to these programs that can be shared across people. But because the code we do is open source, we are required to share it amongst users to As part of our introduction to the course, one of the professors, David Humphery released an essay.
At first I thought - it's an essay, it won't take long to read something (I am one of those people who assumes an essay is about 4 pages with 5-7 Paragraphs with evidence and/or sources). But then it turned out to be a 15 page (when printed out) story about one man's adventure with Open Source style programming and distribution.
Link to article - Cathedrals and Bazaars
written by Eric Raymond
http://www.firstmonday.org/issues/issue3_3/raymond/
He begins by explaining to the reader what is meant by "Cathedrals" and "Bazaars". Eric uses the environments these locations hold as symbolism to two completely different programming styles. A Cathedral would be a secluded location, where developers would create software, without any interaction to the outside world and deal with problems like bugs and data structures themselves. Only the people who are working within this "Cathedral" have direct access to any progress. While a Bazaar, is pretty much the opposite. Its where people become a necessity, and not only the program is shipped out, but also the source code used to create it. This allows any person to take pre-written information and either improve on it, or turn it into something completely different.
The Bazaar method is believed to be only successful by a wing and a prayer. But it has worked in the past successfully - the development of Linux. The creator of Linux, Linus Torvalds took an existing OS for 386 processor-based PCs (Minux) and created Linux from its foundation. Then shipped the source code for it between a large community of users and hackers, which in return supplied Linus with either requests or code to fix various bugs or for improvements to functionality and performance. Seeing how this went successful for the creator of Linux, Eric decided to give it a test.
Eric started off with 2 things: 1) An ancestral mailing client called FetchPop(allowed a user to retrieve mail using POP) and 2) Inherited code from a programmer named Carl Harris for a program called popclient, which he had given up on for some time. However, there was a decent memberbase of approx. 250 users using this one program. And his final outcome would be an mail retrieving program that used STMP via MTA/MDA.
Using the "bazaar" Eric had (the popclient users), he released numerous versions of Fetchmail (the name of Eric's masterpiece) to this localized public. He recieved numerous forms of feedback: Either they were praising him, pointing out bugs that were visible, or supplied code to either improve performance, or to fix the existing bugs. However, there needs to be a limit, such as security, encryption, and in some cases - project scope. This is one advantage to Open Source programming: You are using more than 1 set of "eyes" to assist you in making a more stable product. The more people that are inside your community, there is a possibility that bugs will become more apparent to at least someone and work can be done to correct them. However, that is assuming these people are dedicated enough to your cause and realize the scope of your program. Also, the members of the community don't rip your code and create a product that could just be as capable as yours. Although that is the worst case scenario - it's just how the world of Open Source works.
Eric also had to release patches often, and as many times as necessary to be able to keep his memberbase from leaving his community. Without a community, he would have been developing Fetchmail without "help". Making multiple releases lets your users know that you are still working on this program and that the people's demands or recommendations are either being considered or met. If you cannot keep up with the patches, then you would either need to name a successor to your program, or get more co-developers to assist you.
In the end, Eric created a successful FetchMail, a program that allows you to collect mail from email accounts via SMTP fowarding. Although the scope of his original design had to change a large sum (via his own intentions to keep his mind in this program and the feedback from his community of co-developers), he managed to get a stable program starting from segments of pre-written code. Without Open-sourcing his code or retrieving open source code from the get-go, he would have had to write this program completely from scratch, and with a secluded team of developers, or worse - by himself.
I personally know about writing code solo with zero base - it is not fun, and extremely stressful and time consuming. I would rather do something like play a Diablo II mod or some other game than spend 20 hours a day writing code from scratch. But in previous courses, I had no choice - plagarism was a big-time offence in the Academic Policy at Seneca. Every single course in the Computer Programming and Analysis abided by that code - except this one. The world of Open Source recommends AND REQUIRES that the programmer must "steal" existing code to get a base going. But in doing so, you also cannot acquire code that is protected under copyrights or secluded companies, regardless of how useful or useless the code can become. And you will also probably open yourself up to potential "thieves" who may make a clone of what you made. However, it's better that the code is being put to use - whether it would be to further your plans or further someone else's.
I also hate debugging code solo. I can see why Eric decided to go Open Source and use a community. Depending on the complexity of the code, debugging for me can take between 1 hour, to 1 week (assuming I work straight through an entire day(s)). There are always solo methods to debugging: Like write one block at a time, compile it and test it, or pen and paper approach - where you physically draw out or "walkthrough" a possible, or current solution. Although both are good tactics, it will only be fast if you do it piece by piece - across a possible 500+ lines of code. It will make matters worse if you don't document your code as you write it. People aren't exactly going to help you, open or closed source, if you don't make your code readable and understandable to the person next to you. I do need other people to help me out when I need to debug - but I mostly used professor help over student help. Student help is often flawed and don't see my program eye to eye too well. It's worse when it looks like you might be the more "educated" one with how you see things, which then makes the person next to you look ignorant. Professor has a higher chance of getting something solved - but you are limited to Student Help Time or In-Class. And some professors need to be communicated in a way they can understand it. I can, however, rely on either people to beta test my programs at least. The ones who could possibly understand might be able to help me debug. But not do all the debugging for me, unless that problem is the only one that is happening.
So as you can see, I for one am in support for Open Source development. But I still need to be careful with how I do this and who I do it with. For this will possibly be my first time I give code to others, but definitly not my first time "borrowing" from others. This is also something I need to fix if I am to succeed in this course, and later on in my professonal career as a Software Developer. I will be fixing it by balancing the equation, and being more open to what I do and/or give to other people.
No comments:
Post a Comment