Discussion: The future of the Vert.x project

[Tim Fox]

As promised, let's discuss the options for the long term future of the project.

I'll make an assumption that, until we come to a conclusion, VMware won't make any further unilateral changes to the way the project is administered or attempt to influence the decision in non public ways. If my assumption doesn't prove to be correct, all bets are off.

So, what are the options:

1) "Netty-style solution". In this solution almost everything continues as-is. The only difference is a CLA is crafted that grants rights of the contributions not to RHT or VMW, but to the "Project". This would require VMWare to grant a perpetual license to the "Project" for use of the name Vert.x.

2) Fork. We wouldn't have permission to use the name 'Vert.x' so we'd have to rename the project. That means removing all references to 'Vert.x' from the code, documentation, and other materials. We'd also lose the current github issues, the wiki, the blog, Google Group and domain. This would not require any permission from VMware.

3) Move project to Apache Software Foundation. This would need approval from ASF and VMware.

4) Move project to the Eclipse Foundation. This would need approval from the Eclipse Foundation and VMware.

Here is my personal opinion (as it currently stands) on the options:

My preferred option is 1) This has the least disruption to the project of all the options, but it requires VMW to grant a license. I proposed this before and it was refused. I would like to ask VMware to reconsider this. It would be by far the easier way to resolve this crisis. There is a very clear precedent for this succeeding in the real world. However, if VMware confirms that this is not an option, then we can remove it from the table.

Let me say a few words about moving to ASF or Eclipse: I don't know much about the fine details of the processes (I will learn more), but, aiui, they both follow a similar approach. The IP for the project gets signed over or licensed to the neutral entity. Both foundations mandate fairly complex development processes that relies on concensus amongst committers in order for changes to made.

If we went down this path I assume both VMW and RHT would want to have committer representatives on the team. For this setup to work, it requires trust and co-operation between the committers. Without trust the project could easily grind to halt as changes from one committer are vetoed by other committers with conflicting agendas.

The problem right now, is there has been an almost complete breakdown of trust and communication between myself and VMW due the recent actions and subsequent behind the scenes political actions by certain parties.

For me, personally, to seriously consider 3) or 4) as an option then the current poor atmosphere would need to be fixed, or it's simply not going to work...

...and that would leave us with 2) Fork. This is the "Hudson vs Jenkins" option. Forking is a pain since we would lose the name, the github followers, the google group, the wiki and the blog. However I don't think it would be the end of the world. If we go down this route, I suggest that we do make a clean break down by continuing the project in the fork with the 2.0 release of the newly named project.

Comments please.

[Daryl Teo]

Question: isn't RHT kinda left out of this? 

As I remember you mentioning, RHT will be paying you to  work on Vert.x (correct me if I'm wrong please). In that case, what rights would they seek to claim on the forked project if vert.x was, indeed, forked?

Daryl

[Tim Fox]

On 10/01/13 10:11, Daryl Teo wrote:

Question: isn't RHT kinda left out of this? 

As I remember you mentioning, RHT will be paying you to  work on Vert.x (correct me if I'm wrong please). In that case, what rights would they seek to claim on the forked project if vert.x was, indeed, forked?

This is a good point.

I have a pretty standard employment contract which means my code contributions and other "inventions" would be owned by RHT, but this is probably no different to most committers on the project (their contribs are owned by their employers).

I would need to clarify with RHT whether they would assert rights to the <new_name_of_vertx>, and what sort of CLA would be used in this case.

--
 
 

[Oliver Rolle]

I agree with Tim and trust him, that he will negotiate a good deal for the community. I like the idea of a fork, bc we could do this independently from other parties and vert.x 2.0 provides a clear cut. The loose of the name is serious, but the project is young and a re-branding is not too risky.

[Tim Fox]

We could mitigate against this by making sure we had multiple committers
from all parts of the community, not just RHT and VMW.

Excluding my contributions, non VMW contributors have contributed more
than VMW, so this would be fair too.

>
> The problem right now, is there has been an almost complete breakdown
> of trust and communication between myself and VMW due the recent
> actions and subsequent behind the scenes political actions by certain
> parties.
>
> For me, personally, to seriously consider 3) or 4) as an option then
> the current poor atmosphere would need to be fixed, or it's simply not
> going to work...
>
> ...and that would leave us with 2) Fork. This is the "Hudson vs
> Jenkins" option. Forking is a pain since we would lose the name, the
> github followers, the google group, the wiki and the blog. However I
> don't think it would be the end of the world. If we go down this
> route, I suggest that we do make a clean break down by continuing the
> project in the fork with the 2.0 release of the newly named project.
>
> Comments please.
>

> --
>
>

[Brian Lalor]

