[Bioperl-l] distant thoughts from a dinosaur...
sac at bioperl.org
Mon Jul 7 19:30:33 EDT 2003
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.
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.)
On Monday, Jul 7, 2003, at 11:22 US/Pacific, Ewan Birney wrote:
> --- 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
> - 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 3621 bytes
Desc: not available
Url : http://portal.open-bio.org/pipermail/bioperl-l/attachments/20030707/09bf975c/attachment.bin
More information about the Bioperl-l