[Bioperl-l] distant thoughts from a dinosaur...

[Lincoln Stein]

The successful open source projects are the ones in which there is a small 
central group to create the design and framework and a large cloud of 
volunteers with clearly defined tasks.

Bioperl needs a clear model of the canonical biological objects: sequence, 
alignment, taxonomic tree, ontology.  This needs to be put together by a 
manageable group with a clear leader.  For each major part, there should be 
one example of how to extend the paradigm.  For example, if SeqIO were to be 
redesigned (which I'm not sure it should be), the core group would create 
SeqIO::embl, and leave the other format parsers to the larger group to work 
on.  Preferably, these modules would be "outside the core" in the sense that 
people could contribute them without extensive refereeing.

I'll take Ewan's advice and not even think of volunteering for the leadership 
position, although I want to be involved in the development of the sequence 
feature model.  Aaron and Heikki have my full confidence.  The idea of an 
outsider is a good one; can someone suggest some names?

Lincoln

On Monday 07 July 2003 09:30 pm, Steve Chervitz wrote:
> Nice comments, Ewan. A two-week break with absolutely no computer
> connection would probably do us all good.
>
> I've been mulling these issues for a while, wondering the best way to
> proceed. Today I noticed some similarities between Bioperl and the
> Mozilla project, which is on the verge of a major overhaul to de-bloat.
> See http://www.mozilla.org/roadmap.html.
>
> I think we can learn some things from these hardcore hackers. One
> lesson I think we should take to heart is: First create a roadmap. In
> this, we would outline what sort of changes we see up ahead for
> Bioperl, and establish some milestones to aim for along the way.
>
> Anyone want to take a crack at a roadmap for Bioperl? Summarizing the
> various bioperl-l discussions would be a start. It might make sense for
> several (or all) core team people to create a roadmap, then merge these
> into a unified version that all core folks agree to.
>
> Parts of the Mozilla code review guidelines may apply to Bioperl as
> well (http://www.mozilla.org/hacking/). Their reviews center on how
> well does a patch fix a bug. For us, think of this as "how well does a
> module solve a bioinformatics need?" (Another code-review idea: Take a
> look at other open-bio projects, see what has/hasn't worked and
> incorporate best-practices from them.)
>
> Regarding:
>
> On Monday, Jul 7, 2003, at 11:22 US/Pacific, Ewan Birney wrote:
> > <snip>
> >    --- I would claim that the main thing we should take from Bioperl is
> > community and culture; being:
> >
> >     - community of people who do real-life bioinformatics in Perl
> >
> >     - culture being open with
> >
> >         - anybody can join; anybody can lead. You prove
> >           yourself by your comments on the list and the
> >           code/documentation you provide
> >
> >         - whoever codes it wins the argument
> >            aka:
> >         - working code trumps abstract arguments
> >
> >         - we should live up to our promises as much as
> >           possible for:
> >              - testing as much as possible
> >              - documenting sensibly
> >              - bug finding and fixing as much as possible
> >              - stability of API when we say it is stable
>
> The community culture is definitely a great part of Bioperl, but we
> might want to re-consider the "whoever codes it wins" motto. At least,
> define what we mean be "wins". We don't want to stifle competition or
> say that the first solution will become *the* Bioperl way for all time.
> There could be a section of BioPAN where people can contribute
> different modules that provide the same functionality. But there would
> be more control over what goes into the core distributions.
>
> Here's are some quotes from the Mozilla roadmap that are relevant:
>
> "Simply put: great applications cannot be managed as common land, with
> whoever is most motivated in a particular area, or just the last to
> check in, determining the piecewise look and feel of the application.
> ..
> Continue the move away from an ownership model involving a large cloud
> of hackers with unlimited CVS access, to a model, more common in the
> open source world, of vigorously defended modules with strong
> leadership and clear delegation..."
>
> Bioperl isn't an application like Mozilla, but it is more like a set of
> applications, a toolkit. They mention the need for "application czars"
> to provide "cross-application consistency" and "coherent UI".
> Substitute module for application and API for UI and I think the
> concept applies to Bioperl as well.
>
> Steve

-- 
========================================================================
Lincoln D. Stein                           Cold Spring Harbor Laboratory
lstein at cshl.org			                  Cold Spring Harbor, NY
========================================================================