Hey folks, I felt I had to take a look at this. Like Ralph I was very concerned when I saw Ethan's e-mail. Thanks a lot for writing it Ethan, and thanks for writing it with so much detail.
I just read all the e-mail about bloodhound I could find (that I had pretty much ignored when I saw other people I trust were looking at it) and then I read the last year of trac e-mail traffic (fwiw, the relevant/interesting e-mail concerning the bloodhound proposal is all in the last 2 months, older relevant e-mail is not on publicly archived lists). I have to say I'm a lot less concerned now. First impression: the trac community is full of really nice people and it's mailing lists are full of gentle and carefully considered communication. Very nice to see :-). I wish all open source communities were like that! I really recommend anyone else trying to form an opinion goes and looks at trac-dev. In particular you may want to read the overview one of the core devs from trac wrote for our benefit: https://groups.google.com/d/msg/trac-dev/kMVFq9pkfus/eYMCVfqyUwkJ The bloodhound proposal and communication around it probably could've been handled better over the last 9 months or so, but it also could've been handled much worse. It's a typical example of the difficulty that exists where a company wants to engage an open source community and there isn't a strong legal/commercial story yet. All the parties seem to be trying hard to come up with the best approach for everyone, and the apache approach seems like it should be able to help produce a healthy kind of collaboration. The bloodhound proposers look like they're doing pretty well now in communicating intent and approach clearly on the trac mailing list, and the trac folks in turn seem pretty clear on what is and isn't going on. Bloodhound at apache will probably be better for all, than bloodhound not at apache. If things continue on their current path, apache rules and processes should help minimize negative impact on trac so that the effect on trac will be a definitive net positive. I remember a bit about trac internals from years ago and ISTR it's pretty cleanly split into lots of little bits...so I imagine bloodhound can (and should) take a careful licensing path contributing patches to core upstream as BSD while making new/rewritten plugins available upstream as ALv2. That seems to be the intent, too. Proof will be in the pudding :-D I do think it would be nice and appropriate if someone updates the proposal page along the lines that Ethan mentioned, probably by simply removing the somewhat unfair depictions of the trac community. (perhaps edit the current page, but keep a link there to the version that was voted on, for clarity). All in all I think bloodhound should continue on, and the incubator PMC should trust the mentors to keep things on their current track (hehe) of collaboration-where-possible, rather than turn this into an overheated debate. cheers, Leo On Fri, Dec 30, 2011 at 9:30 PM, Ethan Jucovy <ethan.juc...@gmail.com> 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
