Open Source As Agile Process

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): 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

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 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 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?


View edit of October 18, 2009 or FindPage with title or text search