On Jan 10, 2013, at 4:58 AM, Tim Fox <timv...@gmail.com> wrote:

...and that would leave us with 2) Fork. This is the "Hudson vs Jenkins" option. Forking is a pain since we would lose the name, the github followers, the google group, the wiki and the blog. However I don't think it would be the end of the world. If we go down this route, I suggest that we do make a clean break down by continuing the project in the fork with the 2.0 release of the newly named project.

All of this is a colossal waste of time and good will, so I'm hoping RHT and VMW get their shit together soon.  That out of the way, I think the increased organizational overhead of Eclipse or Apache could cost the project some agility if the team principals have to deal with politics external to the core development of the project.  That's largely up to you Tim, but I could see you chafing at the additional structure, and I really want to see 2.0 build momentum.  I also think it's important that the 1.x branch be maintained.  I haven't looked at issues in a while, but I'd be surprised if there weren't some things that should be addressed while 2.0 is gestating.

Regarding GitHub issues and stars, etc, it should be possible to suck down that information while you still have access through their API.  I don't have experience with the API myself, but I'm guessing you could at least archive the bulk of that for import to a new project, as well as proactively notify those who have starred/watched the project to notify them of the new home.

[Henri Gomez]

3) Move project to Apache Software Foundation. This would need approval from ASF and VMware.

As a long time ASFer and OSS activist, I would recommand this.

Why ?

A project hosted in ASF is protected by the fundation, CLA and CCLA ensure that project will stay a community project, whatever happen to commiters or companies behind it. There is many examples in ASF of projects where leadership fly from one company to another one, and they are still here.

A good example is Apache Tomcat who turned 10y, moved from Sun, to ASF, JBoss and now SpringSource/VMV.
It's still here and very widely used around. 

It's a long time investment guaranty for users and it secure companies who want to use it or invest on it.

Vert.x as a market, great developpers/commiters, a strong community, it's a perfect candidate for ASF project.

[Andy Piper]

Something we should consider is that several folks have mentioned that they are building solutions and businesses on top of vert.x - which is fantastic - and that leads me to ask two important questions about governance and IP review / cleanliness of contributions.

I'm not sufficiently familiar with the "Netty-style solution" to know what guarantees exist there. Wouldn't the "Project" then need to deal with these things somehow independently?

Setting aside the fork option, as it also doesn't address those questions, and also in my view would be a shame... that leaves a Foundation-based solution.

It's no secret that I'm an Eclipse committer, and I'm slightly biased in that direction mostly because I'm familiar with it. 

In fact I found myself in a similar (but far from identical) situation a year ago when I left IBM but wanted to continue to contribute and lead the community for what was otherwise a somewhat IBM-heavy project, which has since diversified. I've been able to do that without significant issues or loss of "agility". Organisations generally like to consume and re-use Eclipse code, there's a good IP and governance process in place.

That said I've also worked with Apache (in fact I became friends with Pid through that community) and know that it's good some good structures in place as well.

So, +1 for moving to a Foundation, to enable continued independence, with governance and IP review to assure folks that the project isn't going away, and that the code has been well-reviewed.

Andy

[Pid]

My personal opinion is that 3 & 4 would offer the community:

a) continuation of service
b) implied support from the main companies involved
c) continued use of the name & associated goodwill
d) support from a foundation
e) technical resources
g) more exposure and a chance to grow the community


I do not believe that there is any need to rush into a decision, because
to all intents and purposes this project can continue where it is while
we talk it through.

I agree that more committers would be great for the project!


p



--

[key:62590808]

[Tim Fox]

Aren't the above also provided by solution 1) ?

> d) support from a foundation
> e) technical resources
> g) more exposure and a chance to grow the community
>
>
> I do not believe that there is any need to rush into a decision, because
> to all intents and purposes this project can continue where it is while
> we talk it through.

We need to make a decision quickly.

I, for one am not willing to work under the current arrangement for any
longer than is necessary. It provides too much uncertainty for users,
and it adversely affects productivity (For example - I have done very
little _real_ work this week).

[Tim Fox]

On Thursday, 10 January 2013 11:18:04 UTC, Andy Piper wrote:

Something we should consider is that several folks have mentioned that they are building solutions and businesses on top of vert.x - which is fantastic - and that leads me to ask two important questions about governance and IP review / cleanliness of contributions.

I'm not sufficiently familiar with the "Netty-style solution" to know what guarantees exist there. Wouldn't the "Project" then need to deal with these things somehow independently?

Take a look at the Netty CLA:

https://docs.google.com/spreadsheet/viewform?formkey=dHBjc1YzdWhsZERUQnhlSklsbG1KT1E6MQ

As you can see grant of copyright license is made to the "Project" not to RHT, Twitter or <some_other_company>

