incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [VOTE] Bloodhound to join the Incubator
Date Sat, 31 Dec 2011 15:57:04 GMT
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.


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]
> [2]
> [3]
> [4]
> [5]
> [6]
> [7]
> [8]
> [9]
> [10]
> [11]
> [12]
> [13]
> [14]
> [15]
> [16]
> [17]
> [18]
> [19]
> [20]<>
> [21]
> [22]
> [23]
> [24]
> [25]
> [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
> [27] "We'll be working closely with some of the plugin developers."  From
> [28]
> [29]
> [30]
> [31]
> for
> the complete thread.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message