On 12/31/2011 5:57 PM, Ethan Jucovy wrote:
> Hi,
>
> On the Apache Incubator list I was advised:
>
> "At this point, I would recommend that you hold a vote on the
> appropriate Trac mailing list regarding approving or disapproving a
> fork and then forwarding that here. If the existing community
> doesn't want a fork I would suspect the incubator PMC would require
> the bloodhound project not to start from one."
As apparently now some independent Apache people are monitoring this
thread, let me try to make a summary for them (some original bits here
but I've already tried to explain the situation as I saw it elsewhere
in the previous thread, sorry for the possible repetition).
The Trac developers were approached privately last year in April, by
WANdisco. They told us that they wanted to build a "leading
open-source bug-tracker" and that they wanted to base their efforts on
Trac. We were asked for information about the project and some
guidance about how they could make it happen. So far, so great, but
for various reasons, they were insisting to get the project moved to
the ASF, though not completely ruling out other ways of
cooperation. We were reluctant to make such a far-reaching move only
for the sake of satisfying the requirements of a company with no prior
involvement with the Trac development community and which was simply
betting on some future developments of Trac. We hoped they would be
successful, of course, like anyone who find some value in our free BSD
work, but we also knew that companies can have volatile agendas and we
witnessed in the past other companies having tried to leverage Trac
and failed ([1], [2]).
That seemed a bit like a stalemate, us wanting to see if we could work
together, them wanting to move the project to Apache beforehand. In
addition, the time we could allocate on the project was little and
precious so we feared that if they had a few developers working full
time full steam on their version of the project, we couldn't properly
review those contributions in a timely manner and could be a
bottleneck for them in the event they wanted to contribute it back. So
the easiest way forward, as we saw it then, was to suggest a "friendly
fork" in the spirit of forking the code as an externally hosted
development branch. Depending on what we would see there, and how well
we would be able to work with them, we could make an informed
judgement about what to do next to best serve the interests of the
project. Or so was our idea.
That was in May 2011 and we only heard back from WANdisco in December,
still privately, to learn that they settled on directly creating a new
incubator project at the ASF. The rest is public, but most of the
concerns raised since then on this list (risks of community
fragmentation, how could we safely mix BSD and ALv2 code, better make
it all BSD) were already discussed in almost the same terms back in
May.
So let me restate that we were not (and still are not) hostile to
WANdisco in any way, and hope we can eventually find a working
together beneficial to both parties, but the fact remains that at this
stage there remain several uncertainties that will only dissipate when
the *actual* attempt to work together begins (or not).
For example, it has nowhere been said by WANdisco (err, Apache now)
what kind of collaboration they intend to have with the existing Trac
community. Will that be some friendly exchange of fixes and patches
and improvements (all eventual licensing issues being cleared), with a
shared concerns on making life for plugins authors the easiest
possible, compatibility-wise? Or will it be more like "thanks for the
initial code base, now it's ASF business; if you're interested, come
by us"? Unfortunately, it seems to be more like the latter attitude,
and I can understand the reactions of the community seeing this.
> Therefore I would like to hold a vote to collect opinions on the
> question of forking Trac into an Apache Foundation Subversion
> repository, with the new code to be added under an Apache license.
I hope the explanations above show that the problem is not that much
about the fork of the code (which we indeed suggested, for the reasons
explained above) than about the fork of the community. Some
clarifications on the collaboration intents from the Bloodhound people
would be welcome. Well, they already stated that the Bloodhound
project will not be detrimental to Trac, and that there could be
synergies, but several people here (osimons, Ethan, Dirk, even me) had
some valid questions about how this would work in practice, notably
for the plugins and the compatibility guidelines, and the licensing
issues in case of a fork of the core.
> The purpose of this vote is to collect Trac community sentiments
> about a fork, and about whether we would like the Apache-licensed
> Bloodhound project to start from a fork of Trac.
> The alternative would be for the Apache-licensed Bloodhound project
> to start with a dependency on the Trac core, and to consist of
> Apache-licensed plugins and/or installers.
Well, I don't think that's a possible alternative if they are serious
about some of the more ambitious goals stated by Bloodhound (like
multiproject support) which could probably only be achieved properly
by making changes to the core. But if as a first step they choose to
keep Trac core itself as an external dependency and engage in the
community by producing some Apache hosted plugin code on their own and
send patches for Trac core as needed, that would probably be a
smoother way to get things started and for people to get to know each
other.
Even if they fork, I think we could incorporate the Apache Bloodhound
code back in Trac under the BSD license if we wished so (I still hope
that my interpretation is the correct one, as the ALv2 is not a
copyleft license and the license FAQ explicitly states "You may
distribute the result [i.e. modified code] under a different license"
[3]). Both Ian Wild (WANdisco) and Greg Stein (Apache VP) are also
supportive of this ("the bottom line is that it is possible for Trac
to keep distributing under a BSD license while incorporating Apache
licensed code" [4]). There are indeed some real concerns about how
this could work in practice, which are probably better addressed in
the other thread, where I will follow-up later with another mail.
But the license is only a technical detail (albeit an important
one). The other questions are, will we find the changes they make
relevant? Will we want to share code this way? Do they also intend to
take the new changes coming from us? Will this be practical on the
long term? It all depends on the code and how people on both sides
want and manage to interact. In a few months, I guess we'll have a
better picture, the code base could have diverged wildly or have been
enriched a lot with Trac and Bloodhound developers working happily
together to the point the community will actually *want* to switch to
Apache, or there can be any other outcome (like no changes affecting
Trac core) and all this discussion will probably be seen as wasted
time ;-) At this point, it's just guessing.
> Please vote +1 (in favor of fork), -1 (against a fork) , +0 (no
> strong opinion but would rather see a fork) or -0 (no strong opinion
> but would rather not see a fork) if you are interested. I will
> reference the results of this thread in an email to the Apache
> Incubator list.
Please, let's drop this "vote". We initially suggested the fork as a
way for them to be able to show us more "meat" so we're not in a
position now to say "no, don't fork", even if there's still no meat
and they even moved one step ahead by starting the Apache incubation
directly. Realize they have their own constraints, habits, and right
to do what they want with the code.
You may translate that to a +0 if you wish so, but reducing a complex
argument down to a [+-][01] is also something I don't like that much
in the Apache ways ;-) Maybe I got too many -1s ;-). That's why I also
don't want to see as a result of this vote their incubation to be
derailed: let them try what works best for them... So it could also be
a "+1 (binding)" if that would help to let them continue, I wouldn't
want to see us being perceived as over-protective with our code (or
else we should have stayed with the GPL).
-- Christian
[1] Optaros' http://code.optaros.com/trac/oforge/wiki/AboutOForge
[2] ActiveState's FireFly
http://www.activestate.com/press-releases/activestate-introduces-firefly-new-hosted-project-management-and-
[3] http://www.apache.org/foundation/license-faq.html#Distribute-changes
[4] http://groups.google.com/group/trac-dev/msg/966edd19924ea052
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
