On Fri, Feb 10, 2012 at 5:51 AM, David Karger <kar...@mit.edu> wrote:
> As I tried to indicate in my last email, I'm actually quite sanguine > regarding whetever commit process the community evolves going forward. > There's no rush to figure it out and I'm sure I'll be happy to follow it. > In particular if I find it too burdensome I can just stop coding. Also, > this process will be focused on E3, as E2 development is ending. > > My *immediate* concern is the code I've *already* developed for *E2* in > the absence of any clear commit process. I'd like to arrive at a decision > about its disposition, one that hopefully doesn't involve throwing it all > away. I'm sitting on a (fait accompli) bunch of code that I think will be > of use to the current users, so I'd like to incorporate it. > Fair enough, let's get practical and decouple the immediate needs from the need for more explicit governance rules. Here is what I would do: 1) move the existing svn "trunk" into a branch, say "branches/davidk_2.3a" 2) copy the "tags/2.2.0" release as "trunk" 3) tell people NOT to update their svn if they're running from trunk until this conflict is resolved 4) create a diff between "branches/davidk_2.3a" and the current "trunk" (which is now the latest released exhibit) 5) put the above patch up for review (for example, a very good one that mimics the tool that Google uses internally is http://codereview.appspot.com/, but any public code review places would work) 6) collect suggestions from the community there on what part of this patch should be "pulled" into trunk for an immediate release and what should remain there up for further discussion on alignment with the 3.0 tree, governance and ownership rules, maintenance responsibilities and what not 7) apply the community reviewed patch to trunk, release it as 2.2.1 if there is no added functionality but only bugfixes, 2.3.0 if there are additions in functionality as well but back compatibility is guaranteed... if it's not back compatible, it shouldn't have made it into the patch in the first place. 8) tell people the harmonization is done and they are free to update from trunk again 8) whatever is left on the floor of the editing room will probably need further discussions on where it should live, although my suggestions would be against further development on a "vendor" branch and rather use the github model instead, and that might require us to move the mainline from svn to git, although it might not be necessary since git can also talk to an svn repository. The above process would give you increase vitality and freshness in the mainline that you seek and reduce the impedance mismatch between the agreed upon 2.2 -> 3.0 transition path and the currently proposed 2.3a "detour". Now, granted, the devil is in the details and such a code review might yield consensus that might not fit 100% your needs... at the same time, it will bring confidence to the fact that this community can self-regulate and protect its users interests, however varied they are and will allow you a clear path that can be repeated in the future. In fact, I would venture to suggest that using a review-then-commit model might be much better suited for this project, considering the variety of interests surrounding it and the different in skillsets in terms of programming and backgrounds in production-quality software engineering. All the above will sound painfully convoluted, I'm fully aware of that, but I don't see an easier way to resolve the current impasse in ways that help everybody involved. > > On 2/10/2012 3:33 AM, Stefano Mazzocchi wrote: > >> 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. >> >> -- Stefano. -- You received this message because you are subscribed to the Google Groups "SIMILE Widgets" group. To post to this group, send email to simile-widgets@googlegroups.com. To unsubscribe from this group, send email to simile-widgets+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/simile-widgets?hl=en.
