Yet Another Review of the Cathedral and the Bazaar: YAROCAB
From GOSC
Introduction
"The cathedral and the Bazaar (CAB)"[1] article written by Eric Raymond is one of the earliest analysis of an open source (OS) community practices. It is the first attempt to formalize a model of such practices in a way that triggers one's head towards better software engineering. There is no doubt that this article has affected the software development models one way or another. Here at the German University in Cairo (GUC), as we study open source software engineering, we would like to provide yet another review to this document. Our review is going to be a collaborative submission from the OS software engineering students where we reflect on the main points or quotes from CAB.
Why are we doing this?
First of all, we are hoping to learn. Looking deeply into the CAB principles will help us learn and embarce what we learned. Second, we would like to make a serious contribution to the OS community by reflecting on this document. What kind of contribution?, you may ask. Here are some examples:
- presenting a principle in a clearer way for wider audience either in a written, visual or even comic format.
- Relating examples from our experience or from other resources that will strengthen or weaken a point in CAB
- Introducing a model or adding to what is proposed (Yes, we are that ambitious)
YAROCAB Points
Please note that the quoted subtitles are literal words of Eric Raymond.
A Proposition: "Given enough eyeballs, all bugs are shallow" (Mirna Bouchra)
Reviewer: Atef
"Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone."
Problems in any open source project will not be characterized and fixed unless a base of co-developers and beta-testers exist. The developer who starts it all should be a good leader able to build and motivate a community of interested users as I think that if they are not interested or don’t need the application, they will not be ready to accept the motivation in the first place. He should have a charisma and a charming communication style to attract people and get the maximum out of their energy. In the bazaar model, the developer should accept changes and criticism with serenity and courage. People having knowledge and passion for working help in achieving the philosophy of leadership.
A good point but not enough. would you like to give examples of situations that support or contradict with this statement) I am really interested in your point of view. I am not interested in repeating what Eric Raymond said or rephrasing it. Please try to think of this proposition and of how you can reflect on it from your life or from something else your read. i also asked for some references.
--Fmeawad 11:10, 21 October 2009 (UTC)
Linus’ law supports the “Release early, Release often” rule. I’m convinced that releasing often buggy releases in condition to have a community to fix them is much better than a cathedralian release missing the features its users have waited for and thus disappointing them. The people joining this community have to be treated as co-developers to act like some, to gain confidence and to have faith in their own potentials. However unique someone think he is, there is always another one who had the same dream before so people’s experience are always helpful(Paulo Coelho)
Your writing is not well connected together. It is not a writing course. However, you are writing as if you are reading a paragraph in the document and commenting back here accordingly. That is why I can't connect between your two paragraphs. You are supposed to read the whole thing and then reflect from your own line of thoughts. Can you make your english sentences smaller so it can be more understandable?
--Fmeawad 11:10, 21 October 2009 (UTC)
I agree with Eric Raymond that having lots of effective hackers will not reduce the complexity of the problem but rather increase the probability that one of them will have the tool to fix it and it will be shallow for him.
A nice review overall, although it would have been more interesting with some real life experience. One statement I personally did not get was: "... achieving the philosophy of leadership", how does that relate to the beginning of the sentence? The final paragraph was stated properly. It shows that Mirna's text goes along with Eric's proposition and agrees with it.
--Atef 16:11, 18 October 2009 (UTC)
Problems in any open source project will not be characterized and fixed unless a base of co-developers and beta-testers exist. The developer who starts it all should be a good leader able to build and motivate a community of interested users as I think that if they are not interested or don’t need the application, they will not be ready to accept the motivation in the first place. He should have a charisma and a charming communication style to attract people and get the maximum out of their energy. In the bazaar model, the developer should accept changes and criticism with serenity and courage. One of my personal experiences while working on projects during university or in summer trainings that reflects on this statement is that I wasn't the type of person who easily trusts people changing the code I've written. Even when I was facing problems, I didn't like to ask for help and I was remaining debugging until I fix them. This was my style until one time I couldn't fix one so I allowed other people to test and change my code and the bug was rapidly fixed. So open source community is nothing but a large team of developers directed toward a common vision. If the developer allows his ideas and applications to be shared with some other co-developers, problems will be quickly found and solved. Just to support my opinion about the community spirit, I'll refer to Stephen Covey quote "Strength lies in differences, not in similarities". So in order to acquire this large base of co-developers, I think "release early, release often" rule has to be followed. Releasing often buggy releases in condition to have a community to fix them is much better than a cathedralian release missing the features its users have waited for and thus disappointing them. These often releases will attract more developers. The people joining this community have to be treated as co-developers to act like some, to gain confidence and to have faith in their own potentials. However unique someone think he is, there is always another one who had the same dream before so people’s experience are always helpful(Paulo Coelho)
--Mirna Bouchra 14:06, 21 October 2009 (UTC)
The Cathedral and the Bazaar approaching 2010 (Mina Metias)
Reviewer: Abdallah El guindy
Well,before proceeding in discussing this particular point,it is essentially needed to explain first,what the cathedral and bazaar expressions mean,and where from theses names were originated. In this context,the cathedral refers to the more common, regular ,structured,and organized Software Engineering models,where a group of professional programmers-representing a certain organization- would sit together trying to solve a certain problem. Finally the software solving the problem is delivered to the users,who are interested in the solution for that particular problem. Before the end version,a beta version could be also delivered first,but typically it is shortly before the official release and it is done for commercial purposes rather than targeting a feed back goal. The end users do not have an insight or a deeper look into the the solution procedure itself (the source code),they are only concerned with the end results. As it is obvious from the name as well as the definition,the model is a very structured one. Just like a cathedral is built,a very strict plan for the building must exist before proceeding in the actual building process. The plan is only accessible for those who are responsible/directly related to the planning process,and no other person is being allowed to have the slightest glimpse on the plan. Eventually the cathedral is built,and honestly speaking, in most of the cases it amazes whoever sees it for the first time. In other words,try to name one cathedral that is didn't take your breath away on the first sight.
On the other hand,the bazaar model here refers to uncommon,irregular, and unstructured Software Engineering model,where a programmer (or a small group of programmers) is trying to solve a certain problem. While solving the problem the programmer shares his/her ideas,code and even prototypes with other programmers or even regular users,who are interested in the same problem. These other programmers/regular users are seen as partner stakeholders rather than end users. Combining all the different views,opinions,thoughts and even code modification together the end version comes to light. Unlike the cathedral model,in the bazaar model the end users are granted the right to have a full insight into the solution procedure,they even have the right to modify this procedure (the source code). Before the end version a prototype or a beta version is being developed at every possible step of the developing phase. Beta versions in this model are not for commercial or marketing use,they majorly target getting a feed back from other programmers or regular users,in order to carry these modifications into the next developing phase.(Do not get confused with the iterative software engineering model,that is present under the regular Software Engineering category. In the bazaar model stakeholders are allowed to modify the code itself,unlike the iterative approach,the only things stakeholders may modify are the features of the solution,not the process of solving itself.). Just like a bazaar takes place,no strict plan is followed,every single participant in the bazaar is granted the right to present what he/she has , participants are allowed to take a look at eachother's products, they are even allowed to take eachother's products and emerge it together with their own products hoping to have a much stronger product as a result. Results from such emerging could be magnificent, and beneficial for all products owners, as the new product is not constraint for a certain participant,recursively it is being shared among all other participants again.
After these brief explanations for both models,a comparison between both is enforced upon us. Both models have been present for a quiet long time now, none of them got destroyed by the other,and none of them was vanished. This observation could only have one implication,that they are equally strong. In other words,each of them has got it's positives as well as it's negatives. Each of them has got it's field,where it could simply crush the other in it. During the comparison I will take one popular and most probably the most important example into consideration to illustrate the differences and similarities in both models. The example is the Linux operating system, versus any other non-open source operating system (Windows or MAC OS). It is not deniable that the latter operating system in terms of usage population is more successful nowadays . Which is actually something wondrous in a way. Meaning,why would a regular customer buy an operating system,while there is a free one that is available to download. Well at first glance, it seems like the quality of the operating system is the answer,however it is not. Actually Linux distributions has proven that is much more faster and stable than a Windows or MAC OS system. So what could it be ? In my opinion the answer to this question is twofold. The first point to take into consideration would be the initiative the non-open source operating systems took by providing its users with a user friendly interface. This initiative managed to draw the large population of users to use this kind of operating systems. However the open source operating systems realized this fact and began to focus on the user interaction quality in their distributions. Unfortunately it was too late for most of the users to switch to an open source operating system. And that brings us to the second point of the answer. The human psychology plays one major role in the success of the non-open source operating system. Since humans tend to prefer whatever they know and got acquainted to over trying a new thing,even if the new thing is much better for them. The second role the human psychology plays emphasizes the role of the society in creating the idea of “ any paid-for service is indeed better in quality than a free service” . Combining both points together,the answer to the question becomes crystal clear. The second major point to discuss in the comparison would be the motive behind both models. The motive behind the non-open source model or the cathedral model is pretty obvious,and logical too. Money in particular and industry in general would resemble the motive for this model. Being paid to do develop a certain software,is the fuel that brings this model to motion. In contrast ,in the open source model or the bazaar model there is little financial benefit present,which may be weird and non logical for some people at first glance (myself included). The main motive behind this model would be more of a moral motive,which is the right to have a good software in particular and the right in freedom in general.
The third and final aspect in the comparison would be the quality of the software system. Despite the widely spread idea,that there is no free or non-benefit service is nearly as good as a paid-for service this is not the case with the chosen example . With the chosen example Linux vs (MAC OS or Windows) and through a personal experience Linux would prevail over windows/MAC in terms of speed,efficiency and quality of operation. Which is in my opinion a pretty logical result,that could be expected looking at the different developing models each of them follows. Windows/MAC follow the cathedral model,on the other side Linux co-founded the open source development model or the bazaar model. By nature in the bazaar model a larger population of developers take part in testing,debugging and even programming, and hence the result is way more stable and has a higher quality standard . In other simplified words,it is all about pure math,where more developers/programmers (or as the text referred to as hackers) a better result is available.
To conclude the previously stated points,it is clear that both of the developing models has got its own strengths and weaknesses,and the fight between them will always be on. The cathedral model followers will continue to attract brilliant developers/programmers to their companies, and the bazaar model followers will always fight for their principals and morals.
Abdallah.elguindy 12:01, 18 October 2009 (UTC)
The review is quite good and interesting to read.. However it has one serious flaw, it tends to compare the cathedral vs. the bazaar rather than showing the status of the competition as we are approaching 2010 (which should be the main point). The first 2 paragraphs focus on describing the two models and the metaphor of the cathedral and the bazaar, which is irrelevant and redundant as it is already described in the article. I think that the first 2 paragraphs should be shrunk (if not removed altogether) and that the rest of the article should be directed more towards its main purpose. One final note, the sentence "versus any other non-open source operating system (Windows or MAC OS)" is a bit weird :).. There are other OS's than the big 3, and some of the other OS's are opensource too :)!
For Mina: I enjoyed reading your text because it expresses your own opinion. However, I feel what you have written is reflecting on things and history more than talking about the topic which is approaching 2010? It would be nice to talk about the popular models now these days: are they the traditional model like the cathedral? the paper CAB was written in 1998. Now, we are over a decade after this? Was he correct in his specualtions? Are traditional techniques changing? Has open source been successful and growing since then? Do you have examples from your own experience? Did you have to use any Open source system or were you impressed by any? You have some many strong statements. Whenever you make such strong statements you need to find references. Otherwise, you can say, I believe .... Well in general, I enjoyed your reflections. I just feel that you can say alot about the topic; however, you chose to write what was on your mind which was irrelevant. Also, can you make it shorter?. This will increase the probability of people reading it till the end :)
Dear Abdalla, Dear Dr. Fatma. I would like to thank you for your fair and reasonable reviews,as i totally agree with them. And just telling you that your notes will be considered in the coming version of the review.
The Cathedral and the Bazaar approaching 2010 (Mina Metias) Version 2: Before proceeding into the review itself,it is important to mention that this is a modifeid review, after being reviewd by a colleague ( Abdalla EL Guindy) and the course supervisor (Dr. Fatma Meawad). I wish the major flaws they mentoned before,will be handeled in a decent manner in this new version.
My major flaw in the previous version was that there was no actual transfer for both concepts(Cathedral and Bazaar) into the time being as we are approaching 2010 (which is almost a decade after the original document was written). The major observation that could be transfered into 2010,is the "fight" between both developing concepts that existed with thier own existance.In other words,whether it is 1998 or 2010,both concepts exists strongly,each of them has it's own followers and supports, and since none of them got vanished or destroyed by the other,that could only indicate thier strength . Well ofcourse some differeces could be noticed carrying out the concepts from 1998 to 2010. The major difference that is observed is the internet technology that helped the bazaar model to spread all over the world. The availability of web-based communities and web blogs managed the "connection" phase between different contributors in a certain project. Ofcourse the revolutionary communication technology (mainly the internet) attracted many users to the open source communities (myself included,i was namely a windows user,now i run ubuntu 9.04 and i wouldn't change it for the world =) ). In my opinion,the fight between both developing models,that is observed in the past and the current time being,will be also observed in the future,as no one will give up. The Cathedrals,will still attract the so-called "best of the best in the business" to join thier teams, and on the other hand the Bazaar followers will keep on defending thier principals and concepts as it represents the pure FREEDOM to them. --Fmeawad 11:57, 21 October 2009 (UTC)
"Every good work of software starts by scratching a developer's personal itch" (Mina Tadros)
Reviewer: Ramy Wafaa
"Necessity is the mother of invention", can it be the driver of good practice? Would necessity make a good softwar engineer?
As it is well known and spoken for years that “necessity is the mother of invention” but is that just enough for software programmers, doesn’t the hacker or software engineer need some inner motive that drive him other than the customer’s need for particular software?! The answer is no, it is the personal itch which is the programmer’s thrust to write a particular program that should drive this code to perfection; in turn this will lead to a better software design. In most software design it is the software engineer love and need for the program that makes him go the extra mile for making the software better than the usual standard. Thus I agree with Eric that for software to be good it must bug the developer.
Thanks for the short paragraph it was easy and fast to read. That being said, It is contradictory and even though small is redundant. Most of the words were either A rhetorical questions or a personal opinion. The personal opinion would not have been a problem if it was not contradicting the question. The answer to the question "doesn’t the hacker or software engineer need some inner motive that drive him other than the customer’s need for particular software?!" is no he does not according to you. In the opinion you say you agree with the Eric's statement whose answer to this question is yes rather than no as you mentioned. The word "personal itch" is not used properly after the answer you gave. The use of the word bug the programer is not clear too. Do you mean the actual software? The development process of the software? what exactly about the software that has to bug the programmer?. If so why does a programer who is "bugged" by a certain software work on it?
For Mina: Eric Raymond was speaking about the developer's need, not the customer's need. He means by an itch, like something that he is eager or challenged to do. Can you please make sure you read this part in the CAB document and express your opinion, mention examples from your own experience or from someone else's experience to support or contradict this phrase? Also, I mentioned that I need some references not just the CAB. You had a whole week to write this paragraph and your writing is telling me that you didn't read.
--Fmeawad 12:00, 21 October 2009 (UTC)
"Necessity is the mother of invention", can it be the driver of good practice? Would necessity make a good softwar engineer? As we all know that "Necessity is the mother of invention" Eric Raymond was speaking that this is not the life with programmers as most of the time they asked to do programs they don't need to do or even they don't like to do. As we used to do in our university projects everybody is asked to do project and its not important that he/she are interested in this project or need to do it or not. As asking a programmer to design project he must fill that he really need it to do so that he can fill the challenge of doing this project so that he can reach this aim. Eric also said that he don't have to design a program that is exist just to add something he need to it and compete it with the old one. programmers can just search for something near to what they want and try to rewrite it to reach his needs and this will be much easier and faster. and i really agree with him in that as to start something from scratch is something so harder than understanding and updating existing programs.
--Mina Tadros 01:07, 26 October 2009 (UTC)
"Good programmers know what to write. Great ones know what to rewrite (and reuse)"(Ramy Wafa)
Reviewer: Antonious Mamdouh
Almost all programmers do not write code from scratch. If we are talking about writing code totally from scratch then we are talking about people who write all functions of a programing language like writing a function that reads from the console or hard disk. Even people writing code for drivers of things like graphics cards and such have well tested functions written for the routine functions that they need.
Even if we mean by writing from scratch the use of programing languages only without the use of any frameworks, then a lot of programmers still are reusing code that was done by other software developers. Imagine writing code for a website from scratch using only Java, Python, or C++. That would certainly be tedious at least in terms of time consumption as well as the fact that this newly written code will most likely contain bugs that need solving.
Moreover if you are building projects from scratch it is almost likely that you will use the code of projects similar to yours for comparison and to realize good ideas from them. Even if this was the case then you are reusing the code of others in the sense of perfecting your code. One good example of such projects is Google Chrome.
That being said there are also other programmers that prefer writing things from scratch. Most of these programmers prefer doing so because to them writing code is easier than understanding the code of others. Others feel the need for a new architecture for the software being developed. The problem with rewriting code just because you do not want to understand the code of others is that their will be a lot of redundant code doing the same thing. This is not good for the design of the software "You know you’ve achieved perfection in design, Not when you have nothing more to add, But when you have nothing more to take away"[2].
I believe that using code and ideas of others if it is well tested and it is appropriate to use such code or idea is great for developing high quality software efficiently. I also believe that rewriting large scale software is not good unless there are huge bugs in the system or a new need for the rewriting it. An example that shows that rewriting software is not good is Netscape who attempted to rewrite the code which took three years to accomplish (Valuable market time)[3].
From my personal experience, using tested code of other people as well as reusing software that is already tested before for the functionality it does is a must. I started to learn about programing four years ago in the university. Almost all my projects were done in teams. In a team generally every person is required to implement certain functionality and then the members integrate their code to provide the required goals of the project. If each member of the team writes his own functions to use then each one of them would end up with his own version of the project in addition to the fact that he will be wasting his time or the time of his team partner as one of their codes will not be used.
--Antonious Shafik 16:07, 18 October 2009 (UTC)
I liked Ramy's way of giving examples and arguing for the statement which shows that his reading of the paper was tough and inspective, me myself couldn't agree anymore than he did. Also Ramy gave a really good example about his team work for the project. Also he covered the aspect from everyway either from the point that taking ideas from other work, or even taking parts of functions going beyond the literal meaning of the sentence which would simply imply that programmers should know which parts of code to use from other programs, to that relying on other programs for ideas is part of the logical implication of the phrase which was true to a piont.
Thank you Ramy for your reflections. I have to admit, I didn't think of scratch as deep as you described it. I was thinking just a new project :) I enjoyed the examples and thank you for the references :)
--Fmeawad 12:14, 21 October 2009 (UTC)
"Plan to throw one away; you will, anyhow." (Saher El-Neklawy)
Reviewer: Mina Tadros
As many hackers start their coding/hacking in their years as university students, they tend to be working on small scale projects.
This usually give rise to a Cathedralian approach of coding, where the person would write their part with little review from third parties.
With such a path, this programmer tends to develop a sense of ownership with both the code and the piece of software.
This feeling of ownership towards one's code feeds the fear of other people playing with the code. I noticed this first hand when working on a project alone. As I wrote my parts, the code got more layered and complex (of course i didn't know that at the time). With every passing keystroke, it felt like I was putting part of myself in the file. Later after the project was done, and other people needed to reuse the code, changes needed to be made. I found myself thinking "How dare they touch my beautiful code!".
The above story shows the power of the Bazaarian way of open transparency during development. Having your work out in the world with people commenting on it will give you an objective perspective early. This will build an attachment not to the code base itself, but rather to the "greater good" of the product as whole. It would also facilitate making rational decisions about doing drastic changes that would lead to improvements on the long run.
Being able to accept change, and knowing that this will not come except by being open to critique, reinforces the original premise of "Given enough eyeballs, all bugs are shallow".
First of all i'd like to thank saher about his easy English he used in this paragraph. Second i really like the example saher give as i really fell the same if someone just read my code i think that "oh my GOD, he will play with my code and i will lose more time in redoing it the same as it was no way!" Also i like your way of saying the objective of the Bazaarian that i really understand it from you more. your goal now is to have more people to see your code so that they can see more bugs and this is really good if you can accept that someone do change in your work finally saher you did a good work on this part i like it but really it need people to be ready to accept others to play on there work
For Saher: Really nice Saher, again I enjoyed hearing your own related experience about this. Openness in general is a tough challenge but it leads to transparency, trust, learning and more good things as we saw from existing open source communities.
--Fmeawad 12:21, 21 October 2009 (UTC)
"If you have the right attitude, interesting problems will find you." (Abdallah El Guindy)
Reviewer: Sarah Nagaty
Be it in Academia or in enterprise, why do some people keep running into interesting problems while others have to struggle with others that are totally uninteresting? Is it mere luck?
It is a fact at least the case in my personal experience, that those who have a certain attitude meet the most intriguing problems. It is the attitude of seeking perfection, settling for no less than what will perfectly do the job. It is the attitude of scratching one's itch (not a very healthy thing to do in real life). It is the attitude of not letting interesting problems fly by without taking the time to ponder for a second whether a perfect solution is within reach. It is the attitude of not being scared by unexplored territory or by the existence of claimed "perfect" solutions written by big name firms. Those who are not lazy to leave simple problems along the way unsolved, those who do not shy away from problems without giving their ideas a shot without fearing immediate failure.. Those are the ones lucky to meet interesting problems most of the time and with enough talent those are the ones that find glorious solutions to even more glorious problems.
--Sarah Nagaty 17:42, 18 October 2009 (UTC)
What I like most about this part is its motivational effect. There is no one lucky by coincidence to work on interesting problems while others are not. I consider this review as an interesting and effective one. It contains personal experience as a support to the reviewer's point of view whereas I really wished as a reader to have another experience or example as a reference to support the point. The review brings a personal opinion regarding the CAB document in this specific point where a description of the right attitude was explained. I regard this attitude as a general attitude in life and according to what Charles Haanel once said that "The predominant thought or the mental attitude is the magnet, and the law is that like attracts like, consequently, the mental attitude will invariably attract such conditions as corresponds to its nature". Working on interesting problems is a choice that a person makes and not mere luck.
Like Sarah said, it is very motivational :) and also gives advice to others in a very light manner. Well done.
--Fmeawad 12:27, 21 October 2009 (UTC)
"When you lose interest in a program, your last duty to it is to hand it off to a competent successor" (Antonious Mamdouh)
Omar Roushdy
When I read the statement in the first place it was a major shock all that ran through my mind was "what the hell, why should work my brains on something then give it away for a COMPETENT?!” However after reading the Cathedral and the Bazaar article it really seemed like an interesting idea. The point is that the major aim of a programmer is to provide the users with the needed tools and to ensure that his tool is still alive in the form that it keeps up with the user demands. And the statement indicates that there must be a loss of interest in the program, and by the definition of the word interest that is a state of curiosity or concern about or attention to something [1]. This implies that I as a programmer have no more interest of ensuring that that program is alive, thus if I’m not going to ensure that my code is alive then why shouldn’t someone else take it and give it a new life rather than leaving the program die. However one point that was made clear that this person that is going to take over my program should be a competent, which means that he should be fit for the job in a sense that he has the and has the sufficient knowledge to give the program a new life and ensure that it stays alive.[2].
This statement is as Antonious said, wierd at first but later on when i read it and understood the concept it made sense. Firstly, I agree with the previous reviewer on what he mentioned, when losing interest in a program the last duty for a programmer is to hand it to a competent successor. This helps in reviving or keeping the program alive, the word competent would be useful here for some reasons. When a programmer loses interest in a cretain program and he hands it to a competent programmer, he starts working on it eagerly to prove himself that he's a better man for the job. This could be one reason for the programmer to be a competitior. Moreover, I want to add to the previous review, one quote which was stated in the article "given enough eyeballs, all bugs are shallow." which means that all bugs are transparent to somebody which could not be you or the programmer working on the program. This means that handing it to other people would be useful as it will be exposed to different mentalities and experiences. Sometimes a person finds the problem and another one solves it.
--Omarroushdy 23:29, 18 October 2009 (UTC)
For Tony, Tony, I like what you wrote. Thank you. However, I would have loved it if you told me hints of what made you change your mind from the cathedral and the bazaar. Otherwise, your whole paragraph is agreeing on the point and giving definitions to two main words. I appreciate that you meant to put references though :) Thanks.
For Omar: It is not competitor omar. It is competent, someone who is qualified. I don't have to work on something to prove that I am a better man for the job. this is not the right attitude that will make you successful in a community. However, I really like your last sentence about the eyeballs :) (feels like a scary movie when I say eye balls :))
--Fmeawad 12:34, 21 October 2009 (UTC)
"Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging." (Muhammad Moustafa)
Reviewer: Mostafa Magdy
Are the users part of the problem or part of the solution?
If you consider the user being part of your problem (the hacker assumes that the problem occurs because of the user) then your are underestimating the value of your user. You must give the user some credit for basic intelligence!!. It has to be emphasized that the problem already existed and the user was the one who pointed it out, thus the hacker has to consider the user as a part of his solution. Moreover, users have the options to cause a direct change in any system, in other words users can be considered as actors who will be engaged in activities such as reporting or fixing the errors, suggesting new functionality and participating in the community, etc...and this what makes the bazaar model such a success model.
Treating your users as co-developers would make life much easier since they directly interact with your application. Now, a question would arise, why the user will participate in the developing process (Considering the fact, that users are too lazy to report a bug (at least me))?...well one reason is that a user might think that it is just a ridiculous bug or the fear of looking stupid, this feeling is caused due the lack of user's motivation to participate. Therefore, the user has to be empowered with such motivation and the right attitude in order to amplify the development process and enhance the debugging process.
I totally agree with Muhamed review – especially the part he mentioned that some users won’t participate unless they are motivated somehow, and that’s true. Users need to be treated as your most valuable recourses same as the beta-testers. Muhammed also nicely stated how important and effective the users can be in the bazaar community. But he could proof how effective they are by giving a real life example. And they are many examples; the most famous ones are the Chrome application and Linux distributions.
Thank you Mohammed for your reflections on the topic. As Mustafa said, an example would have been great :) Also about motivating users to participate, you could have elaborated more on this point. what can do for this?
--Fmeawad 12:45, 21 October 2009 (UTC)
Are the users part of the problem or part of the solution? If you consider the user being part of your problem (the hacker assumes that the problem occurs because of the user) then your are underestimating the value of your user. You must give the user some credit for basic intelligence!!. It has to be emphasized that the problem already existed and the user was the one who pointed it out, thus the hacker has to consider the user as a part of his solution. Moreover, users have the options to cause a direct change in any system, in other words users can be considered as actors who will be engaged in activities such as reporting or fixing the errors, suggesting new functionality and participating in the community, etc...and this what makes the bazaar model such a success model. Take a look at the ubuntu community, actually users solve other users' issues, regardless the complexity of the user's problem. Many problems are just solved, when the user take a step and post his question regarding a certain issue. Also, this increase awareness among other users about such an issue. Treating your users as co-developers would make life much easier since they directly interact with your application. Now, a question would arise, why the user will participate in the developing process (Considering the fact, that users are too lazy to report a bug (at least me))?...well one reason is that a user might think that it is just a ridiculous bug or the fear of looking stupid, this feeling is caused due the lack of user's motivation to participate. Therefore, the user has to be empowered with such motivation and the right attitude in order to amplify the development process and enhance the debugging process. I believe that the place where the user will gain such motivation is the community. In the community, the user will be able to see other participants and the effects of there participation on the community, thus the user will be motivated to share and positively affect the community.
Muhammad Moustafa 01:55, 26 October 2009 (UTC) [modified]
"Release Early, Release Often" (Sarah Nagaty)
Reviewer: Mostafa Sheshtawy
Does this ring a bell?
Users are sometimes more motivated than developers when concerned with a software that they are using. So why don't we allow these eager users to act as co-developers and make use of their potentials?
The fear of shame is the main reason that keeps developers away from the RERO (Release Early, Release Often) model as a project might not be good enough to be going live. Since early releases are mostly buggy versions so this might cause a bad project reputation among the users. On the other hand, the early release gives the advantage of being a pioneer. According to the bazaarian model, any project can be released as long as it has minimal functionalities to meet the user's need and can stand on its own feet [3]. This release will position the project to immediate testing by the users allowing them to dig deep into it and discover all the bugs that are not yet discovered. This is consistent with Linus' law which states that "Given enough eyeballs, all bugs are shallow." where bugs are no longer an issue and this guarantees the project's lack of buginess. RERO decreases the debugging time as the eager users act as co-developers and are involved in the development process unlike the cathedral model which restricts this act on exclusive developers and does not make use of the users' potentials who are most of the time more motivated than the actual developers. Eventually, the developer aims that the project is being used and fulfills the users' needs which is the key motivation to any open source project. RERO is mostly concerned with the user satisfaction and thus it gives space for the users' feedback taking us to "Release early. Release often. And listen to your customers". This way software evolves fast and even sometimes more than it was actually intended to be developed at first which gives a clear reason to follow the RERO fashion.
I like how Eng.Sarah looked at the problem, it is more into users than developers or products. As she claimed, most of the users are co-developers - i would add Vice Verse - since also most of the developers and co-users to the normal users. Also the Release Early Release Often model prevents the product or the project from getting out of fashion - or maybe getting old. if you release often you make sure you are at the level of the current technologies that are in the market. That was one point I wanted to Clarify.
Good review Sarah. Again, I would have appreciate an example.
--Fmeawad 12:53, 21 October 2009 (UTC)
For Sheshtawy, the release early and release often it not about keeping with the current technologies. It is a development behaviour to help catch issues early and improve development.
--Fmeawad 12:53, 21 October 2009 (UTC)
"Release early. Release often. And listen to your customers" (Mostafa Elkhouly)
Reviewer: Abdurrahman Ahmed
This is the edited review
Linus’s strategy was to keep his users satisfied by the constant improvement of the Linux system, for example in the early times it was often that Linus releases more than one new kernel in one day, other users (hackers) also get an “egoboo” when they see that they get acknowledged as the developers of there work, these rapid improvements made the users eager to participate more and more and to follow the “Release Early, Release Often” strategy.
On the other hand, some users who develop some code don’t test it cautiously, which leads to lots of bugs in the code, and as Andrew Morton said "we have hundreds of bugs which people have taken the time to report, which the relevant developers know about and nothing is happening.", he also added that we don’t have a sufficient amount of developers and users working on fixing the bugs that the system currently has [4]. Since the developers (hackers) these days don’t test there work carefully, and they don’t fix the existing bugs, these two facts will cause an accumulation of bugs that will be very hard to fix them on the long term.
I think that "Release early. Release often. And listen to your customers" strategy can work better if it is accompanied with the "Linus' Law": "Given enough eyeballs, all bugs are shallow.", because this law will solve the problem of fixing the existing bugs. My opinion about listening to the customers is that it’s not always good, they must be more committed and test there work roughly before submitting it, it is not just about how often you release, it is about how often you release work with good quality.
I find this section interesting and relevant to the topic. It also shows thorough reading of the article, as well as research. Some parts of it, however, were a bit confusing. The first paragraph states that Linus kept his users satisfied by constant improvements. This is, according to what I understood, only partially true, as his users (at the time) were hackers, and their satisfaction was in seeing their own work being updated daily (so it was not really his improvements, but rather their own). I felt there was some contradiction between the second and third paragraphs. In the second, it is argued that the Linux kernel (according to citation) has alot of bugs and too few developers to tackle them. Yet, the third paragraph goes on to state that "Given enough eyeballs, all bugs are shallow.". Does that mean that the bugs are known, but are not fixed timely? I think this part needs a little bit more clarification.
--Abdurrahman 18:58, 19 October 2009 (UTC)
I can see contradiction in your text. If there are alot of developers who are not working on existing bugs, it doesn't mean you don't listen to your customers? Please clarify your points and write clearly. Thanks
--Fmeawad 13:02, 21 October 2009 (UTC)
I totally agree with your point of view on the first paragraph, because that was what I really meant, and by improvements I didn’t mean only Linus improvements, I just gave Linus as an example, because in my opinion he acted as one of the hackers but he was more committed. As you said hackers were satisfied in seeing their own work being updated frequently, a proof of that is the introduction and frequent use of a term like “egoboo” in the open source community. What I meant by the second and third paragraphs is that Linus said that developers (hackers) these days don’t test there work carefully, moreover they don’t fix the existing bugs, these two facts will cause an accumulation of bugs that will be very hard to fix them on the long term. About the contradiction between the second and third paragraphs, I meant in my review to show the advantages of the "Release early. Release often. And listen to your customers" strategy in the first paragraph then to state the problems that occurred as a consequence of it in the second paragraph, finally I mentioned my opinion of a solution to these problems in the third paragraph. My point about listening to the customers is that it’s not always good, they must be more committed and test there work roughly before submitting it, it is not just about how often you release, it is about how often you release work with good quality.
--Khouly 08:36, 26 October 2009 (UTC)
How would you follow Linus's way for communication in 2009? Any new revolutionary tools or ideas? (Mohamed Zakaria)
Reviewer: Mostafa Elkhouly Eric Raymond listed what he did to follow Linus's model, that was in 1998, what would you do now in 2009 considering all the existing tools for communication and interaction.
Linus' model mainly depends on the coordinating developer being the gatekeeper of a project in which most of the work is done by others. In other words, debuggers or co-developers communicate only with the coordinating developer, not each other. The coordinating developer has to have very good social skills, and has to be able to use the "egoboo" of other people in order to be able to attract the largest number of them to help develop and debug the project. Egoboo is a colloquial expression for the pleasure received from public recognition of voluntary work.[5] So the coordinating developer will have to give credit to everyone who participates even a single line of code in the project.
Agreeing with Mr. Raymond's words "Provided the development coordinator has a medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one" the internet has established an amazing and enormous communication channel between the developers, and the new tools being developed for the internet so quickly allowed more effective communication and helped reduce any communication overhead that used to happen before. Linus' way of communication is now a piece of cake for any newbie user who even wants only to complain about a bug in a computer application, this will help further to find out bugs, or in other words the bugs will find the developer.
Unlike 1993, there much more than e-mail to connect the co-developers to the coordinating developer, and the new tools are now simple, and sometimes even trivial. Forums are now one of the tools that became trivial and widely used by everybody, as well as blogs. There are also more advanced tools that satisfy the users' needs in communicating to others, like Facebook and Google Wave which are generic communication tools in which people can start group communication very easily and fast. Needless to talk about other professional tools and website whose only purpose is to help developers collect their codes and reduces the communication overhead magnificently.
First of all, I agree with what Mohamed Zakaria said in his review, but I would like to add to it. As Eric Raymond said in an interview with Glyn Moody in 2008, he was disappointed because up till now his original theoretical models and language are still used, and no one tried to improve them. Although the are new revolutionary tools and ideas, first of which is the use of project workbenches like SourceForge, secondly the transition from centralized to decentralized version-control systems, and finally using real-time Internet text messaging instead of only using e-mail channels.[http://www.linuxjournal.com/article/9911] So in my opinion we just need to learn how to use all the capabilities that we have now, and to use them to improve the communication and interaction between the developers.
--Khouly 13:34, 19 October 2009 (UTC)
Good review and very good peer review. Thank you both. There much more to say about improving the process though.
"If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource." (Mostafa Magdi)
Reviewer: Ahmed-Yasser Can you think of any existing practice that we do now on the internet or in software development that reminds you of this quote?
I totally agree with Erics’s Quote, as beta-testers are one of the main factors of the Bazaar community’s success. In my opinion, without their feedbacks, patches and comments, the open source community wouldn’t be as grown as we see nowadays. So one might ask, how can someone treat the beta-testers as if they are the most valuable resources? Well, simply by listening to their feedbacks and taking it seriously and responding to their quires.
Many companies now advertise their alpha and beta software in order to allow people to test their products and send feedbacks and patches as they found any issues. One example is the Google Chrome application. Chrome was first released as a beta version for the public that allowed many hackers to test and feedback. They have their own channel for developers, testers and early releases that are not stable yet (http://dev.chromium.org/getting-involved/dev-channel). This gives a change to everyone to try and hack their code in order to help the developers to develop a better stable version.
I found this very well put as he summarized the importance of beta-testers extremely well. The main points I have extracted from within this review is that without beta testers the open source community would still be lacking in features and progress and that the only matter of gratification needed by the beta tester is to be heard, replied to and thanked. Alot of beta testers are not those who wait till a program crash and then just notify the developers, they instead try and reduplicate the situation on different machines, different environment and feedback the community with screenshots, debug statements and detailed information. This clarifies that beta-testers are the main asset that can be acquired within any development program, as debugging is usually one of them main problems in the cathedral approach. (*cough* *windows* *cough*) The only thing I think could have been added is that by making your beta testers feel valuable (by not only giving them feedback and taking remarks but by also notifying them of changes and making them feel like part of the active development) they will in turn develop a stronger sense of loyalty to the community (or the project in specific) and hence feel an urge to want contribute more, hence increasing the quality and quality of the feedback and get even more value from them.
"The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better." (Hassan Mohamed)
Saher El Neklawy
I strongly agree with the previous key aspect of Open Source method. As a new useful feature is a feature that is needed by some users and doesn't exist with the software. Based on the previous argument users are generally more able to detect missing features based on their usuage of the program. This is clear when Harry Hochheiser suggested providing an option for forwarding mail to client SMTP port offers a great idea to Eric Raymond who has just understand the idea and its effects and manage to introduce an important feature to his mail retriever. In addition, Most successful companies keeps a forum or feedback mail to get users requests and implement the most requested ones of them periodically. This way they broaden their users base and get new innovative features. However, according to the size of the user's list the process of filtering good ideas is not easy.
Moreover, Recognizing good ideas from other competitors and co-developers is very important. As Most successful persons are characterized by having the ability to recognize good ideas, implement them and market them such as: Bill Gates (Microsoft's founder) and Bill Bernbach (One of the leading advertisers). In Addition, Many universities and research center focuses on teaching junior researcher the ability to recognize good ideas as well as extending them.
More specifically, we can take the experience of Steve Jobs (Apple founder) with XeroxPARC company. The Xerox Palo Alto Research Center (XPARC) was founded in the early 1970s by the Xerox corporation. They focused on conducting research on computers, as they noticed computer evolution will threaten their business. In 1979, Steve Jobs visited XPARC. The researchers there showed him magnificient technologies that XPARC recognize it as research failure like: Object-Oriented Programming (OOP), laser printers, computer networks through Ethernet, weird device called mouse and finally the Alto. The Alto is the world's first computer to use Graphical User Interface (GUI). Steve Jobs has realized that these technologies will lead a revolution. He hired researchers from XPARC and assign them to research on implementing GUI that is not too expensive as the Alto to come out with Apple. [4] [5]
In the end, I have already noticed this fact during making my bachelor project. As I observed that my supervisor is very active in recognizing good ideas in the student's projects and extending them to new projects. Which I realize that this is one of the main reasons for his success.
From what i am reading, i am getting the feeling that you disagree with the claim that users can be source of ideas? Please clarify more, as all the examples and the general tone of the discussion is directed towards people working in the field being the only innovators. You should be open to user suggestions and improvements to your system. This gives it a chance to grow and widening the user base.
--Saher 04:49, 19 October 2009 (UTC)
Hassan, where are the users' ideas in your example? It is all about the companies. They are good examples but not for this specific topic. May be I miss understood you? Can you clarify? Also, can you use references?
--Fmeawad 17:41, 22 October 2009 (UTC)
Saher, I think you detect that I have missed part of the main point as I wrote about recognizing good ideas in general. So, I have wrote much about recognizing good ideas as an elementary point of success rather than recognizing good ideas from your users. Thanks for identifying this mistake.
--Hassan 21:10, 24 October 2009 (UTC)
Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong. (Mohamed Abdel-Fattah)
Reviewer: Mina Metias
Admitting that one's effort was performed in an suboptimal direction is necessary to put other effort in a more optimal direction. Quoting the article, "you often don't really understand the problem until after the first time you implement a solution", getting some effort done in the workout of solving a problem is necessary to solve it. It helps solving it whether this work directly or indirectly contributed to the final solution to the problem. Getting one solution clears up the problem, the use-case, the possible solution methodology as well as the unforeseen difficulties and challenges, which might not ever be thought of until people begin developing or using a solution.
It does not only apply to software development, but to science as well. It happened that science altered their solutions or explanations to problems once it is noticed that another solution outperforms the older solutions in accuracy or generality of use (such as general relativity replacing Newtonian gravitational laws) or simplicity of usage and clarity of the idea (such as Maxwell's equations describing electromagnetism). It turns out at some stage of the development that the currently developed solution has design problems that might disable it from its natural expansion, or develop problems in extending it to more general use. Fetchmail, the example used in the article, appeared to be needing to be redesigned as an extension to the generic driver, in order to overcame many design issues. Having delayed the decision of redesign or not taking it would have probably put more effort into the old, yet suboptimal, design. That might have lead to a decreased speed of the solution development.
A lesson learned is that a contributor has to have the guts to start over, just the same way he/she had the guts to start. It is often a plus to start over after having had explored many issues and methodologies if this leads to a less sophisticated design, and thus more featured solution. The best time to consider redesigning is the time a simpler design is noticed. If the newer design is simpler and allows the wanted functionality (solves the current problem), then applying it will increase the understanding of the simpler design, which will pay back when the solution develops bigger, to tackle more sophisticated problems.
I totally agree with Mohamed's review, i also found your point was clearly stated. From what i read, i got that in order to have a better understanding of the poblem, you have to exert effort in solving the problem. Moreover, whenever you find the solution, the problem will be cleared up. Nevertheless, if you reach a stage where the solution leads to more complex desgin, then it will be the right time to start over (that might not be appealing to everyone). However, you should have the right attitude to start over because this will leads to a better problem comprehension thus, resulting in better solution design.
"Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away."(Ibrahim Mansour)
Reviewer: Hassan Mohammed
Do I here anyone say Test Driven Development, TDD? Do I hear anyone saying minimum amount of code possible? Could this be the answer to the perfect design.
I definitely agree with the statement as there are many other factors that should be analysed within the process of development rather than just adding features or acheiving a bulky code. Time, work and space complexity are considered the most important factors when judging the perfection of some software or a piece of code. This would be obvious through the process of debugging, where the software should run in a stable manner on a wide range of systems with different capabilities as long as the software requirements exist. Actually not only in a stable manner, but in the most efficient one. However, the amount of code might be the key to perfection in design when considering the professionality of the coder. At a certain level of professionality, may be adding more code is equivalent to adding more promising and usable feature in the way that would ensure the simplicity and the efficiency of the code, where all terms of complexity might be considered optimal.
First of all, I would like to add the origin of the quote as this quote is said by the French aviator Antoine Exupéry. I think that this review is stating Ibrahim's opinion which I strongly agrees with him. However, the review doesn't indicate why the statement is true. It states that adding extra features isn't the most important factor in software design. but can't it be added to the other factors, I mean if the other factors such as: efficiency has been focused on enough. Is adding unnecessary feature to the software is good? Is it really related to the programmer's professional level? I don't think that this is true, as a good software system should be simple or at least doesn't have unnecessary complexity. But why is complexity bad? this can be justified by the fact that as the complexity of the system increases, the interaction between its components increases as well to a degree where one can't analyze all possible states of interaction. This can result in unpredictable problems and weakening the software. Finally, Just to strengthen my opinion, I will refer to Donald Knuth's quote "premature optimization is the root of all evil".
--Hassan 01:57, 19 October 2009 (UTC)
For Ibrahim, I am not sure I understand how is you review a refelction on the topic.
--Fmeawad 18:09, 22 October 2009 (UTC)
Hassan, thank you for the nice quotes. I guess the point is that complex is not necessairly good. This happens alot in Software. I see it alot nowadays as well. However, learning from TDD, keeping your code to a minimum to the extent that it is only sufficient to make a specific feature works indicate a good design.
--Fmeawad 18:09, 22 October 2009 (UTC)
"Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected." (Baher Salama)
Reviewer: Ibrahim Mansour
Can you think of examples of such a tool that you have used or built may be?
The first examples that I thought of when I read this statement were some of the very simple Linux\Unix tools such as diff, cat, cmp and grep. Each of these tools specializes in solving a small specific problem, yet they can be used in a wide variety of setting and many different ways that even the authors of these programs might have not expected. Eric Raymond's decision to specialize fetchmail to be only a mail transport agent (MTA) was one of the main factors that contributed to the increased elasticity of the tool as it gave the users the freedom to choose the method they want for mail delivery. The development of the multi-drop feature has emphasized this advantage when it produced a new and unexpected use for the fetchmail tool.
I totally agree with the statement and with Baher's review. A specific need for some tool is the main reason for developing it, however, this doesn't mean that the tool must be a single-purpose one. The flexibility in adding features to a certain tool so that that it performs more functions other than its core function makes it more popular and widens the range of its users. It is also clear that Eric Raymond strongly believed in the statement, where most of his work was on promoting tools that already existed, in order to serve new purposes the developers did not realize. And this is the power of the open source development, the use of others' feedback (developers and even users) might speed up the process of promoting a certain tool to be a multi-purpose instead of a single purpose one.
Well done baher, this is right to the point :) The peer review is good as well.
--Fmeawad 18:12, 22 October 2009 (UTC)
Can the Bazaar Model work from scratch? (Abdurrahman Ahmed)
Reviewer: Mirna Bouchra
In their presentation entitled "The Myth of the "Genius Programmer"", Brian Fitzpatrick and Ben Collins-Sussman show a very interesting graph. The graph shows a project's life cycle: someone gets an idea, develops a prototype, then invites people to join. They then raise the question of "when to do that last step?". They state that, in case that happens too early, one might "run into the risk of attracting people that don't want to do what you want to do".
The problem with starting a project in the bazaar fashion is that, these early projects intrinsically attract the type of people who already have an idea, and think that the owner of the project has the same idea in mind. This will almost certainly have a devastating effect on the project. The project will be frozen, due to all the forces pulling it in different directions, and time and energy will be wasted. If the project ever manages to take off, it will be so deviated from the form the creator intended it to be, and it will have lost most of the original "contributors", who will realize the actual direction the project is heading. People want to see a working piece of software (no matter how primitive or buggy) to be able to understand the real goals of a project, and to be motivated to join.
It can be observed that many open source software were originally developed by students, Linux being the most notable. The reason that may be is that these students are in the perfect conditions for releasing their code at the right time. Students tend to have clever ideas that they attempt to solve themselves. The lack of experience, however, pushes these students to ask for help in early stages of their project. It is this time, that is not too early as to gather many people around a vague idea, and not too late as to repel people from joining an already almost finished product, that is the perfect environment for the bazaar model to work. Communities (like the G-OSC) that attempt to nurture these types of projects are essential. Without these communities, many projects by students will be lost in the face of lack of initiative. Such communities will offer the students a place to put projects they are working on or ones they have lost interest in (handing them to a competent successor).
I agree with Abdurrahman that the time to ask for help or for people to join a project is really crucial because I believe that adding people in early phases may cause the initiation of lots of ideas and the project may be deviated from its main goal. However, adding people in a project's late phase makes it even later because they don't have enough knowledge of how the system reached that phase. I disagree with the term "frozen project" if we add people in early phases since the people who will join will be motivated and excited for the idea from the first place. So there will be lots of manpower and thus forward steps will be taken but may be not large enough compared to the case that people join in time where a first version of the application is released even if it is a buggy one so that they will have a sense of direction to the main goal. I agree that the presence of open source communities is essential because they adopt students ideas and turn them into real applications as the case of Linus and Linux OS.
--User: Mirna Bouchra 20:45, 18 October 2009 (UTC)
For Abdurrahman: I love your discussion Abdurrahman, well done :) I seriously enjoyed reading your reflection on this topic. (not because your praised g-osc;) sincerely:)) Also one of the few who included a reference. Thank you for that.
--Fmeawad 11:29, 21 October 2009 (UTC)
For Mirna: I disagree with the point of adding people in a late phase. That is what is happening in open source already and has proven successful. The knowledge is always there in the community and whoever is eager to find it, will find it. Help and review is also available in Os communities. Abdurrahman is just saying that a prototype or an initial vision of the system should be there to avoid early conflicts and misunderstandings. That was his answer to should we start from scratch or not? Your comment reflect some understanding though.
--Fmeawad 11:44, 21 October 2009 (UTC)
what I meant by late is a project that has a deadline and not an open-ended project. Getting used to the application and acquiring knowledge takes time.
--Mirna Bouchra 11:14, 26 October 2009 (UTC)
"To solve an interesting problem, start by finding a problem that is interesting to you." ( Mostafa Sheshtawy )
Reviewer: Muhammed Moustafa
While analyzing this statement, all I was thinking about is "yes. of course, makes sense", But it has one part missing : The definition of an interesting problem.
A factor is Interesting, when it is Arousing or holding the attention; absorbing the attention.[6]
"A problem is an issue or obstacle which makes it difficult to achieve a desired goal, objective or purpose. It refers to a situation, condition, or issue that is yet unresolved. In a broad sense, a problem exists when an individual becomes aware of a significant difference between what actually is and what is desired." [7]
Usually when a problem absorbs the attention it absorbs commitment and passion towards it, those two are the main fundamentals in creating and inventing a good solution to any problem. Finding an interesting problem , is the main challenge. It depends on, is it a problem in a made program or application (e.g. Bug), or is it a problem where you want to create a new program or application. The first requires Skills and Experience , also background about this application. The second requires Skills and creativity.
Then we move to the the easy part -Comparing to Finding the problem- Solving the problem. Since the "interesting problems" differ from a developer to another and the number of users is increasing.That makes the number of interesting problems increases significantly, in both types innovation and evolution. That is exactly what helps and have been helping build new programs and application in open source, and made the open source dominate in the creativity field and helped it get popular by the minute.
-- New part
Refering to Eng.Abdallah el Guindy's review, you always have to have a good attitude or then you will never find that interesting problem, and you will be stuck with the uninteresting problems where absorbs all the motivation and just leave duty.
<< Relate to 3.6 when the review is written >>
I found this really well structured and straight to the point. However, i dont think that finding an interesting problem is the main challenge. Your Commitment to find a solution to the problem what really counts, thus adding another challenge toward the solution (people give up easily, only few who commits). And this took me to another point, which is "Solving the problem". I think that solving the problem is harder than finding the problem or at least as hard as finding one. Finally, finding a bug in an applications isn't that interesting (At least for me), it is really an annoying experience. Rather than this, i totally agree that interesting problems increase innovation and evolution.
Muhammad Moustafa 09:41, 19 October 2009 (UTC)
I Actually like Muhammed's review, it was very nice to read, however it was almost the opposite of what I think or wrote. However what I believe in is, if you can't find an interesting problem, you would never be as committed as you were going to be, cause then only thing that connects you is either duty or job , or maybe you have nothing to do ! But YES , I agree that finding a bug is not that fun. But you know what ! that is exactly what we are going to do in the big project. Interested Yet ?? thanks Muhammed :)
--Mostafa Sheshtawy 19:18, 22 October 2009 (UTC)
If I may hijack this chain of reviews, I personally find debugging and finding new bugs so much fun! xD
--Atef 17:48, 25 October 2009 (UTC)
Brook's law and Linus' model (Shehab ElNoury)
Reviewer: Mohamed Abdel-Fattah
I believe that whether a software engineering process can break Brooks's Law or not, highly depends on the nature of the software being developed, what the programmers will add, and how well documented the software really is.
It is only common sense that it would take the initial developers, whom have been working on the software from the start, a lot less time in getting tasks done, rather than newly added ones. That's simply because picking up someone's work is not easy. Be it a different thinking style, or a different way of implementing, time would be wasted understanding how the software runs. Yet on the other hand, what if these newly added developers won't be responsible for changing the core of the software, but for introducing new features? Or help with debugging process?
Fred Brooks had a valid point, but let's not ignore the fact that his work The Mythical Man-Month was published in 1975. That was 15 years before the Internet gained a public face, and almost 35 years ago from this day. At that time, with the given technology, his observation was correct. But things are quite different now. Given the tools we have today, given the leap in technology we've came across, I second Eric S. Raymond's counter proposal to the law which states that:
"Provided the development coordinator has a medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one."
As for egoboo and its relation to the bazaar model, one can say that it is somewhat the driving force behind the programmers/hackers will to produce efficiently and effectively, or let me say, produce at all for that matter. It is what motivates them. Egoboo can be considered as some kind of ranking/public recognition between programmers. The higher your rank, the more you're respected among other developer/fans. And that's a main reason as to why Linux is so neatly documented.
For his opinion, "I believe that whether a software engineering process can break Brooks's Law or not, highly depends on the nature of the software being developed, what the programmers will add, and how well documented the software really is." ~ this needs actual examples to arrive at such an opinion. The Internet (communication) technology is having a radically different shape than 35 years ago is a valid statement, elaboration is needed to clarify the directions it changed and affected the open source development processes.
I actually agree with Mohammed, I failed to give examples in both my statements and relied mainly on common sense and my opinion of what just sounded logical, yet valid. Since his review was more comment oriented, I don't think there's more I can add to this.
Why do you think Linux is so well documented? Does it apply to all open source communities? (Majid Hassan)
Reviewer: Baher
In all approaches of coding, be it a Cathedral or a Bazaar approach, documentation is important. The difference between the Cathedral and the Bazaar, though, is, that most of the code generated using a Cathedral approach is not reused, while a Bazaar approach of coding reuses to the maximum. Of course this is only partially true, since a cathedralian program usually has several releases and of course each release does not start from scratch. But most probably the programmers/hackers who work on the new release are the ones who worked on the previous version or are affiliated with them (co-workers in the same company for example), so that a documentation is not crucial. On the contrary in the bazarian approach, people who give ideas for new features or people who actually enhance the source code of any open source software might have never worked on any of the previous releases and even more most probably never met the maker of the software in person. So, there is no better way to make the source code understandable, but by documenting it.
Linux was not built from scratch, it was based on Minix – another open source operating system. Even if none of the Minix code is existent in the newest versions, it set the building block for Linux. The development and enhancement of Linux also follows the Bazaar model, which means that Linux users themselves can access the source code, change it and reuse it. The users act as testers, as well as programmers. I am sure that the Linux source code has millions of lines. Reusing such a code without documentation is impossible. That is why documentation is the only way for programmers/hackers to interact with the code and with each other.
It might be, that not all open source communities or not all open source programmers/hackers code in an open and understandable way – speak: documenting everything – but this should be the case for all open source softwares.
Of course the need for documentation rises with the complexity of the software, but even a simple one could only gain from being well documented.
I agree with Majid's opinion that documentation is particularly important for open-source/Bazaar-style projects and in my opinion it has a great influence on the success or failure of the project. Since there is no direct interaction between the developers/contributors, documentation provides an optimal way for "new comers" to become familiar with the code and the usage of the software. Documentation also serves experienced developers to understand the contributions of others, making it easier for them to reuse/modify the code if necessary. Ideally, all open-source projects should be very well documented, and this is the case in almost all of the successful projects. However, due to the nature of the Bazaarian-model and the fact the documentation develops with the software, some projects or features with some project might not be so well documented. The usually happens when different people are responsible for coding/documentation which is typical since good programmers are not always good documenters.
Baher 09:23, 19 October 2009 (UTC)
Can you see the preconditions of a Bazaar model ever fulfilled in our GUC community? (Ahmed-Yasser)
Reviewer: Mohammed Zakaria
Before I can begin to state whether I think GUC can adapt the Bazaar model by implementing the preconditions I would first like to try and spectate on the current system we have now. Those systems can be split into two main categories, the academic standards where the work would be an assignment or a project that would directly affect the grade of a certain subject, or the software used for the development of university services such as web portals, administrative tasks and IT related tasks.
A quick review of the preconditions of a Bazaar model is, 1: A society, the power of the Bazaar model is that a larger number of users allow delegation that allows the workflow to be parallel hence decreasing developing and bugging time. 2: Code to work on as the Bazaar model is used to improve an existing written program and not construct one from scratch. 3: The open source licensing, by including a semi open source license (where everyone is notified to what and who has changed what) the development timing is severely increased, which violates the Release Early, Release Often requirement. This wasn't stated but I find it important as it carries an important role in the distribution of grades. 4: Charm, to get the community hyped up.
Now in the aspect of the academic side of GUC the Bazaar model does reach a few pitfalls if given the same scale projects as we are accustomed, one of which being plagiarism [8]. A certain colleague of mine was once very famous for being able to understand code and its design details faster than others that code it, but had a few problems with the actual development of the program himself. As the basis for our career within the computer engineering field I believe that given the option to be able to easily view other students work would result in a lack of creativity and problem solving. On the other hand harder projects can be given out with a certain amount of control from the Academic staff which would allow them to monitor the students participation while also allowing the full benefit of the rapid production rate as well as the multiple skills that can be acquired from a robust developing environment rather than the small scale projects using the cathedral model we are subject to nowadays. The option to get a functioning program is not hard, especially since alot of the GUC services have been outdated and are being renovated and redesigned by students carrying out their bachelors, as well as the hundreds of requests for functions within programs that could be found within the open source society today.
From the view of an open source society without the academic interference within GUC should be fairly easy, mainly because people will only send in fixes if they personally feel like contributing or to fix an itch, for example as Dr. Fatma has stated with her desire to add a few functions within the met website. And as this society would involve all students within university, academics and hopefully alumni (that would mainly be us for now!) its user base would be pretty huge, keeping in consideration that not only engineers are used yet every major, from artwork to bugging reports and documentation. This system already meets the preconditions as the amount of potential participants in GUC are alot, all systems are online and working, and they mostly can use a bit of polish and shine. And the nice thing about open source is you rarely can ever get worse, and if you do... well, that’s what the version and build tracker is for!
As for charm, I don't think the possibility of dealing with future work collegues, no wonder how great, will ever suffice to the same amount of social interaction and word of mouth that one can get during his university years. Personal opinion!
I would also like to state that the Bazaar model does not have to be used only in the development in a computer program, but in a variety of different applications, from science to art and music. While this seriously negates the original matter of perception (that an invention has an inventor or a song has an artist) it could also speed up the process, and dramaticly increase the creativity of the users, as well as bring them alot more immense feedback. [9].
Sorry if this went a bit (or ALOT) off topic. Feel free to downsize as much as you want.
I agree with Ahmed Yasser that the Bazaar style can be used to every field, and I think it can be used very efficiently in research in any field, but I have a different opinion than his in a few points. I don't see the user base of the GUC including its students, staff, and alumni a large user base, it doesn't exceed a few thousands, and don't forget that only 5% may be are able to contribute to any open source software, and only 1% will really contribute to the project(personal opinion), so you can't build, improve, or maintain a large open source project using only this co-developer base unless there is a good reason for them to give a lot of effort to it. This can really happen if their contribution was through a course project or a bachelor project, and this is the second point I disagree with Ahmed about. Contributing to an open-source project through a course project or a bachelor project is a good choice, it motivates the co-developers far better than only contributing because they feel like it. So if it is a course project the number of contributers will be large enough to be able to build an average size project even from scratch, the quality of the result depends on the quality and motivation of the contributers, however I think it will result in a better result in a shorter time. And if the contributers in the project contributed through their bachelor project, the result will even be of better quality, and the open-source project will need less developers. The charm of working in an open-source community in the university is not enough as a motivator for university students, and this my third point, may be Ahmed Yasser is right concerning the social interaction during the university years, but I think most people don't think that way, only a few people will participate without getting a direct benefit from contributing to a software. When there is a really large user base there will be enough to contribute, but I don't think the GUC user base is large enough. The final point I disagree about is that I think every invention has an inventor, but not necessarily one, in our case we have a lot of co-inventors\artists. Now I'd like to add a few points Ahmed Yasser didn't talk about. First for a bazaar style project to work we need a good management and support, this may be the most important aspect of a successful open-source software, and the most aspect our university lacks. And there is one more thing needed for the success of a project, the need to it, we need to work on a project that we really need, fun projects start and stop often and doesn't take enough time to be good ones. --[[User:Ziko|Mohamed Zakaria]] 02:00, 19 October 2009 (UTC)
God bless system crashes. After reading the review several times I realized that most of his findings are correct, a university run open source project would get a lot further in a lot less time. However when it comes to him saying that the university does not have the user base I have to object. I personally think that his opinion is based on open source being specially made for computer engineers whom will dedicate their time to the code. In my own personal opinion this is incorrect as the user base will mainly be the debuggers, who consist of most students. What makes me say this isn't that the students are energetic and willing to contribute more then the basic human trigger of curiosity that will allow them to try out new features which may automatically become a response database for the programmers. As I have also stated within my review was that the open source society consists of testers, artwork, documenters and others which can be spanned over a larger audience. Hence not limiting the user base available to only engineers. As for the management and support, from my reading of the article I have assumed that the hectic nature of the bazaar in itself, including all of its members, create an order. Different authority is meant to be delegated based on both the programmers need while also allowing project managers (mainly project creators and maintainers) to decide whether or not the feature can be delegated to the certain level of the volunteers skill. Hence the management should naturally find itself within the system. --~~~~
Do you think that teaching the Bazaar model for computer science students is a must or just optional? (Omar Roushdy)
Reviewer: Aya Mahfouz
Before starting to talk about wether or not the Bazaar model for computer science students is a must or just optional, i would like to talk about how linux was affected by the bazaar model. Linux is an open source software collaboration mainly based on the Bazaar model, this means that all the underlying source code can be used, freely modified, and redistributed by anyone under the terms or the license of the mother company. As mentioned in the article, linux resembled a great babbling bazaar of different agendas and approaches which resulted in a coherent and stable system, moreover this system helped the whole system to go from strength to strength at a speed were cathedral-builders dream of.
In my point of view, bazaar model should be obligatory to computer science students due to many reasons. As mentioned in the article, "Good programmers know what to write. Great ones know what to rewrite (and reuse)". Writing a program from scratch could be very hectic, needs a lot of effort and a number of people, or needs a lot of programming skills which could not be present, therefore, one shouldn't write a program from scratch to be a good programmer, he could start from a partial solution by another programmer or developer and reach the same or better solutions. Moving on we reach another quote saying "Every good work of software starts by scratching a developer's personal itch". Most programmers spend their days implementing and developing software that they neither need nor love just for pay. This exlpains why the average quality of the linux software is so high, because developers are forced to grind away for pay at programs, they just could start editing and developing previously created software, this is better for the developer in-terms of effort, time spent on creating things which are already done and just need to be modified, and giving a chance to less experienced programmers who donot have the skills to create a program from scratch, to modify or optimize this software.
All previously stated points are the reasons for the Bazaar model to be obligatory on computer science students. I believe it helps them to be creative without the need to have the experience of their professors or other programmers, a certain base level of design and coding skill is required, of course, but I expect almost anybody seriously thinking of launching a bazaar effort will already be above that minimum.
--aserkm 19:06, 16 October 2009 (UTC)
Omar provides many good points what students can gain from the Bazaar model. I will summarize what I grasped in the following list:
* Good Programmers do not want to waste their time rewriting existing code.
* Reuse of existing code eliminates the need to gather many programmers and possession of non-existent programming skills.
* Good ideas can start from partial solutions.
* The quality of Linux software projects comes from the fact the programmers code something they need and care about.
* The Bazaar model provides students the chance to implement creative ideas without writing the code from scratch and gaining all
the programming skills to implement such an idea.
* The Bazaar model is essential for students because it gives them the freedom to learn from many different sources not just
the University or other Programmers.
I do agree with Omar on all the points that he mentioned but I hoped that he could provide more details and reasons for why students
should be introduced to the Bazaar model. He provided the general reasons but did not mention how would the students benefit in
the short- or long- term. As programmers suffer in the real world from coding projects that they don't care about or need just
for the sake of earning a living, students suffer from the fact that they have to learn programming languages that they will not use
in the future and write code that will help them learn concrete concepts but eventually is thrown away. In the best case, students
do something to earn marks as programmers write code to make money.
Another point I was eager to read about in Omar's writing is his experiences and needs as a student and why would such a model
help him and others. In gerneral students write code to learn whereas programmers learn to write new pieces of code.
Can the academia and the Open-source community collobarate to benefit both sides? Yes they can and here is how, the code
that needs to be rewritten or maintained can be assigned to the students as assignments and projects in the universities.
Optimizations for existing code could be delegated to students in their senior years. These ideas should be applied
in a non-restrictive, rewarding and interesting manner. If such a model can be developed and sustained in the universities,
students will be having a hands-on approach that convinces them that they need what they learn right now to be able to adapt
to the world's needs. They will also get in touch with the latest technologies and approaches in the Software community as
the Open-source community is an early adopter and actually a test bed for such crude ideas .
My last comment on Omar's section is that I really wanted to see him talking about the eagerness and enthusiasm of Students
to do something. Students strive to prove themselves and search for opportunities that benefits them in every aspect.
They seek an answer for every question they have and look for opportunities in the form of competitions and intern ships.
Competitions such as Google Code Jam and ACM ICPC do recognize that but Open-source communities takes it a step further
when students see their work credited and used by other people.
--Omarroushdy 02:11, 26 October 2009 (UTC)
Aya's review is I think fair and states some drawbacks in my review which gives me another view of the problem. Firstly, i liked the point were she added how students benefit on the short and long term but I don't think the reasons were convincing for me, or she did not elaborate them well. The bazaar model would help students develop and improve their programming skills, this is on the short term. On the other hand, on the long term it would help them escape spending hours and days working on programming or developing software they don't even like only for the sake of money. Moreover, in the last point in Aya's review, she talks about how would the bazaar model affect the students' eagerness and enthusiasm. This would give the students a push to develop and explore the world of open source programming or known here as the bazaar model. When students do some changes in an open source program or improve a program by a way or another, and then they find that it is credited and is being used by other people, it gives them the push needed to be more creative and dig deeper in this field. Other than that, i agree with the rest of the post as stated in my review.
The psychology that drives the Bazaar model (Aya Saif El-yazal Mahfouz)
Reviewer: El Noury
How selfishness laid down the Bazaar model rules
In the CAB document, Eric Raymond talks about how people (Professional Programmers, Students, Enthusiasts) are attracted to join or create a project that adapts the Bazaar model. They are motivated by an itch to do something that they need. He claims that people's motivations are primarily fuelled by their selfishness which is true. Selfishness in itself is a trait that is present in all human beings but it is not a strategy. Every person will join an open-source project with different tactics and strategies that suits their selfish behaviour. They will find that to maximize their win they will actually need to co-operate in a manner that helps them minimize the work and effort done to get the final product or service. So rules are laid down for the benefit of the majority not a certain group of people. This is great given that every one joins based on a different motive in mind. One of the popular selfish goals that is derives almost all human beings is the act of ego boosting or as Eric Raymond calls it "egoboo".
"egoboo" (the enhancement of one's reputation among other fans)
Although human beings act, claim and know that they are selfish, they need to live and communicate with their counterparts to sustain a normal life, others may call it a social life. The need to be around others raises the need to be recognized in some manner. People want to be popular, funny, happy, successful etc. In the bazaar model, successful communication guarantees participants social recognition. In my personal opinion, which I find to be subjective since it is not based on any study, Social recognition is the final product that results from all the work done to boost's one's personal ego. One can easily recognize many ego-boosting behaviours in the open-source community. I will state two facts taken from the CAB document which is programmers hate documenting their code and open-source projects code is clean. I think that these two facts come from the following ego-boosting scenario. When people join an open-source project they find that there are many ready made functions written by fellow members in the community. Sadly, they find the the code needs cleaning and/or documenting before they start with their own but actually this is the first place for the "egoboo" arena. Cleaning and documenting others code will gain anyone credit and recognition in the community and hence "egoboo". When these programmers start writing their own code they care more about adding new function and utilities, the second "egoboo" arena, to the project more than cleaning and documenting their own. So the process of "egoboo" is continuous and in the end this pours into the project's benefit.
Well, I like the way Aya put things, her review was neatly written and I agree with most of what she had to say. But come to think of it, personally, I believe selfishness only contributes to the first rule which states that "Every good work of software starts by scratching a developer's personal itch". Even that shouldn't entirely be labeled as selfishness. Apart from the first rule, I think staying far away from selfishness as possible is what the bazaar model is based upon. To further clarify my point, let's take a look at some of the other bazaar's rules: - Good programmers know what to write. Great ones know what to rewrite (and reuse). - When you lose interest in a program, your last duty to it is to hand it off to a competent successor. - Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. - Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. - If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource. - The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better. - Provided the development coordinator has a medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one. So as you can see, these traits are far from having to do with selfishness, instead they mainly focus on sharing with as many users as possible. When it came to egoboo though, I didn't fully understand how the ego-boosting scenarios that were mentioned relate to 'programmers hating to document their code'. It's true, documenting other people's code, writing your own well documented code and contributing to the community works as a plus for a person's egoboo, hence developers aim to have well documented code. But I don't see how the aspect of them hating to document their code was relevant to that point.
Very good Aya. I enjoyed reading this so much. I feel you really understood what Eric Raymond is talking about. I admit that everyone has this selfishness that drives him to do something. It is only human but what is great is that the dynamics of open source communities somehow convert this selfishness to something good for everyone. In a way, I feel open source communities are like open educational environments (a university, may be) that doesn't : have the student/teacher structure. It is just there for whoever want to learn. That person will find a mentor, a friend, a reviewer and eventually a career :) And shehab, good review as well :)
--Fmeawad 14:02, 23 October 2009 (UTC)
Thank you Shehab and Dr. Fatma for your reviews. As for Shehab, I do agree with you but it seems that you did not realize that I talk about selfishness as a strategy not a trait. If you happen to be familiar with game theory, players lay down their strategies and that of their opponents and draw a pay-off matrix. They choose the strategy that helps them maximize their profit in all consequences. You pointed out to many points that seems to conflict with selfishness. But actually they only seem to conflict if people do not think about their decisions in the long run. I will take some points, ask some selfish questions and I hope that you get my point Good programmers know what to write. Great ones know what to rewrite (and reuse) If I as a programmer would like to get some new idea implemented as fast as possible. Should I waste my time on rewriting existing code or should I take some ready made clean code, build on it and rewrite only the parts that I would like to change? When you lose interest in a program, your last duty to it is to hand it off to a competent successor. There is an open-source program that I spent a lot of time and effort writing code to enhance it. Now, if I am responsible for that program in any means should I simply throw it away or let some else complete on it and ensure that the program is still working and someone is still using it? Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. If I have some good idea should I simply write the program and get all the reviews after I write it to polish it? Or take opinions while working on it and see the result after collecting some worthy reviews. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better. Now if I would like to proceed with a community and keep it alive should I depend on my ideas only that for sure run out one day or attract people from different backgrounds and make my community thrive? In all the mentioned points, ask a smart selfish person and I think you will know what the answer in advance is. As I mentioned before don't think of selfishness as a trait think of it a strategy to maximize your win. This is the open-source community, passionate people with ideas who are selfish in a smart way and know what are their profits in the long run. As for “egoboo”, in the open-source community you do not have to document your code , if you hate writing documentation, for people to use it. Others can do that job for you and get some recognition in the project community.
aserkm 19:48, 30 October 2009 (UTC)
A visually sum up of the CAB document or some of its principles? (Extra)
Reviewer: Everyone is encouraged to review this one
"It's no fun to be responsible for fixing bugs in a program you don't understand." (Muaz Al-Jarhi)
Reviewer: Majid Hassan
Should you understand a program before attempting to fix bugs in it?
Assume you have a program code. You read through the code and you see that the code is not well-documented, is all messed up, you could not follow the code and you could not figure out what the program is supposed to do or how it works. If your task is to fix a bug in this program will you carry out this task? What will be your feelings when carrying out this task? Basically, not understanding a program code should only lead you to one of two things: either leaving the program alone or rewriting the program code into something that you can understand. Else, it will take you a long and harsh time trying to fix bugs in the program or improving it which is not worth it. Rewriting code may waste some of your time which leads to this: how can anyone make his program code understandable to anyone else?
--Majid Hassan 18:33, 18 October 2009 (UTC)
I do not really agree on some of the points Muaz mentions in his review. First of all, its a "program you don't understand". Of course I understand, that taking the extreme case is better for clarifying ones point of view, but still a "program you don't understand" might be organized (still undocumented, but organized). Another point is, why would you be asked to fix a bug in a program where you don't even know what it is supposed to do? At least you do know what it is supposed to do. And that applies for both cases the cathedral and the bazaar system. I think I don't need to explain why this applies for the cathedral system, but even in a bazaar system: as a programmer you will not be interested in fixing a bug for an open source system if you have no clue what this program does. What is the idea of fixing it then? Another point I disagree with is that "understanding a program code should only lead [...] to one of two things [...]." If you don't understand "what the program is supposed to do" then how could you rewrite it? A third option I would like to introduce is actually trying to understand the code (which is in all cases easier than rewriting it). The point Muaz is trying to prove - as far as I understand - is, that fixing a bug in an undocumented and messy program code is a time-consuming, tough and boring job. I agree.
Conclusive Remarks
How well can you see the students at the GUC embracing the bazaar style? Is there hope for that?
Outlook
References
- ↑ The Cathedral and The Bazaar By Eric Raymond
- ↑ http://en.wikipedia.org/wiki/Antoine_de_Saint_Exupéry
- ↑ http://www.joelonsoftware.com/articles/fog0000000069.html
- ↑ A. S. Tanenbaum, "Modern Operating Systems", (2rd Edition),Prentice Hall, 2001.
- ↑ Romain Moisescot. (2006) "All about Steve Jobs". Available at: http://www.allaboutstevejobs.com/bio/long/03.html (Accessed: 11 October 2009)
