VOTE: Apache-licensed Trac fork (was: New Trac based project)

[Ethan Jucovy]

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

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.

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.

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.

Thanks,

Ethan

[Dirk Stöcker]

On Sat, 31 Dec 2011, Ethan Jucovy wrote:

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

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

-1 (against a fork)

But the trac core based plugin/installer development variant sounds very
positive to me and with close cooperation core patches can produce
necessary interfaces when required.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

[Hyrum K Wright]

On Sat, Dec 31, 2011 at 10:57 AM, Ethan Jucovy <ethan....@gmail.com> 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."
>
> 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.

For those unfamiliar, where are the guidelines for how this vote
progresses? Who is entitled to vote? How long will the vote be open?
What actions will be taken based upon the outcome?

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

This is a false dichotomy: there are many more options than "fork or
no fork". Limiting options in this context artificially limits the
discussion.

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

The Bloodhound project has *always* been envisioned as being a
derivative of Trac, not a fork of it. Just because any new bits may
be added under the Apache License does not change this fact.

One more thing: many projects use github, and there are even mirrors
on github for Trac and its dependencies. Do you require a similar
vote every time somebody presses the "fork" button on github? How is
this instance different?

-Hyrum

[Olemis Lang]

On Mon, Jan 2, 2012 at 9:56 AM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
> On Sat, Dec 31, 2011 at 10:57 AM, Ethan Jucovy <ethan....@gmail.com> wrote:
>> Hi,
>>

:)

[...]

>
> One more thing: many projects use github, and there are even mirrors
> on github for Trac and its dependencies.  Do you require a similar
> vote every time somebody presses the "fork" button on github?  How is
> this instance different?
>

I mentioned something like this in main thread @ trac-dev . After
reading a bit more it seems to me that there's a difference (in
contrast to my initial view, similar to yours) . Mainly related to
interactions between ALv2 & BSD when (pushing | pulling) (code |
patches) back and forth . What happens (maybe extremely simplified ,
but I hope you get the idea ;) in Github, Bitbucket , ... is

1- Initial User1 "owns" project repository (Repos1)
2- User2 creates a fork (Repos2) , which is allowed by most (all?)
open-source license
3- User2 modifies code and commits changes in Repos2, which is allowed
by most (all?) open-source license
4- User2 sends a pull request so as to incorporate "his"
modifications, by doing so generally this implies that User1 agrees to
distribute those changes under the same terms (license) of code in
original Repos1 ... if not explicitly, that decision is implicit
AFAICS
5- Let's suppose User1 reviews changes and accepts to merge these with
existing code base ... there's no problem considering (4)

Let's suppose Repos1 = Trac-dev's and Repos2 = Bloodhound's , fact is
that in this case the fomer is BSD whereas the later will be ALv2
(different to 4 above) and it seems there are unhappy interactions in
this case (mentioned in main thread , no need to repeat them here ;)

--
Regards,

Olemis

Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@olemislc)
Blog ES => http://simelo-es.blogspot.com
Blog EN => http://simelo-en.blogspot.com
Quora => http://www.quora.com/olemis
Youtube => http://youtube.com/user/greatsoftw

Get a signature like this. CLICK HERE.

[Ethan Jucovy]

On Mon, Jan 2, 2012 at 9:56 AM, Hyrum K Wright <hy...@hyrumwright.org> wrote:

For those unfamiliar, where are the guidelines for how this vote

progresses?  Who is entitled to vote?  How long will the vote be open?
 What actions will be taken based upon the outcome?

The purpose of this vote is to provide a record of community sentiment about forking the Trac core codebase into an Apache-licensed Incubator project, as requested on the Apache Incubator list.  Holding a vote gives the Apache community unambiguous binary statements so that they do not need to subjectively interpret our sentiments based on the opinions we've expressed.

The only followup action I intend to take is to email the Apache Incubator list with a reference to this thread.  Possibly "Straw Poll" would be a better label than "Vote."

I don't know of any established procedures in the Trac community for holding such a vote.  Since the only purpose of the vote is to provide unambiguous records to be communicated to another community, formal procedures seem artificial anyway.  Anyone at all is welcome to vote.  I don't see any need to "close" the vote either -- after all the only relevant timelines are in the Apache community.

 

This is a false dichotomy: there are many more options than "fork or

no fork".  Limiting options in this context artificially limits the
discussion.

In the narrow context of this vote -- an Apache community member requesting that "you hold a vote on the appropriate Trac mailing list regarding approving or disapproving a fork" -- the broader range of options is not relevant.

 

The Bloodhound project has *always* been envisioned as being a

derivative of Trac, not a fork of it.  Just because any new bits may
be added under the Apache License does not change this fact.

One more thing: many projects use github, and there are even mirrors
on github for Trac and its dependencies.  Do you require a similar
vote every time somebody presses the "fork" button on github?  How is
this instance different?

Again, these are not relevant to the narrow context of this vote.  Let's please keep the broader discussion on the other, non-VOTE thread (http://groups.google.com/group/trac-dev/browse_thread/thread/14268355c6e1d494) rather than bringing it here also.

-Ethan

[osimons]

This is obviously not a proper vote - it is more a poll to summarize
sentiments of the Trac development community. In that spirit, here is
what I think of the fork-to-Apache issue:

-0

As mentioned before, I wish that this process had been very different.
But as David Richards of WANdisco said in the previous Trac &
Bloodhound thread: "...we decided that our contribution should be as
part of a larger, independent entity." [1] Despite their best efforts
to herald their arrival as the white knights coming to save the Trac
community, I think that every decision they made so far have the
opposite effect. The fact that the Trac community can't even directly
reuse their future (potential) source code changes due to licensing
issues just feels like an insult.

