XpVsOpenSource

To do this we'd have to have idea's about some/all of the following questions (+ more) :

Are XP and Opensource compatible in anyway? Could you open source an XP project? (I think so) Could you adjust and open source project to be XP. (Would be harder) Which XP practises work well in open source and which do not.

I think somewhere in this there is a fundamental discussion about inter developer bandwidth, which has to be different in the XP and true distributed open source case. --OliBye

Oli, I like your idea of presenting pros/cons + ways of doing it for : "I want to start an open source XP project". The first time I have been introduced to the XtC, I found that, to my surprise, that the worlds of XP and OpenSource?? were 2 separate worlds. I thought they were very near as they were sharing some of the same practices. Apparently there is more than that ... I think understanding what are the differences between OpenSource?? practices and XP is also an output from the BOF because starting an open source project is one thing but making it a successful one is something totally different and this is where the biggest difference is between XP and OpenSource?? !

Ideas in no order (to be sorted) :

Open Source is not a methodology. Rather it is a set of pattern and good practices which are not linked together as in XP for example. Also, there is no established consensus (to my knowledge) on how to develop correctly Open Source projects. I believe it is possible and even desirable for an open source project to be run XP. Or is it really XP ? For example, automated builds running the unit tests : does it come from XP or is it rather an open source practice from long ago ? :) Practices I use on my open source projects (Cactus, ...) but which are common to most open source projects : Unit tests / Integration tests Automated builds (nightly builds) : compilation, packaging (jar, war, ear, ...) automatic documentation generation (changes, todo, features) automatically run unit tests and integration tests (need container) results displayed on a web page (see jakarta.apache.org/builds/gump/latest/ for Cactus nightly builds) Communications through mailing-lists Peer review instead of pair programming : done continuously but after the code has been written as opposed to doing it at the same time with pair programming. Theorically, possibly more eyes with open source peer review. In effect, not always true (no guarantee anyone will actually review the code). OpenSource?? is good for customers because it avoids lock in : when customers buy an infrastructure software (application server, EAI solution, e-CRM solution, ...) to build an application, there is still a lot of glue framework to write for building the application (log, configuration, data access, XML-java mapping, controller in the MVC model, unit test framework, ...). Consultants can be brought in but if they provide their own in-house frameworkm then there is a lock in, whereas an open source framework will provide : reliability, support, enhancements, ... even when the consultancy has left the project ! Project sizes. XP works well for project of reasonable sizes (10-20 persons max) whereas Open Source projects like Linux or more recently like JBoss or Tomcat have hundreds of committers. Open Source projects need to be __very__ careful about the public interfaces as their user base can potentially be huge, is not known and you'll upset them if you start changing too often the public API. An XP project is a much more closed world and it is often easier to deprecate public API. Thus I believe the simple thing that could possibly work need to be slightly revised with open source as you may need to plan a bit ahead, at least for the interfaces. Documentation is a must for an Open Source project. Documentation = user documentation + architecture. Implementation documentation is not explicitely needed but there needs to be good javadoc with examples on usage. A good documentation is what will attract users (exactly what happened with Cactus). Key ingredients to a successful OpenSource?? project. Some are already mentionned above. Main ideas : Good doc, Complete dedication of at least one person (most open source project revolves around one dedicated man with several others helping out from time to time), Change, change and change. The project need to be constantly evolving and making headway. A good project will show the progress on its web site, thus attracting users and making them come back frequently Frequent and small releases (should be less than 1 month between releases) Need good mailing-list support. Of utmost importance ! Need to answer to questions within the same day or next. Make users participate and encourage participation. Charismatic and tolerant persons are very much needed. Responsiveness in general

Some resources : "Managing Projects the Open Source Way" (news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD).

Conclusion : Could we say that the output of the BOF will be the answer to : "I want to start an open source XP project, what's involved ?" or "Cookbook for starting an open source XP project" ? Question : How do we manage the BOF ? What do we need to bring ? Do we start with a list of questions on a board and cover the answers with everyone present, possibly adding news questions as we go along ? How to keep the BOF from going in all directions ?

--VincentMassol

Hey, I just thought I'd direct your attention to Ensembl: www.ensembl.org/ (wiki site: www.ensembl.org/Docs/wiki/html/EnsemblDocs/HomePage.html), the human genome project database in Cambridge. They are a big project that is very open source and is trying to be somewhat XP, including automated tests, (some) design cards, some of the social aspects (or so it seems to me: things like 15-minute stand-up meetings and so on). And they use wiki! (for which Oli can claim credit...) I keep trying to get them to come to XtC. Anyway, might be an interesting case study for the difficulties faced in moving an existing big Open Source project to XP.

--IanHolmes