Allow me to add my 2c to this discussion, mostly out of personal
experience with having started, mentored and transferred ownership and
control of several open source projects, some of which highly
successful and most of which still in existence to this day.

First, let me say that I see value in both sides of the argument: this
proposed release is indeed a fork (and that is bad) but it's also
injecting new vitality into the project (and that is good).

One of the metrics I've used in the past to evaluate the health of
open source communities is their abilities to survive their original
authors/promoters leaving. DavidH has beent he main contributor for
Exhibit (and various other simile widgets like timeline) and his
participation is very much reduced. I had a much smaller role in
development but a bigger one in project/community management, and my
participation is similarly reduced.

The principal reason why communities implode after the original
authors leave is what I normally think of as "thermal death": without
a converging force, entropy kicks in and when it passes a certain
threshold, the project dilutes its social capital and fails to convert
enough users into development contributions. The process is too
diluted to sustain itself and it decays.

My understanding of Ryan's strong reaction is a resonation to that
perception: David actions are in good faith but represent a clear
signal of entropy increase.... and show a path of entropy increase and
dilution of cohesion and social capital.

The plan to split the release in patches that fix existing broken
behaviors from new functionality is wise and a good step forward, but
the problems Ryan outlines are real and should be taken very
seriously: without an established and meritocratic process for vetting
contributions and granting ownership to vested parties, there is no
way this project will survive thermal death.

Before you think "governance rules" and drafting committees and asking
for a grants to foundations to fund various get-togethers around the
country to make it happen, let me just save you all that problem and
propose you a simple one that would work:

1) use a distributed version control system for contributions where
anybody can push their own tree, and the main line pulls from what the
stakeholders consider appropriate (by simple email voting, lazy
consensus and majority ruling, no veto power).

2) stakeholders can ask new stakeholders to be granted that status by
nomination and majority ruling

So, if the majority of stakeholders believes that logging every action
in every page that embeds exhibit to an MIT server is a worthwhile
feature to have, it will be pulled into the main-line and released
officially... if not, it stays in a side branch, away from where it
can do damage if mis-used or mis-understood.

But at least, by virtue of a public process to propose additions to
the mainline, there is the possibility for review... which is what
David proposal lacks and that is causing Ryan's production engineer
spidey sense to tingle.

I understand why this will not sound appealing to David: why go from
the ability to commit code as needed to a process that is more
difficult, time consuming and potentially less appealing for external
(and shy) contributors?

Because if not this project will splinter in many different "vendor"
branches (one as an MIT research platform, one as a Zepheira product,
one as a Library of Congress publishing system and so on) and the
Exhibit brand will be diluted, users will be confused by the
incompatible codebases, the ability to turn their usage into potential
contributions will be drastically reduced, along with the potential
for each vendor to share maintenance costs with one another.

As a result, the ability to promote Exhibit as a funding substrate,
software product or publishing system respectively will considerably
degrade if unity is not promoted and maintained as a core value.

This is why, if I had to pick a side, I would side with Ryan and
focusing on increasing sustainability instead of increasing momentum:
mostly because a valuable and healthy/sustainable project will find a
way to increase its momentum, while a project that increases momentum
by splintering to shed inertia will have diluted its social capital
with that action, potentially so much that it could go below the
threshold that makes the project appealing and find itself slowing
down its momentum irreversibly.

-- 
You received this message because you are subscribed to the Google Groups 
"SIMILE Widgets" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/simile-widgets?hl=en.

Reply via email to