Agreed: we don't (and shouldn't) encourage hostile forks at the ASF. This isn't a hostile fork.
>From the beginning, the intention of Bloodhound has been to be to use the existing Trac system as much as possible and to improve upon it. After many private (and some public) conversations with several of the Trac principals, it was agreed that the existing community had a different set of goals than the Bloodhound supporters, and that a separate community and derivative codebase was probably in the best interests of all. The Incubator proposal was publicized and discussed on trac-dev *simultaneously* with the discussion on general@incubator, and the reception was generally indifferent (as Greg mentioned earlier)[1]. While I don't discount Ethan's feelings out-of-hand, it certainly is a bit late in the game to be re-raising these issues. Basically, I just don't understanding the concerns that a very vocal minority appear to have. Is it a problem with the license? Fracturing of the community? Technical issues? Or just "don't take my code"? As for discussion about the technical and other project direction, I'd encourage interested parties to bring up their concerns and suggestions on bloodhound-...@incubator.apache.org. (Note: that list is only a few days old, so it may take a little while for folks to get subscribed.) Since one of the main goals of Bloodhound (and the Incubator) is building community, and we should try as hard as possible to get Bloodhound-related discussion on the bloodhound-dev@ list. All that being said, if people are looking for any kind of closure on this issue, they will probably have to wait a bit. The next few days are holidays for a large part of the world, so any discussion will likely attract a very vocal minority, biasing the resulting discussion. -Hyrum [1] It interesting to note that the single thread on trac-dev discussing Bloodhound has more posts than all other threads to trac-dev during the last three months *combined*. On Sat, Dec 31, 2011 at 9:57 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > 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 > -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
