-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.
