The idea that it might be possible to create software in a commercial setting which is as good in quality and richness as OpenSource
Interesting that people seem to think that software in a commercial setting can not be as good quality as Open Source software. Look at flight control software, or reactor protection systems to see software that not only has a higher quality than open source software, but is demonstrably (provably?) of a higher quality than open source software. (This latter point because there's very little over and above opinion and bug lists to show the quality of open source software)
Sure - hmmm, it would be interesting to see whether such software could also be developed in an OpenSource
setting. Would make a lovely comparison between the two approaches .... Ok, my original statement was an over generalization but I wasn't referring to system critical software, unless, of course, one considers WindowsXX system critical! -- GerritRiessen
I for one, being naïve and a believer in fairies.
[What me cynical? I read Mad. - http://www.dccomics.com/mad/
], believe that XP has potential. Ok, sarcasm by-the-side, I do think that XP has a certain potential to allow corporation to build better software - and that, I think, would be good for the World ... if not for Ozone layer! ;)
Gerrit, I appreciate your initial contributions to Wiki, especially the mixture of serious reflection and good humor. But I need to warn you that this is Wiki. Any repetition of the very damaging accusation that ExtremeProgramming
will not solve the ozone layer UserStory
, probably in its very next iteration, will be seriously frowned upon.
Ok, perhaps a little over the top, I apologize to all those who took offence at my remarks. We didn't at all. The two previous comments should have had an IronyWarning. In other words, they were only a joke about the bias on Wiki towards XP (which most of us here think is pretty wonderful). I apologize for confusing you! -- rd
I do like the ideas described in ExtremeProgramming
, but I fear that ExtremeProgramming
will become YetAnotherMethodology
, or the OpenSource
of the CategoryMethodology
used here in the sense of FreeSoftwareFoundation
which was dismissed for a long time as a freak idea and something that could not possible catch on.
Hence my hope that ExtremeProgramming
will become a kind of CorporateOpenSource
or somehow catch the current wave of OpenSource
, a card carrying XP'ler!
Question: is the association with OpenSource
something that ExtremeProgramming
would encourage, or discourage?
It is something that, for me, is unclear. Obviously I have a predisposition to the answer, however, it is not something that can be taken likely. OpenSource
has certain amount of baggage - good and bad - ExtremeProgramming
has, to date, very little baggage, IMHO.
For me it would a positive association.
I would also see it as positive, but I think XP is particularly designed for the deadline pressure that you find in commercial projects.... XP seems office- and group- centric, and OpenSource
is typically asynchronous and geographically distributed collaboration. In my experience, VirtualPairProgramming
just isn't the same thing. -- ShaeErisson
There is no question that in way it's like comparing apples and oranges, however, they do share certain features (open communication, refactoring, close cooperation with the users, ....) but the best feature they share is the quality of the end result, i.e. they both promise to deliver software that is of the highest quality.
The intention is to market ExtremeProgramming
on the back of the OpenSource
hype by drawing parallels between the two, in particular the end result, and explaining that of course it is impossible to apply OpenSource
to a corporate setting, however, the next best thing would be ExtremeProgramming
BTW Are the similarities between the two approaches pure coincidence? If so, then it would be interesting to see whether the two approaches represent the path of least resistance within their respective environments[assumption frameworks].
I've been mulling over this topic for a while. Here are some notes I put together on this subject.
First, XP & OSS are fundamentally different terms. XP refers to a software development methodology. OSS refers to software released under specific kinds of licenses. OSS is typically developed in a collaborative way. The OSS development method involves volunteers contributing to a code base from many remote locations. Often, the participants never meet in person. Sometimes OSS development is referred to the Bazaar model, as opposed to the Cathedral model.
Here is a list of the XP practices, and comments on how OSS relates:
Other Similarities / Dissimilarities:
- The PlanningGame - don't know
- ShortReleases? - "Release Early, Release Often" - OSS motto
- Metaphor - don't know
- SimpleDesign - Globally Available Code makes possible design suggestions from anyone
- Testing - don't know
- Refactoring - don't know
- PairProgramming - Global Code Review is possible as soon as code is added to repository (not dependent on release), Email & chat communication-only
- CollectiveOwnership - don't know
- ContinuousIntegration - don't know
- 40-Hour Week - Not Applicable because people typically work in their spare time.
- On-Site Customer - Not possible, although the customer has the same read-access to the software as the developers.
- CodingStandards - Important for OSS as well, since individuals from completely different backgrounds, and even people in different countries may contribute to the same code base.
Both XP & OSS take a more human approach to software. XP models the development on a few basic principles that have proven track records, and lack the hierarchical, rigid nature of typical software development today. Members of XP teams communicate with each other continuously, making them more satisfied with their jobs, and generally happier overall.
OSS looks at what users and other developers want, as opposed to just what the software development companies want. They try to shift the rights in favor of users and software developers who would enhance an existing product.
It seems that XP seeks to give more control to the programmers. OSS on the other hand seems to give more control to the end users and future adapters of released software. In both cases, the middle men are explicitly pushed out.
Unconventional Developer Proximity
XP promotes the idea of having pairs of developers elbow-to-elbow during the whole software development process. In addition, they advocate co-location of the entire team in a single room (Expert In Earshot). OSS on the other hand involves a team of developers who rarely have two members in the same location. Often the team is spread across multiple regions of a country, or even spread around the globe.
IMHO, OSS is orthogonal to XP - it is wholly possible to have an OSS project that is developed totally wrong by XP terms, and still be successful. OSS is a licensing type, XP a development style. --PeteHardie
At the risk of getting flamed, I think both OS and XP represent development methodologies. Otherwise products and libraries coming out of sites like sourceXchange.org, sourceForge.org and Apache.org would be a figment of my imagination or just a matter of licensing!
I even believe that the two can be combined in a useful and intelligent manner. For example, sourceForge could do with a customer for each project who should be allowed to download(out of cvs) the entire source and be able to run a series of unit/functional tests to ensure themselves that everything is working. Or that for each project, before the beginning of the project, a series of UserStories
are defined through a remote tool like Wiki. And perhaps something as simple as a SystemMetaphor
which is defined for each project.
can be handled by making one of the project administrators a customer representative, and in the extreme case, no code is checked in without an administrator giving their ok, i.e. a kind of double commit.
can be covered by a tools supporting VirtualPairProgramming
, and other features such as PlanningGame
-s simply aren't supported! I.e. you take the bits of XP which makes sense and the rest you leave off, that after all, is the XP way! ;-)
Is there a term for describing open source style development within a corporate environment (i.e. projects opened up to the entire company including technical sales associates, production support, various admins, developers from other groups with too much time on their hands, etc. as opposed to silo project groups within the company?)
-- Derek Greer