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

[Steve Chervitz]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3621 bytes
Desc: not available
Url : http://portal.open-bio.org/pipermail/bioperl-l/attachments/20030707/09bf975c/attachment.bin