[kforge-dev] making branches, etc.

Tue Nov 21 14:39:01 UTC 2006

dear John, all,
On Mon, Nov 20, 2006 at 07:58:11PM +0000, John Bywater wrote:
> To be clear, I strongly disagree with the proposal to branch except for
> CONTINUOUS INTEGRATION, one of the critical agile practices.

Depends how you're using the branch, though? Some projects focus
development on an "activity branch" which is continuously tested with
a system like buildbot. It's a matter of opinion. I would be happy
enough with a public 'sandbox' to experiment in. 
cf http://www.zope.org/DevHome/CVS/ZopeCVSFAQ

> I should also say, just in case there is any
> confusion about the applicability of such practices to small Free
> Software projects, be very sure: the concerns and propositions of the
> agile approach are dimensionless, and apply to large and small project
> (albeit with some variation) including projects with only two or three
> people.

I'm sorry to have skipped over your last email, as this is partly a 
response to it too. I don't agree that the concerns and propositions
of the agile approach or of your practise are all appropriate for 
open source software development. I hope it's clear that i'm not and
never have been challenging test-driven development. But I look at 
writing about the propositions of agile - such as
http://agilemanifesto.org/principles.html or
http://en.wikipedia.org/wiki/Agile_programming and I find there 
elements that aren't a good fit for the production of open source software.

The descriptions of agile read to me as partially wonderful and partially
shaped by a commercial software development environment, the context
which the practise emerged from. Now this may make me sound like an old 
hippie hacker but what of it, open source doesn't fit agile completely.

Every day, thousands of people turn up at hundreds of open source
projects, seeking to contribute. They likely do this because the project:

a/ looks to them like being fun to work on
b/ helps them expand something they're already working on
c/ is enough like what they're already working on, that they feel
inclined to contribute rather than 'compete'.

I've heard this phrase attributed to a couple of open source
developers: "If i can't figure out how to contribute meaningfully
within 5 minutes, I'll walk away." A person involved with one project
is likely to be involved with many, their time is precious and focus is
intense. A person may come along with interest, but at a skill level
where they can't bootstrap without a lot of encouragement, and it's a
current developer's choice whether to sink time into helping. Happily,
people on the 'edge', not right in the core of a project are more
helpful to newcomers; but they too need to bootstrap into involvement.
So every contribution is treated as potentially valuable.

Agile has expectations that open source can't meet, so we have to work
in some different ways. Agile heavily emphasises physical proximity
and F2F decision-sharing. We can't rely on that; so the agile
principle "working code is emphasised over complete documentation" has
to be downgraded; developer documentation is very important to us.
People don't have time to read a lot, it helps if we focus on API
documentation, and lots of diagrams (UML, if you like) of the system
design.

Often projects are started by developers working for a company or a
consultancy. Even in that situation there is no "owner" of the project;
decisions are reached through shared understanding, not imposition or
approval; there may be a set of requirements, there may be clients for
applications but the clients don't control the requirements.

This isn't to say open source projects don't have people 'in control';
the best of these i have seen in action is very responsive, super
friendly, nudging and connecting other developers, marshalling freezes
and thaws for other dependent projects, has in theory a 'committee
chair' role but you would never know it from his methods; things just
keep running. 

A stance of "learn my language and adopt my methods completely before
i will discuss software with you" isn't going to work on an open source 
project. I don't think that repeatedly haranguing people over mistakes, 
or condescending to them when they reveal ignorance, is a helpful way 
to proceed. "there is no value in passing blame; everyone is in it together"
says Alistair Cockburn in his agile-derived project-self-management principles. 

...

jo