I find this post disturbing. Had it been posted before the vote closed I most certainly would have voted -1 as we don't encourage hostile forks at the ASF.
Ralph On Dec 30, 2011, at 12:30 PM, Ethan Jucovy wrote: > -1 > > The Bloodhound proposal is to build an issue tracker by first importing the > Trac core code into the Apache Subversion repository. As currently > planned, this project has potential to be detrimental to the existing Trac > brand and community, and it seems that the Bloodhound project's goals could > equally be achieved without taking the heavy-handed first step of forking > the Trac codebase. I hope that the Bloodhound team will consider building > Bloodhound as a set of plugins and configurations and an installer that > distributes them with an upstream Trac version, rather than forking Trac as > a first resort. > > My concerns fall into three categories: > > a) The Bloodhound proposal contains substantial allegations about the > health of the Trac community and the competence of its maintainers, as > motivating factors for the "fork and rebuild community" approach proposed. > No documented evidence has been provided to support these claims, and many > of the claims are directly contradicted by the publicly available records > in the Trac community's issue tracker, mailing list archives and commit > logs. > > b) Neither the Bloodhound proposal nor the ensuing discussions have > demonstrated any compelling legal, procedural, technical or strategic > reason why Bloodhound should be based on a fork of Trac rather than an > upstream distribution of Trac. > > c) Although the people involved have been friendly and expressed a desire > to keep the two projects in cooperation, the actions taken so far and the > intentions announced are characteristic of a hostile fork. > > -- > > (a) The Bloodhound proposal contains substantial allegations, without > evidence, about the health of the Trac community and the competence of its > maintainers. These allegations are largely contradicted by publicly > available records of the Trac community. > > * The Bloodhound proposal claims, "Private efforts to engage the existing > developers in implementing features have been negatively received[1]." > > (a.1) I was not involved, and all conversations between WANdisco and the > Trac developers were private and off-record, so it is impossible to verify > the actual sequence of events. But, per [2], it seems that what is > referred to here is the following: WANdisco’s developers asked for commit > access to the Trac core, and/or proposed migrating the Trac core to the > Apache Foundation’s infrastructure and governance, with no prior history of > engagement with the Trac community and no prior contributions (see a.2 > below). If this is the case, characterizing it as an offer to "implement > features" which was "negatively received" by the Trac developers is > significantly misleading. > > (a.2) Five out of Bloodhound's six initial core developers have no publicly > documented history of attempting to contribute or engage with Trac's > existing mailing lists, issue tracker, or subversion repository[3,4,5,6,7]. > The contributions of the one developer who has participated on the Trac > mailing list and issue tracker have been well received[8,9]. > > * The proposal also says: "As discussed earlier, the current Trac > development community is small and reluctant to accept outside > contributions[1]." This last statement is false: > > (a.3) Outside contributions from non-core developers are certainly > accepted. A quick search of Trac’s issue tracker turns up at least six > patches submitted by non-core developers and merged in to core within the > past four months[10,11,12,13,14,15]. Other contributions like bug reports > and documentation are also accepted and well received. > > (a.4) Furthermore, outside contributors with a history of good submissions > are granted direct commit access. According to the Trac project wiki the > core currently has five active developers with wholesale commit > access[16]. Two of those developers became core committers in the past > year, based explicitly on their records of prior contributions[17,18]. > > -- > > (b) WANdisco's Ian Wild said that "We'd rather only fork what we have > to[19]" but neither the Bloodhound proposal nor the ensuing discussions > have demonstrated any substantial legal, procedural, technical or strategic > reason why Bloodhound should be based on a fork of Trac rather than an > upstream distribution of Trac. > > (b.1) Legal: On the trac-dev mailing list, in explaining WANdisco’s > decision to propose a fork, Ian Wild said, "The strong governance and very > important legal protections that the Apache Software Foundation provide are > not matched by the current Trac setup[20]." This may be true (I am not in > a position to judge) but as far as I understand, the "legal protections" > concern does not seem relevant to the decision to fork, one way or another. > IANAL, but it seems that precisely the same legal protections would be in > force for the Bloodhound project if its developers build upon an upstream > Trac distribution rather than forking it. > > My understanding is that the Apache Foundation is not in a position to hold > and enforce the Trac core's copyright without a Transfer of Copyright from > the current copyright holders, whether or not the code is forked into an > Apache repository. Therefore any copyright enforcement // brand protection > that the ASF can offer would only apply to new code in the Bloodhound > project, and not the initial Trac codebase upon which it is based. > > (b.2) Procedural: as described above (a.2, a.3, a.4) there is no reason to > believe that the Trac core team would reject contributions from Bloodhound > participants, and if Bloodhound participants provided consistently good > contributions faster than the core team could review them, there is > precedent for being granted commit access. > > (b.3) Technical: as the Bloodhound proposal says, Trac has "a pluggable > infrastructure, and is generally considered stable." Trac's component > architecture allows for a wide ecosystem of plugins and configurations to > extend Trac with custom data models, business logic, workflows, external > application integrations, and themes; that ecosystem is supported by the > Trac Hacks community website and mailing list as well as the trac-users > list. At least two installation packages[21, 22] and four other > custom distributions like Bloodhound exist or have existed[23] based on > upstream Trac releases without needing to fork. > > (b.4) Strategic: apparently the features that WANdisco wants to add to Trac > align well with the features already planned/desired by the Trac community > and Trac core team. WANdisco’s Ian Wild said, "During the last year we > collected a list of improvements that we (and others we've spoken to) > believe would make Trac better. Of course there's isn't much new there > compared to the existing Trac wishlist / roadmap. Our view was always that > we wanted to put time into building out some of these things (Multiproject > support springs to mind for example)[24]." > > -- > > (c) WANdisco claims this is a friendly fork, but thus far their actions and > intentions demonstrate no credible commitment to ensuring that their > project remains symbiotic with Trac, and the discussions thus far in the > two communities already provide cause for concern. > > (c.1) In the Bloodhound thread on the trac-dev mailing list, Trac community > members have expressed concern that the project may detract from the Trac > brand, siphon away developer interest, or add maintenance burden for plugin > authors, documentation authors, and tech support. Bloodhound’s initiators > have not substantially addressed these concerns; their only response to > these concerns to date has been a "trust us // wait and see" attitude, > saying that "it's too early to talk about specifics" and an offer to set up > a conference call to discuss these issues in parallel with (rather than > blocking) the project's initiation and code migration as an > Apache-incubated project. WANdisco’s Ian Wild said [25]: > > "I understand the argument, but I don't believe thats what will happen. I > can imagine that Apache Bloodhound might result in new life [...] but I > just don't believe the efforts will be conflicting or negative to the Trac > base. [...] It's too early to talk about specifics, but there are plenty of > precedents with positive outcomes from similar situations." > > (c.2) At the same time, and contradicting these assurances (also > contradicting their claims about the size and viability of the Trac > community) the project initiators have specifically announced that their > initial strategy for community-building will be to siphon developers' > attention away from Trac to Bloodhound. The Bloodhound proposal states: "The > target audience for growing the developer community is the current Trac > user and developer communities." Other statements in the proposal[26] and > on trac-dev[27] confirm these intentions. While they are certainly welcome > gestures, the inherent contradiction between these intentions and > WANdisco’s assurances that their "intention is in no way to undermine the > current Trac project and the progress that is making[28]" suggests that the > project’s initiators do not have the required perspective to maintain a > symbiotic relationship regardless of their good intentions. > > (c.3) Considerable confusion remains over license compatibilities, both > whether BSD-licensed Trac code can be reused in the Bloodhound repository > and whether Apache-licensed Bloodhound code can be reintegrated into the > Trac repository. This has been a source of confusion on the trac-dev > Bloodhound thread recently with no authoritative resolution from an > expert[29, 30]. > > (c.4) Significant discussion about the proposal and its ramifications have > occurred on the trac-dev list in the past few days, only after the > discussion and votes cast on the Apache Incubator list had died down. > > * Ian Wild announced on trac-dev that he would be submitting the Bloodhound > proposal on December 2 > > * Ian Wild followed up to announce that the proposal had been submitted, > also on December 2 > > * Between December 2 - 12 the trac-dev thread received 11 posts from 5 > distinct authors > > * Greg Stein proposed a vote on the Apache Incubator mailing list on > December 15 > > * Hyrum Wright linked to the "complete discussion" on the trac-dev thread > on the Apache Incubator list on December 15 > > * Between December 24 - 28 the trac-dev thread[31] received an additional > 32 posts, from 17 distinct authors, many of which expressed concern, > suspicion or confusion. > > -- > > In short: the Bloodhound proposal consists of incubating an open source > project by cloning the Trac codebase, developing a brand around this > potentially divergent codebase, implementing features already desired by > the Trac core developers, and building the team of contributors by drawing > interest from the existing Trac community. In evaluating the merits of > this proposal it seems essential to consider the accuracy of WANdisco’s > claims about the Trac community’s attitudes, viability, and governance; the > substance of the initiators' reasons for forking; and the publicly stated > opinions of the Trac community as to whether this will be seen as a hostile > fork. In addition, the proposal should not move forward without > satisfactory answers to the following questions: > > * The proposal states that the Trac development community "is small" > and "has largely dissipated," and that "a new project [...] would help > re-build the developer community." If Bloodhound's initiators believe > this, then why does their community-building plan seem to revolve around > reaching out to the existing Trac communities? > > * Does Bloodhound have any concrete community-building strategy that does > not consist of drawing from the existing Trac community in order to bolster > its fork? > > * How will the existence of Bloodhound not be a drain on the attention of > Trac core developers (watching features built in Bloodhound and potentially > taking the time to backport them); Trac plugin authors and maintainers > (being a divergent codebase to evaluate when deciding whether or not to > ensure compatibility); and users providing volunteer assistance in the Trac > mailing lists and IRC channel (adding an additional target > platform+configuration to field questions about) > > * Verifiably false statements about the Trac community's viability, > attitudes, and processes should be removed from the text of the Bloodhound > proposal; as should, preferably, subjective judgments and/or unfalsifiable > assertions in the same vein (e.g. "the development community surrounding > Trac has largely dissipated"; "very few commits to the source code > repository"; "stagnation in the existing community"; private off-record > offers of contributions "negatively received") > > * Authoritative resolutions by a neutral expert should be provided to the > questions of legal compatibility; > > * Specific, substantial explanations should be provided as to why a > pre-emptive fork -- of a stable, highly extensible project with an > established and continued history of accepting core contributions -- is the > only path forward; > > * and, if the "fork and rebuild" proposal stands, a clear, realistic > roadmap should be developed detailing specific actionable steps to be > undertaken which, if successful, would eliminate the specific, substantial > obstacles which necessitate a fork. > > -- > > References: > > [1] http://wiki.apache.org/incubator/BloodhoundProposal > > [2] http://groups.google.com/group/trac-dev/msg/f70e92742bdba15b > > [3] > http://groups.google.com/group/trac-dev/search?group=trac-dev&q=gavin+mcdonald&qt_g=Search+this+group > > [4] > http://groups.google.com/group/trac-dev/search?group=trac-dev&q=mark+poole&qt_g=Search+this+group > > [5] > http://groups.google.com/group/trac-dev/search?group=trac-dev&q=hyrum+wright&qt_g=Search+this+group > > [6] > http://groups.google.com/group/trac-dev/search?group=trac-dev&q=john+chambers&qt_g=Search+this+group > > [7] > http://groups.google.com/group/trac-dev/search?group=trac-dev&q=gary+martin&qt_g=Search+this+group > > [8] > http://groups.google.com/group/trac-dev/search?group=trac-dev&q=mat+booth&qt_g=Search+this+group > > [9] > http://trac.edgewall.org/query?reporter=~matbooth&or&cc=~matbooth&or&owner=~matbooth&col=id&col=summary&col=owner&col=type&col=status&col=priority&col=milestone&order=priority > > > [10] http://trac.edgewall.org/ticket/10318 > > [11] http://trac.edgewall.org/ticket/10322 > > [12] http://trac.edgewall.org/ticket/10368 > > [13] http://trac.edgewall.org/ticket/10377 > > [14] http://trac.edgewall.org/ticket/10490 > > [15] http://trac.edgewall.org/ticket/10493 > > > [16] http://trac.edgewall.org/wiki/TracTeam > > [17] > http://groups.google.com/group/trac-dev/browse_thread/thread/560ed779f62d455b > > [18] > http://groups.google.com/group/trac-dev/browse_thread/thread/24bb9cdc4c458b79 > > > [19] http://groups.google.com/group/trac-dev/msg/5dfc9284fa54cc08 > > [20] > http://groups.google.com/group/trac-dev/msg/b00884f5f6017d4a<http://groups.google.com/group/trac-dev/msg/b00884f5f6017d4a?> > > > [21] http://bitnami.org/stack/trac > > [22] http://clinkerhq.com/products#va > > [23] http://trac.edgewall.org/wiki/TracDerivatives > > > [24] http://groups.google.com/group/trac-dev/msg/9596d8067d0a4c35 > > > [25] http://groups.google.com/group/trac-dev/msg/f49461665c99d691 > > > [26] "Realizing that incubation is an opportunity to grow the community, we > plan to make every attempt possible to invite additional developers from > the existing Trac user and developer communities, including those involved > in plugin development." From > http://wiki.apache.org/incubator/BloodhoundProposal > > [27] "We'll be working closely with some of the plugin developers." From > http://groups.google.com/group/trac-dev/msg/b80211cf4a1b5d4f > > [28] http://groups.google.com/group/trac-dev/msg/2e7db6b2a588c0b5 > > > [29] http://groups.google.com/group/trac-dev/msg/bb68b25cfb26930b > > [30] http://groups.google.com/group/trac-dev/msg/13f3e255a4f4c148 > > > [31] > http://groups.google.com/group/trac-dev/browse_thread/thread/14268355c6e1d494/b00884f5f6017d4a# > for > the complete thread. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
