incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jucovy <ethan.juc...@gmail.com>
Subject Re: [VOTE] Bloodhound to join the Incubator
Date Fri, 30 Dec 2011 20:30:45 GMT
-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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message