All in all, I am surprised that they already managed to get the Apache
stamp of approval to "re-build the [Trac] developer community" [2].
When I was still waiting for them to articulate a plan for the
improved software (or even start to deliver code), they plowed ahead
and got their merit badges. It obviously changes Trac community
dynamics.

That said, I'm "-0" as I don't feel it is right to "-1" this. Trac is
BSD-licensed and it is everyones right to fork Trac if they really
want to. I think it is a shame that it forks in this way and not as a
regular git/hg project fork, but as an open source developer I will
never disapprove of others exercising rights that I have granted them.
Even forking the community is perfectly valid as there are no
particular strings tying any of us here. It is their right to fork,
and I don't have to like it.


:::simon

http://trac-hacks.org/wiki/osimons
https://www.coderesort.com

[1] http://groups.google.com/group/trac-dev/msg/5bc628afdd5a4ff3
[2] http://wiki.apache.org/incubator/BloodhoundProposal

[Benjamin Lau]

I'm also a -0.  I think osimons articulated my feeling better than I could.

Ben

--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac...@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.

[Christian Boos]

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

[Remy Blank]

Christian Boos wrote:
> 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.

FWIW, I agree with all that Christian wrote, and especially this paragraph.

-- Remy

[k0s]

-1, with TL;DR below

I feel straw poll is a more accurate and beneficial way of looking at
this, since the call for a vote is really a request on behalf of the
thread "Re: [VOTE] Bloodhound to join the Incubator" [1] so ultimately any
Trac dev and community participation should come under its own
governance as to whether the call to vote is at all the thing to do in
such an occassion or overall how to respond to the Bloodhound fork
proposal, and in fact, the governance of Trac and correspondence with
third parties us up to the Trac stakeholders.  As osimons points out
[2] (my interpretation), the professed logic of David Richards
regarding "...we decided that our contribution should be as
part of a larger, independent entity." is, at best, both a
questionable assumption and one that has been followed by questionable
actions and has no way illustrated that this course is best for any
community or for software in general.  On the other hand, I find the
logic of "Trac is BSD-licensed and it is everyones right to fork Trac
if they really want to." to be largely inapplicable.  Of course
everyone has the right to fork FOSS, but that doesn't mean that they
should.  Since the vote was solicited on whether they should, this is
what my vote is respect to.

That said, I cannot in good faith say that I am still a member of the
Trac community so anything I say is from the perspective of a guy that
did a lot of plugins work a few years ago [3] that now works for
Mozilla and does not work on or maintain Trac in any meaningful way.
I care about the project, in the abstract, though to be honest Trac
suffers from many of the symptoms that make it hard to get involved in
any OSS community.  Mozilla does too.  I care a lot about open source
software and generally associate forking without the intention to
upstream (which, as best I can tell, cboos interprets correctly in
https://groups.google.com/d/msg/trac-dev/kMVFq9pkfus/eYMCVfqyUwkJ ) as
real failures in the OSS ecosystem and that I fear leads to corporate
and other moneyed stakeholder control of "open" source software.  That
is what I fear here.

Though, to be honest, I don't fear it much.  I don't forsee a long
term success for the bloodhound project without interest and
collaboration with Trac developers.  There will be some initial
interest, maybe even some tech press, but long term viability?  I
honestly doubt the project has enough commitment to maintain an
issue tracker (and all the other things Trac does) to really get (pun
not intended) traction. If they did, they wouldn't start the
conversation with a fork.  For one that is just rude.  For another,
since OSS is ultimately about cultivating ecosystems, it is a serious
blow to that.

Does .* have the right to fork Trac?  Yes [4].  But I would prefer if
they didn't.

----

[1] http://mail-archives.apache.org/mod_mbox/incubator-general/201112.mbox/%3CCAJjMeYNPPVT4sBOUo3VcUq8c=d1aP5hurWP+w...@mail.gmail.com%3E

[2] https://groups.google.com/d/msg/trac-dev/kMVFq9pkfus/Xa5ivikBAF0J

[3] http://trac-hacks.org/wiki/k0s

[4] Within legal limits

[Dirk Stöcker]

On Mon, 2 Jan 2012, Christian Boos wrote:

> 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 still have the right. I doubt you have been aware (or even are now, or
ever :-) of all the implications and it is not forbidden to change the own
opinion.

The main argument about fork or not seems to be the argument whether Trac
core is capable to be the base of an improved project. WANdisco claimed
no. I would say: Better try and only if it really does not work do the
fork later. It is VERY complicated to undo it.

They have the right to do so and they don't need to ask, but this does not
mean they really need to go that way. The question here is if TRAC
DEVELOPERS want that fork or not.

Forking a project always consumes a lot of additional manpower which
better could be spend on improving a living project (like Trac is).

[Leo Simons]

On Monday, January 2, 2012 9:56:33 PM UTC+1, Christian Boos wrote:

As apparently now some independent Apache people are monitoring this

thread, let me try to make a summary for them.

/me *waves*. Thanks for that Christian.

I used to be an active trac user and I still have warm fuzzy feelings about that, so I'd feel very bad if Apache somehow was involved in doing Bad Things(tm) to Trac! I was pretty concerned for a bit, but it looks like everyone involved is trying to stick to doing just Good Things(tm) though, so as long as that stays the case I'm actually pretty confident things'll work out well.

I'll stay subscribed here while bloodhound is incubating, so I can perhaps help nothing horrible happens. Not that it will, but hey. Peace of mind. Rest assured it's all very selfish: like many I do have a keen interest in something open source with some more of jira's enterpricy features, a somewhat more boring legal status, and none of jira's, err, jira-ness :-)

cheerio,

Leo