I'm trying to analyze the development process of successful OpenSource projects 'cause I think they share a lot of principles with the AgileDevelopment approach.
In AlistairCockburn's Characterizing People as Non-Linear, First-Order Components in Software Development I read:
"The short of the story is that we have been designing complex systems whose active components are variable and highly non-linear components called people, without characterizing these components or their effect on the system being designed. Upon reflection, this seems absurd, but remarkably few people in our field have devoted serious energy to understanding how these things called people affect software development."
I really like to know what do you think about EricRaymond's 'TheCathedralAndTheBazaar' (first edition: 1997) in which Eric wrote these (I took just the ones I think are in common with your work and Agile principles in general):
- 4. If you have the right attitude, interesting problems will find you.
- 5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
- 6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
- 7. Release early. Release often. And listen to your customers
- 8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone
- 10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
- 11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
- 13. ``Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.''
- 18. To solve an interesting problem, start by finding a problem that is interesting to you
- 19: 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
I find common values between Agile principles and Open-Source-bazaar-style development as described in Raymond's work.
Don't you think it could be interesting digging into the development process of a successful OpenSource project?
-- MarcoAbis
BoF session on Open Source and Agile at Linux Bangalore 2004
On Dec 3rd, soon after yogi's and my presentation on TestDrivenDevelopment using open source tools and frameworks, ThoughtWorks conducted a BoF on Open Source and Agile. The agenda of this BoF was
- 1. Introduction to Agile methodologies
- 2. Philosophy behind open source and agile
- 3. How open source and agile gel with each other or go hand-in-hand
- 4. Agile practices that can be used in open source
We had a decent group of 10-15 people. The BoF started off with everyone's introduction. Participants shared their experience with open source and agile. There was a nice balance of people who were open source contributors and who had used agile (mostly
ExtremeProgramming (XP)).
Post introduction, there were lots of people who were interested in understanding concepts of agile. At this stage, we stated the 4 values of XP, i.e. Communication, Simplicity, Feedback and Courage. We looked at how this fits into the open source world. And everyone agreed that these 4 values fit very well with open source development. Next, we briefly explained them the 12 practices of XP.
Except
PairProgramming,
FortyHourWeek and
OnsiteCustomer, everyone agreed that the rest practices are at the crux of the open source development. This led us to a very interesting discussion about customers on an open source project. Basically we had 3 main questions to address
- Who are the customers on an OpenSource project?
- What is the role of a customer on an OpenSource project?
- Over a period of time, how the customers change?
All of us agree to the fact that "Every good work of
OpenSource software starts by scratching a developer's personal itch." and "Necessity is the mother of invention". Hence the author of the
OpenSource project is the customer on the project. S/He knows the best of what s/he needs. S/He knows how to prioritize features and set the milestones for the project. But as the project proceeds and becomes an open source, then the customer shifts from the author to the community of users. It's basically the community, which will drive the features and fix the milestones for the projects. If the author does not agree with the community, then s/he might lose the community. Hence we agreed that the objective of having an
OnsiteCustomer in an agile project and a community in an
OpenSource project is the same.
PairProgramming is something that seems quite difficult in a distributed OpenSource model. Though CodeReviews happen to a great extent on OpenSource projects, they don't happen along with development. But the OpenSource contributors do feel the importance of pair programming.
Lastly, the FortyHourWeek issue. Since the model of an OpenSource development is mostly that, people contribute in their free time (mostly after work), this principle does not apply as it is. But when we think of the objective of the 40-hour week, it basically means that, you don't burn out your developers. Let them not be over-stressed. They can work best when they are fresh. But the most important aspect is to not force your developers to work. It's the freedom aspect that stands out and the associated benefits out of it. People have the freedom to work on OpenSource projects as long as they are interested (in a day and also on a long run). They have the freedom to be a part of the project as long as they think they are contributing/gaining out of it. Hence I tend to feel that the 40-hour week works perfectly fine in both the cases.
There are a few other aspects of open source, which gel well with the agile philosophy. Following are a few of these
- Release early, Release often
- Listen to your customers
- Test, test and test
- Energy levels or enthusiasm of the team members
- Delegate everything you can,
- Be open to the point of promiscuity
- If you have the right attitude, interesting problems will find you.
- Don't be afraid to throw away code, if you don't feel good about it
- Simple Design & minimum-effort path (simplest thing that works but not the dumbest thing)
- Debugging is parallelizable
- Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away
By this time we had to run out of the venue else we would be locked for the whole night talking about open source and agile. Though I would love to do this, there are other social aspects of life that have a strong influence on my decisions.
But in the end, open source continuators had a much better understanding of agile (mostly XP). Some of them did ask for help in implementing some of these practices on their current open source projects. This gave a good feeling at the end of the day after all the talking.
-- NareshJain?
CategoryAgileMethodology
Open Source As Agile Process