I guess you can think of this is a "lightweight neutral organisation". I won't pretend to understand all the details and ramifications since ianal.

[Andy Piper]

Ah... dug into this some more... it seems that Netty also used a Foundation.  I am not sure what the pros and cons of this are, but would love to hear an expert view.

See: https://groups.google.com/forum/?fromgroups=#!msg/netty/_51wiU0niUE/QQnMd1TtvYIJ

and http://sfconservancy.org/

Also referring to the useful info from Eclipse that Mark posted on the original announcement thread, there are a whole lot of benefits to going with Eclipse or ASF. Again I think from the perspective of those building on top of or using vert.x commercially, the governance and IP assurances are likely to be most valuable.

Andy

[Henri Gomez]

Netty didn't seems to be in current sfconservancy yet :

http://sfconservancy.org/members/current/

2013/1/10 Andy Piper <andyp...@gmail.com>

--
 
 

[Mark Little]

I have asked Mike from the Eclipse Foundation to join the group. I believe another Eclipse representative will also be joining.

Mark.

[Nate McCall]

In all but the fork option (which should be last resort only) you will
need a foundation of some sort as a neutral 3rd party to hold the
copyright and provide some legal protection. Otherwise you would be
asking VMWare has to hand over to copyright arbitrarily.

The ASF process is not heavy weight on a day to day. Lot's of popular
projects (with competing corporate interests behind them even) get a
lot of work done. Further, please note that an offer of assistance was
made on the previous thread from the current ASF president - Jim
Jagielski. I just wanted to make sure that wasn't lost in the noise.

Looks like incubation sponsorship would be straightforward :)

[Bob McWhirter]

Tim speaks for Red Hat on this subject.

I've discussed each of these options with Tim, and whichever one the community decides to go with, we are happy to support.

In the event of a fork without a foundation, then work produced by Tim would be owned by Red Hat, but licensed under ASL2, as many of our projects work.  If the project (or a fork) goes to another party (ASF, Eclipse, Fedora, whatever) which would hold IP, they would own his work.  Red Hat has a very liberal policy regarding work-for-hire, and our employee handbook explicitly states that we may work on open-source, during work hours, on projects not owned by Red Hat.  We understand how open-source works.

No matter the outcome, we consider it Tim's job to lead and innovate in the project, whatever its name, where-ever it lands. While ownership interests are important, our highest priority is that Tim have the ability to lead and create awesome code.

Bob McWhirter

[Mike Milinkovich]

I'm here! My day is just starting in Ottawa....I will read the thread and answer where I can.

[Alexis Richardson]

I would love to understand why Trustin and RH chose the SFC route.  It seems to have taken a long time.

[Mark Little]

We didn't choose the SFC route. That came after Trustin left with the Netty project.

Mark.

--
 
 

[Alexis Richardson]

On Thursday, January 10, 2013 1:50:58 PM UTC, Mark Little wrote:

We didn't choose the SFC route. That came after Trustin left with the Netty project.

In that case, I am curious why he chose it :-)

[Mike Milinkovich]

Tim,

I understand your point of view and preferences. I am here to try to help explain how Eclipse works. I hope you find it useful.

There are a few misconceptions about Eclipse below that I will try to address. Eclipse and Apache have a lot in common, in that we uphold the core values of openness, transparency and meritocracy. However, there are important differences between the two cultures that a lot of people don't realize.

On Thursday, January 10, 2013 4:58:38 AM UTC-5, Tim Fox wrote:

The IP for the project gets signed over or licensed to the neutral entity.

That's not entirely correct at Eclipse. The project names (e.g. trademarks) for Eclipse projects have to be assigned to Eclipse. But the ownership of the copyrights and patents don't come to Eclipse. We also do not require CLAs at Eclipse. So unlike a lot of organizations, we don't aggregate all of the IP at the Foundation.We rely on symmetrical inbound and outbound licensing.

Both foundations mandate fairly complex development processes that relies on consensus amongst committers in order for changes to made. 

"Fairly complex" is fair comment. But the Eclipse process does not require consensus for commits. People who have commit status can commit code. Of course if they screw something up, they hear about it :).  Eclipse projects also actually have clear project leaders who are expected to run the project. Our Project Management Committees (PMCs) are also quite small and well-defined groups. 

In other words, our development process is calibrated to be in the middle of the "benevolent dictator" model and the "everything is a consensus" model.

 

If we went down this path I assume both VMW and RHT would want to have committer representatives on the team. For this setup to work, it requires trust and co-operation between the committers. Without trust the project could easily grind to halt as changes from one committer are vetoed by other committers with conflicting agendas.

The initial project leader and list of committers for Eclipse projects are defined in the project proposal. Unlike Apache, existing members of the Eclipse community do *not* get to join the project at startup. A new project does need to find two mentors from the Architecture Council to assist them in learning and navigating the Eclipse processes. Mentors do not get commit rights.

Once a project is established, the only way in is via meritocracy. E.g. a contributor who wants to become a committer has to demonstrate a history of contribution, be nominated by an existing committer, and be voted in by the existing committers on the project. And as I said above, committers at Eclipse don't get to veto other committers changes. The project leader can kick some butt if necessary, but it happens exceedingly rarely.

 

For me, personally, to seriously consider 3) or 4) as an option then the current poor atmosphere would need to be fixed, or it's simply not going to work...

Amen to that. Trust is the bedrock of any community.

[Alexis Richardson]

Mike

Thanks for posting this.  What do you mean by "We rely on symmetrical inbound and outbound licensing."?

Also -- I'd heard that ESF used to require the EPL but it's now ok to use an Apache license.  Is that correct?

alexis

[Mike Milinkovich]

On Thursday, January 10, 2013 9:07:13 AM UTC-5, Alexis Richardson wrote:

Thanks for posting this.  What do you mean by "We rely on symmetrical inbound and outbound licensing."?

We don't use CLAs. A lot of organization do rely on CLAs. To the degree where some think that it is an inherent part of open source. CLAs are used to aggregate copyrights (either ownership or a license equivalent to ownership) in a single organization. That organization can be non-project (e.g. FSF, ASF), or for-profit (e.g. Oracle, Canonical). By acquiring all of this IP, the central organization retains the ability to re-license, or alternatively license the contributions in the future.

At Eclipse, all of the contributions come in under the license of the project and are licensed out under that same license. That's what I meant by "symmetrical". Other than the trademark, the Eclipse Foundation does not acquire any IP interest in its projects. This means that we could not re-license an Eclipse project without the express permission of every single contributor. We went through this exercise in 2005 when the Eclipse community re-licensed from the Common Public License (CPL) to the EPL. It was horrendous.

Also -- I'd heard that ESF used to require the EPL but it's now ok to use an Apache license.  Is that correct?

It requires the approval of the Eclipse Board of Directors, but yes.

We do have a modest preference for an ALv2+EPL dual-license scenario - which is what Jetty has - but an ALv2-only license scenario is definitely possible.

 

[Mark Little]

I can ask him.

Mark.

--
 
 

[이희승 (Trustin Lee)]

Mark is correct.  I wanted to keep the project neutral.  However, in Korea, it is pretty difficult for an individual to found a non-profit.  Therefore, I applied for SFC membership because SFC takes care of legal and financial issues and let me focus on development.  Unfortunately, it took eternity to get approval - I actually didn't get any response for the application.

Meanwhile, we assigned the copyright to the 'Project'.  I'm not really sure about the legal ramifications, and I still wish there's a foundation similar to SFC which protects Netty.

Hope that explains,
T

--
 
 

--
https://twitter.com/trustin
https://twitter.com/trustin_ko
https://twitter.com/netty_project

[Mark Little]

Thanks Trustin. Now you can ignore the email from me ;-)

Mark.

--
 
 

[Alexis Richardson]

Many thanks Trustin.

I agree with you that a foundation is a good thing.  It certainly clarifies the legal ramifications both current and 'in the future'.

alexis

[Guillaume Laforge]

Hi Trustin,

On Thu, Jan 10, 2013 at 3:26 PM, 이희승 (Trustin Lee) <tru...@gmail.com> wrote:

[...]

Meanwhile, we assigned the copyright to the 'Project'. 

 

What I don't understand with the 'Project' is that it's no legal body?

It's not a human, not a non-profit, nor any kind of liable organization?

It sounds like something not very legal :-(

[...]

--
Guillaume Laforge
Groovy Project Manager
SpringSource, a division of VMware

Blog: http://glaforge.appspot.com/

Social: @glaforge / Google+

[Alexis Richardson]

That's all pretty cool, and would likely work from our point of view.  I'll our ask folks to get back to me with an official view.

In passing, let me mention that VMware is involved in many open source projects and foundations.  Sometimes as owner & custodian, sometimes as sponsor, sometimes as a member.  Over time, I personally have found that there is no one 'best' model or even license.

[Norman Maurer]

If you choose the ASF then there is no Project Lead. There is "only" the PMC which is responsible to for the Project. In fact all committers are responsible but only votes (releases get voted) are binding from PMC Members.  To be clear I not say the ASF is a bad place for vert.x. I just want to share that there is no "Project Lead" like position at the ASF. Even if you want to call the "most active committer" a "Project Lead", he has no more power then anyone else on the PMC.

Cheers,

Norman