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

[Norman Maurer]

Yeah something like the SFC would be nice for Netty, but so far everything worked out like it is for us. 

Bye,

Norman

[Mike Milinkovich]

There is one point that I would like to make which is independent of any particular process or foundation. That is, I would like to address the issue of why foundations are useful at all.

Github rocks. I totally get it. For the people working on a project, it is just about perfect. It is a great environment for people to collaborate on a codebase and Get Shit Done. At Eclipse we aspire to hosting a really good forge and community, but we're not under the illusion that we compete with github's greatness.

But foundations are not just for the people producing the code. They exist to balance the interests of the producers of that code, and the consumers who want to adopt it in their products or enterprises. All of the processes that you see at organizations like Eclipse and Apache exist to balance those interests. One of those interests that is particularly vital is vendor neutrality. In this day and age, if you want your project to aspire to becoming an industry platform, you need to demonstrate your project's independence from vendor control, and openness to outside contribution. Other key interests include IP management, project longevity, and the like. Organizations like Eclipse and Apache exist to ensure that their projects meet those criteria.

There are certainly counter-examples (Spring comes to mind), but in general hosting a project at a foundation makes it more likely that your code will reach its maximum mainstream adoption.

Disclaimer: I run a foundation, so obviously I'm biased :)

[Alexis Richardson]

I like that Eclipse has "clear project leaders" to quote from Mike's post.

[Douglas Campos]

Mike, this venting from jgit/egit[1] was the first thing that came to mind - I know the post is two years old, this still holds true?

Another question, at Eclipse Foundation, is it impossible to continue using github workflows / hosting? so all contributions should go via gerrit, etc?


[1]:http://blog.spearce.org/2010/02/tragedy-of-eclipseorg.html

> --
>
>

[Mike Milinkovich]

I was wondering when someone would point to that :)

In general, the processes being complained about in that post remain in effect. We've streamlined and simplified many of them, but I am not going to claim that Eclipse is process-free. IP conversations remain closed to committer-only, rather than public. That's because we sometimes talk about issues with code (ours and others) which could have legal ramifications. I honestly never understood why the conversation about the fileheaders and licensing wasn't done on the project mailing list. There was no reason not to. We just screwed up.

However, in more recent news, EGit and JGit have become very successful projects, Shawn Pearce is now on the Board of the Eclipse Foundation, and Google recently joined as a Strategic Member. So that post was a clear documentation of some screw-ups on our part, and some honest frustrations on Shawn's part, but it has all worked out very well in the end.

[Mike Milinkovich]

On Thursday, January 10, 2013 10:00:54 AM UTC-5, Douglas Campos (qmx) wrote:

Another question, at Eclipse Foundation, is it impossible to continue using github workflows / hosting? so all contributions should go via gerrit, etc?

The project has to be hosted on eclipse.org infrastructure. Eclipse projects can mirror to github. The good news is that we do support git and gerrit for all projects. We also provide a common build infrastructure so projects can build at Eclipse if they want to.

There are a couple of reasons why projects need to be hosted at eclipse.org. 

. Vendor neutrality: hosting projects at any particular vendor implies a level of endorsement.

. IP flow and management: github in particular does a very poor job with its license management and its terms of use. To provide proper IP management at github requires a lot of extra work around manual CLAs and the like that we just take care of at Eclipse. 

. Independence: There have been examples in the past of project hosting services that changed their business models in ways which were detrimental to the project communities hosted there. 

[bytor99999]

OK, what about option 5, which wasn't posted by Tim, because he already stated it isn't his preference, but it is still an option.

But why change anything now. vert.x website, project et al belongs to VMWare. However, I believe except for ownership of say the github repository. Tim can still do everything he did before without change. So we can keep the status quo, keep the project on github. Keep contributing without the disruption of a fork, Apache, or Eclipse.

I am now totally against a fork. If it forks, then vert.x can't be an option for our app, too much uncertainty and risk. We are a Vegas gaming company and we gamble, but not that type of gamble.

I am disappointed in both sides VMWare and Red Hat.

Mark

[Andy Piper]

On Thursday, 10 January 2013 15:00:54 UTC, Douglas Campos (qmx) wrote:

Another question, at Eclipse Foundation, is it impossible to continue using github workflows / hosting? so all contributions should go via gerrit, etc?

AIUI your project gets automatically mirrored from Eclipse Git's repo to Github, which is handy for discovery purposes. The commit flows go via Gerrit and Git on Eclipse though - and via an established project Committer, who is responsible for ensuring that any required IP review occurs. 

(this is certainly the case with the project I'm working on, but we are in incubation so I cannot claim in-depth knowledge of everything yet)

Andy

[Mark Little]

My preference is certainly a foundation, and of the ones mentioned so far, Eclipse is my favourite.

Mark.

> --
>
>

[Jim Jagielski]

Tim and community,

I won't try to "sell" you or anyone on the ASF. That's not how we work. I do think that the ASF would be a great home for the project, and it would be joining a large and growing list of ubiquitous FOSS projects, well known and well used in the entire web/cloud/IT community.

The advantages of 3 is that the ASF is truly individual and volunteer focused. It is a safe and neutral location for a project, and allows both volunteers are corporate-sponsored developers to work together, but ensuring that the *community* had control of the project. I also think that such a location would be a "safer" bet for VMware, and they would likely be more willing to have the ASF be the new home.

I would also encourage you and the community to make this decision. It is, or should be, yours to make. Also, make sure it's an *informed* decision, and not one based on FUD and biases, but on facts and on what's best for the project and the community.

[Mark Little]

On 10 Jan 2013, at 15:22, bytor99999 wrote:

> OK, what about option 5, which wasn't posted by Tim, because he already stated it isn't his preference, but it is still an option.
>
> But why change anything now. vert.x website, project et al belongs to VMWare. However, I believe except for ownership of say the github repository. Tim can still do everything he did before without change. So we can keep the status quo, keep the project on github. Keep contributing without the disruption of a fork, Apache, or Eclipse.

That is an option. As mentioned before: all options should be on the table for discussion.

>
> I am now totally against a fork. If it forks, then vert.x can't be an option for our app, too much uncertainty and risk. We are a Vegas gaming company and we gamble, but not that type of gamble.
>
> I am disappointed in both sides VMWare and Red Hat.
>

We are all trying to do the best for the project and the community. Whilst the delay in getting a response from Red Hat and VMWare was longer than anyone wanted, I hope that it showed the best of intentions. Red Hat is fully committed to the success of the vert.x project. Tim and I have known each other personally for over 6 years now, so you should know that there's a level of trust beyond "big company" employment. In general my gauge on whether or not we are doing the right thing on something is the number of complaining emails I get from Tim.

Mark.

[Jim Jagielski]

The ASF would not "own his work". There is no copyright assignment.

On Thursday, January 10, 2013 8:32:38 AM UTC-5, Bob McWhirter wrote:

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

On Thursday, January 10, 2013 5:11:42 AM UTC-5, 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?

Daryl

[Alex Tkachman]

My vote is for ASF

--------
Best regards,
Alex

Best way to call / chat with me http://lucy.me/alex

--

[Tim Fox]

On Thursday, 10 January 2013 15:22:08 UTC, bytor99999 wrote:

OK, what about option 5, which wasn't posted by Tim, because he already stated it isn't his preference, but it is still an option.

But why change anything now. vert.x website, project et al belongs to VMWare. However, I believe except for ownership of say the github repository. Tim can still do everything he did before without change.

(Actually that's not quite true. I can do everyday project type stuff, but I no longer administrate anything)

It's really a question of trust. VMW have shown that they're willing to make unilateral changes to the way the project is administered without consulting the community first.

I dearly hope VMware have learned their lesson, but it introduces risk and uncertainty that I, for one, am not willing to work under for any extended period of time.

 

 

[Tim Fox]

Between a rock and a hard place.

I can certainly see the advantages of a neutral foundation such as ASF/Eclipse - I only wish there was a neutral foundation which didn't impose such an onerous development process.

I've been reading through the Eclipse development process: http://www.eclipse.org/projects/dev_process/development_process_2011.php

It seems really complex. I think I will go insane if I have to follow that. I'd also be worried that the project would screech to a halt. Anyone who knows me knows I am really not a process guy.

ASF - dev process seems a bit simpler, but I have to say, I have never really agreed with the whole "every committer is equal" thing. I think projects need leads.

So... I'm really stuck on this personally :(

[Alexis Richardson]

On Thursday, January 10, 2013 6:37:26 PM UTC, Tim Fox wrote:

On Thursday, 10 January 2013 15:22:08 UTC, bytor99999 wrote:

OK, what about option 5, which wasn't posted by Tim, because he already stated it isn't his preference, but it is still an option.

But why change anything now. vert.x website, project et al belongs to VMWare. However, I believe except for ownership of say the github repository. Tim can still do everything he did before without change.

(Actually that's not quite true. I can do everyday project type stuff, but I no longer administrate anything)

This is the status since Monday pm:

While Tim is no longer a designated owner of the Google Group[1] or GitHub

Organisation[2], he has been assigned the Manager role (with all

permissions enabled) in the Group and to the Admins team (with push, pull

& admin rights) on all of the existing repositories at GitHub.

1 http://support.google.com/a/bin/answer.py?hl=en&answer=167094

2 https://help.github.com/articles/what-are-the-different-access-permissions

alexis

[Mike Milinkovich]

On Thursday, January 10, 2013 1:43:28 PM UTC-5, Tim Fox wrote:

I've been reading through the Eclipse development process: http://www.eclipse.org/projects/dev_process/development_process_2011.php

It seems really complex. I think I will go insane if I have to follow that. I'd also be worried that the project would screech to a halt. Anyone who knows me knows I am really not a process guy.

Like I said, I am not going to claim that Eclipse has no process. However, a couple of things to keep in mind:

- part of the reason that document looks so complex is because our approach is to document everything. We try to make sure that we don't leave anything to folklore.

- there is a bunch of stuff that happens at new project inception which you never have to worry about afterwards.

- there are people to help guide you, including full-time staff

But I certainly understand the rock and a hard place.

[Tim Fox]

On 10/01/13 18:45, Alexis Richardson wrote:

On Thursday, January 10, 2013 6:37:26 PM UTC, Tim Fox wrote:

On Thursday, 10 January 2013 15:22:08 UTC, bytor99999 wrote:

OK, what about option 5, which wasn't posted by Tim, because he already stated it isn't his preference, but it is still an option.

But why change anything now. vert.x website, project et al belongs to VMWare. However, I believe except for ownership of say the github repository. Tim can still do everything he did before without change.

(Actually that's not quite true. I can do everyday project type stuff, but I no longer administrate anything)

This is the status since Monday pm:

While Tim is no longer a designated owner of the Google Group[1] or GitHub

Organisation[2], he has been assigned the Manager role (with all

permissions enabled) in the Group and to the Admins team (with push, pull

& admin rights) on all of the existing repositories at GitHub.

1 http://support.google.com/a/bin/answer.py?hl=en&answer=167094

2 https://help.github.com/articles/what-are-the-different-access-permissions

By administrate i mean *full control* over the project. I no longer have that, and VMware has the ability to revoke those rights at any time. That's the point.

alexis

 

It's really a question of trust. VMW have shown that they're willing to make unilateral changes to the way the project is administered without consulting the community first.

 

I dearly hope VMware have learned their lesson, but it introduces risk and uncertainty that I, for one, am not willing to work under for any extended period of time.

 

 

--
 
 

[Kohsuke Kawaguchi]

Have you looked into http://www.spi-inc.org/ or http://sfconservancy.org/overview/ ?

I was in a similar situation in the past, so I can relate to many of your concerns. FWIW, the path we adopted eventually was SPI. It is a legal entity, and so it can hold assets (trademark, domain names, etc.), it can collect CLAs if you so choose, and it can collect donations on behalf of the project. It does the crux of what you need, a neutral entity to hold the naming right (which I think is at the heart of the issue, really.)

But SPI doesn't require a particular development process. So you can maintain the status quo in that regard. You just nominate the liason from the project to SPI, and in the eyes of SPI that person is the project. This is both a blessing and a curse --- blessing because projects like ours can maintain the way it operates and preserves its culture. But it's a curse because you'd need more governance to protect the community from you. There's no systematic check that prevents you from going rogue. I know some projects where the owner decided to turn the project closed source for profits, and it's not pretty. Not that I'm saying you'd ever do that, but after a fisasco like this one, I think it's fair to the community to make sure that won't happen.

Now that I've gone through the whole thing, I see that if one really takes this to the logical conclusion, you'll go the way toward Apache/Eclipse style mechanisms. But then, one shouldn't have to make the whole leap in one go, right?

So that's just my 2 cents.

[Tim Fox]

Hi Kohsuke,

On Thursday, 10 January 2013 19:09:33 UTC, Kohsuke Kawaguchi wrote:

Have you looked into http://www.spi-inc.org/ or http://sfconservancy.org/overview/ ?

Thanks for the link. I haven't heard of spi before. 

I was in a similar situation in the past, so I can relate to many of your concerns. FWIW, the path we adopted eventually was SPI. It is a legal entity, and so it can hold assets (trademark, domain names, etc.), it can collect CLAs if you so choose, and it can collect donations on behalf of the project. It does the crux of what you need, a neutral entity to hold the naming right (which I think is at the heart of the issue, really.)

But SPI doesn't require a particular development process. So you can maintain the status quo in that regard. You just nominate the liason from the project to SPI, and in the eyes of SPI that person is the project. This is both a blessing and a curse --- blessing because projects like ours can maintain the way it operates and preserves its culture. But it's a curse because you'd need more governance to protect the community from you. There's no systematic check that prevents you from going rogue. I know some projects where the owner decided to turn the project closed source for profits, and it's not pretty. Not that I'm saying you'd ever do that, but after a fisasco like this one, I think it's fair to the community to make sure that won't happen.

Now that I've gone through the whole thing, I see that if one really takes this to the logical conclusion, you'll go the way toward Apache/Eclipse style mechanisms.

I think you're probably right, and I'm warming to the idea of a neutral foundation. But honestly, the bureacracy just scares the shit out of me.

There is currently only one person paid full-time to work on Vert.x (me), it's a very small project in that regard, and if I spend most of the time filling in forms and attending reviews then I'm scared the project dies.

[Andy Piper]

Hiya Tim

On Thursday, 10 January 2013 19:05:07 UTC, Tim Fox wrote:

By administrate i mean *full control* over the project. I no longer have that, and VMware has the ability to revoke those rights at any time. That's the point.

 

I get that you're concerned, but in the joint statement that Alexis and Mark put out I'm pretty sure that I read that both orgs want you to retain project leadership and have you involved.

Putting aside generic "uncertainties" for the sake of moving this along... Can you be really specific about what you're currently lacking that you believe that you need right now? From my reading of the difference between owner and fully-enabled manager in Github and Google Groups etc, I'm not sure what you might be missing?

Thanks.

Andy

[Joern Bernhardt]

From a developer point of view, I want to ...

- have a cool project to work on.
Vert.x certainly is this, whatever its name might be.
- have someone lead the project who is motivated and determined to get it done.
As a developer, I wouldn't be motivated if I had to care about politics all the time. It's no wonder Vert.x doesn't get many commits right now. From my experience, a motivated project leader also motivates contributors.
- be able to contribute EASILY.
If possible, there are CLAs or politics involved. Not being a native english speaker and especially no lawyer, I didn't really like to sign the CLA a few months ago. If we could get rid of that, it would be great.
- have a nice working climate.
That means helpful and nice people on the mailing list, IRC, issue tracker, etc.

The last point is actually the most important to me, as it should result in more people attracted to the project.

My thoughts about this discussion:
My biggest fear is that a fork may exclude contributing members of the community, essentially kicking them out. This is something nice people usually don't do.

Right now, it is not clear for me which option to choose. For me the options sound like this:
1) Who is "the project"/is there an owner? Will we have a backup plan, if the project leader decides to quit? My concern is clearly the long-term support of Vert.x here.
2) The questions are the same as in 1), but it would also piss off some members, I guess.
3) I don't know too much about ASF, so I'd like to know more about it before deciding. It sounds like Tim would loose all leader privileges, which I think is bad.
4) As a user of eclipse, this sounds great - but what I heard from the discussion, this looks like a heavy process to get commits into it and stuff like GitHub may not be used. Working with something different looks like a step back for me.
5) (as mentioned by Mark [bytor99999]), well, that would be great, but I guess it won't be motivating for Tim to commit, if VMW is seen as someone who could take his "baby" away from him at any point in time. From what I've read, I highly doubt that VMW would do something like that and it might just have been a big misunderstanding - but if the trust is gone right now, it's hard to repair it within reasonable time.

In the end, I hope the decision won't be based on "the ones screaming the loudest will get what they want". *cough* build system *cough*

Even though I'd vote for option 1 or 5, I guess these are extremely unrealistic to get. Either Tim or VMW don't want to do that, so we should evaluate the compromises. 2 would be the "easy route", but as I said, I wouldn't vote for that. I'd like to know more about ASF and what this would mean for the community: Switch to other code hosting, issue tracking, wiki, mailing list? Sign CLAs? Wait longer for contributions to get pulled in?

[Norman Maurer]

Let me try to give you a bit of more insight in the ASF:

 * All the code need to get hosted at ASF hardware. They support subversion and git. You can mirror your code to github as read-only in both cases. But no write possible on github.

 * JIRA is used as issue-tracker

 * The ASF use moinmoin as wiki and has a "self-build" CMS for the Website

 * Supports Jenkins and buildbot for CI

 * Projects can have access to a freebsd jail for own usage

 * Allows to push releases to maven via nexus

 * Everything happens on mailing lists

 * You can accept code from "non-committers" if the grant rights without a CLA

 * There are 3 different roles in the Project:

     * Committer - People that are allowed to directly commit / push to the repository 

     * PMC - Are responsible for the Project and VOTE new committers. Every committer needs to get voted, there is NO way around this

     * PMC Chair - The Person that is the one that reports to the Board of the Foundation every 3 months the state of the Project. The PMC Chair has no more power then any other PMC member. So there is no Leader.

 * Only committers are allowed to "commit" code directly to the repository of the project. Every committer first needs to get VOTED by the PMC and sign an CLA or the company he is working for a ICLA.

 * Every release needs to get VOTED. Only VOTES of PMC members are binding.

 * New projects go through the incubator (incubator.apache.org) to become Top-Level and get "mentored" during this phase. How long incubation takes depends on many things. Like the community, cleanup code to be conform with ASL2 etc.

 ...

 

I think those are the most important things that affect the "workflow" and address your questions. That said the ASF is not a bad place I just tried to make clearer what it means to the project. In fact be aware that I'm a ASF Member and also a PMC Member of Apache James (was the PMC Chair in the past), so I have some experience what it means to have a Project under the ASF.

Bye,

Norman

[Tim Fox]

On Thursday, 10 January 2013 19:40:31 UTC, Andy Piper wrote:

Hiya Tim

On Thursday, 10 January 2013 19:05:07 UTC, Tim Fox wrote:

By administrate i mean *full control* over the project. I no longer have that, and VMware has the ability to revoke those rights at any time. That's the point.

 

I get that you're concerned, but in the joint statement that Alexis and Mark put out I'm pretty sure that I read that both orgs want you to retain project leadership and have you involved.

It's nice that a verbal commitment has been made, but it provides no guarantees. And it's not really about retaining leadership it's about a more general issue of the community feeling same that unsolicited changes aren't going to be hoisted on them.

 

Putting aside generic "uncertainties" for the sake of moving this along... Can you be really specific about what you're currently lacking that you believe that you need right now? From my reading of the difference between owner and fully-enabled manager in Github and Google Groups etc, I'm not sure what you might be missing?

See above. 

Thanks.

Andy

[Kohsuke Kawaguchi]

2013/1/10 Tim Fox <timv...@gmail.com>

Now that I've gone through the whole thing, I see that if one really takes this to the logical conclusion, you'll go the way toward Apache/Eclipse style mechanisms.

I think you're probably right, and I'm warming to the idea of a neutral foundation. But honestly, the bureacracy just scares the shit out of me.

There is currently only one person paid full-time to work on Vert.x (me), it's a very small project in that regard, and if I spend most of the time filling in forms and attending reviews then I'm scared the project dies.

Yep, which is why I recommended SPI.

--
Kohsuke Kawaguchi

[Pid]

On 10/01/2013 20:08, Tim Fox wrote:
>
>
> On Thursday, 10 January 2013 19:40:31 UTC, Andy Piper wrote:
>
> Hiya Tim
>
> On Thursday, 10 January 2013 19:05:07 UTC, Tim Fox wrote:
>
>
> By administrate i mean *full control* over the project. I no
> longer have that, and VMware has the ability to revoke those
> rights at any time. That's the point.
>
>
> I get that you're concerned, but in the joint statement that Alexis
> and Mark put out I'm pretty sure that I read that both orgs want you
> to retain project leadership and have you involved.
>
>
> It's nice that a verbal commitment has been made, but it provides no
> guarantees. And it's not really about retaining leadership it's about a
> more general issue of the community feeling same that unsolicited
> changes aren't going to be hoisted on them.

I've reviewed the threads and I see that we have not stated who does
have the 'owner' status currently – so in the interest of disclosure and
to avoid uncertainty, I thought I'd tell everyone that it's me*.

I hope that the community will take my word that I will not do anything
hasty, unethical or inappropriate or foist any changes on the community.


p

* I think I've said this before, but yes, I do work for VMware.

> Putting aside generic "uncertainties" for the sake of moving this
> along... Can you be really specific about what you're currently
> lacking that you believe that you need right now? From my reading of
> the difference between owner and fully-enabled manager in Github and
> Google Groups etc, I'm not sure what you might be missing?
>
>
> See above.

--

[key:62590808]

[Matthias Wessendorf]

if u really want... there is bugzilla :D

> * The ASF use moinmoin as wiki and has a "self-build" CMS for the Website

that's news to me - at Apache MyFaces we use confluence...
example -> https://cwiki.apache.org/confluence/display/EXTCDI/Index

> * Supports Jenkins and buildbot for CI
> * Projects can have access to a freebsd jail for own usage
> * Allows to push releases to maven via nexus
> * Everything happens on mailing lists
> * You can accept code from "non-committers" if the grant rights without a
> CLA
> * There are 3 different roles in the Project:
> * Committer - People that are allowed to directly commit / push to the
> repository
> * PMC - Are responsible for the Project and VOTE new committers. Every
> committer needs to get voted, there is NO way around this

not sure, why this is bad.

> * PMC Chair - The Person that is the one that reports to the Board of
> the Foundation every 3 months the state of the Project. The PMC Chair has no
> more power then any other PMC member. So there is no Leader.
> * Only committers are allowed to "commit" code directly to the repository
> of the project.

on github - I think - a PR (pull request) needs to be merged by a
member of the organisation as well, or am I wrong?

> Every committer first needs to get VOTED by the PMC

Assuming my previous comment is right:
Do github projects always grant "membership" of an organisation after
one PR? Not sure - some may do, that's true!
(Also... at Apache... some projects tend to grant commit access
quicker than others - it's up to the PMC. Not every project is the
same)

> and sign
> an CLA or the company he is working for a ICLA.

CLA is not unusual, see:
http://jquery.github.com/cla.html
or
https://github.com/square/SocketRocket/blob/master/README.rst#contributing

> * Every release needs to get VOTED. Only VOTES of PMC members are binding.

Of course, if a user (yes, they are "allowed" to reply to vote mails)
finds a critical bug,
usually their "-1" to the release is also somewhat important/binding -
at least on projects that I have worked on...
(could be different on your ASF projects - sure, you are fine to
ignore that. And, perhaps you have done that - but that's usually a
bad sign of ignorance...
but again, not every project (and their PMC) are the same).

> * New projects go through the incubator (incubator.apache.org) to become
> Top-Level and get "mentored" during this phase. How long incubation takes
> depends on many things. Like the community, cleanup code to be conform with
> ASL2 etc.

The philosophy behind the incubation is to make sure there is a
healthy community, behind it...
Which makes sense (for me). It would be (IMO) wrong, to directly be a
full-blown top-level-project (TLP).


-Matthias

disclaimer: ASF member - but speaking on my own

> ...
>
> I think those are the most important things that affect the "workflow" and
> address your questions. That said the ASF is not a bad place I just tried to
> make clearer what it means to the project. In fact be aware that I'm a ASF
> Member and also a PMC Member of Apache James (was the PMC Chair in the
> past), so I have some experience what it means to have a Project under the
> ASF.
>
> Bye,
> Norman
>

> --
>
>



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

[Norman Maurer]

Yeah missed that. I think most of the new Projects use Jira.

>
>> * The ASF use moinmoin as wiki and has a "self-build" CMS for the Website
>
> that's news to me - at Apache MyFaces we use confluence...
> example -> https://cwiki.apache.org/confluence/display/EXTCDI/Index

Ups right there is moinmoin and confluence. Thanks, I forgot confluence.

>
>> * Supports Jenkins and buildbot for CI
>> * Projects can have access to a freebsd jail for own usage
>> * Allows to push releases to maven via nexus
>> * Everything happens on mailing lists
>> * You can accept code from "non-committers" if the grant rights without a
>> CLA
>> * There are 3 different roles in the Project:
>> * Committer - People that are allowed to directly commit / push to the
>> repository
>> * PMC - Are responsible for the Project and VOTE new committers. Every
>> committer needs to get voted, there is NO way around this
>
> not sure, why this is bad.

I'm not sayin it is bad. I just tried to layout the facts.

>
>> * PMC Chair - The Person that is the one that reports to the Board of
>> the Foundation every 3 months the state of the Project. The PMC Chair has no
>> more power then any other PMC member. So there is no Leader.
>> * Only committers are allowed to "commit" code directly to the repository
>> of the project.
>
> on github - I think - a PR (pull request) needs to be merged by a
> member of the organisation as well, or am I wrong?

Yep the same...

>
>> Every committer first needs to get VOTED by the PMC
>
> Assuming my previous comment is right:
> Do github projects always grant "membership" of an organisation after
> one PR? Not sure - some may do, that's true!
> (Also... at Apache... some projects tend to grant commit access
> quicker than others - it's up to the PMC. Not every project is the
> same)

Right,
It is up to the PMC .. For example the Apache James Project tend to grand it quite easily. Apache Hadoop is more 'strict' from my expirience. Again it is all up to PMC of the Project..

>
>> and sign
>> an CLA or the company he is working for a ICLA.
>
> CLA is not unusual, see:
> http://jquery.github.com/cla.html
> or
> https://github.com/square/SocketRocket/blob/master/README.rst#contributing
>

Yeah, and a CLA makes a lot of sense!

>> * Every release needs to get VOTED. Only VOTES of PMC members are binding.
>
> Of course, if a user (yes, they are "allowed" to reply to vote mails)
> finds a critical bug,
> usually their "-1" to the release is also somewhat important/binding -
> at least on projects that I have worked on...
> (could be different on your ASF projects - sure, you are fine to
> ignore that. And, perhaps you have done that - but that's usually a
> bad sign of ignorance...
> but again, not every project (and their PMC) are the same).

Again I just wanted to list the facts....

>
>> * New projects go through the incubator (incubator.apache.org) to become
>> Top-Level and get "mentored" during this phase. How long incubation takes
>> depends on many things. Like the community, cleanup code to be conform with
>> ASL2 etc.
>
> The philosophy behind the incubation is to make sure there is a
> healthy community, behind it...
> Which makes sense (for me). It would be (IMO) wrong, to directly be a
> full-blown top-level-project (TLP).
>

Yeah, the incubator makes a lot of sense. It also ensures that the Project gets how an Apache OpenSource project must operate..

>
> -Matthias
>
> disclaimer: ASF member - but speaking on my own
>
>> ...
>>
>> I think those are the most important things that affect the "workflow" and
>> address your questions. That said the ASF is not a bad place I just tried to
>> make clearer what it means to the project. In fact be aware that I'm a ASF
>> Member and also a PMC Member of Apache James (was the PMC Chair in the
>> past), so I have some experience what it means to have a Project under the
>> ASF.
>>
>> Bye,
>> Norman
>>
>> --
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>

> --
>
>

I really hope my email did not sound like I think how the ASF works is bad. I just wanted to give others an overview about the rules that are not aware of them.

Bye,
Norman

[Bradley M. Kuhn]

[ Sorry to be slightly Kibo-like and join this thread, but someone
mentioned to me that Conservancy came up in this thread, and I thought
I could comment usefully on the decision about fiscal sponsorship that
the vert.x project currently faces. ]

Conservancy would welcome an application for vert.x, but I typically
tell projects that they should actually talk to *all* possible fiscal
sponsors to find the right one. Each of the options discussed in this
thread are different types of organizations on various spectra.
However, IMO, the most important difference is that some of
these orgs are non-profit trade associations (a 501(c)(6) in
the USA), some are non-profit charities (a 501(c)(3) in the USA).

Mike Milinkovich's posts about how Eclipse works gives a good sense of
what a trade association looks like. This solution is right for some
projects. Mike has noted in his posts that Eclipse focuses on
interacting with the for-profit industry, which is what trade
associations like Eclipse (and Linux Foundation, too) are for. They do
a good job at this task, and if your project's main goal is to interact
with for-profit companies, then a trade association solution as a fiscal
sponsor is probably right.

By contrast, non-profit charities like SPI and Conservancy focus on
benefiting the general public. Every time a member project at
Conservancy wants to do something, the question I ask is whether the
plan helps make the software better (more available, more usable, etc.)
for everyone in the general public. It's not that charities *ignore* the
for-profit corporate user base, but rather we focus first on the
*individuals* who use and develop the software.

Anyway, there are fortunately lots of non-profit options of all sorts
(including some that I didn't even cover in this email), and I urge the
vert.x project to think about all of its options. Conservancy welcomes
applications from projects that are just considering but aren't sure
yet, as the application process is often a good way to see if a given
org is the right fit. I can't speak how other orgs treat this process,
but I do know that SPI feels the same way about this aspect of it.

On that point, I see Jenkins mentioned in this thread, and Kohsuke
Kawaguchi talking about how Jenkins joined SPI. As KK could tell you,
Jenkins applied to both Conservancy and SPI, but ultimately decided that
SPI was a better option, in part because Jenkins didn't really need the
"full service plan" that Conservancy has. SPI focuses on a smaller set
of services, which means it's easier for them to take new projects
quickly, when compared to Conservancy. SPI's and Conservancy's service
plans, BTW, are available here:
http://www.spi-inc.org/projects/services/
http://sfconservancy.org/members/services/


More than anything else, though, I think what matters in selecting a
fiscal sponsor is finding the right fit for the users and developers of
the software. I urge vert.x developers and users to look at all the
options and decide what's best for them, and to not jump to a decision
quickly merely because there's a specific set of issues to be resolved.
All of these orgs talked about in this thread could probably help you
solve the issues that vert.x faces, but they'll all do so in very
different ways.


BTW, I did want to reply to Trustin's email publicly (I've already
written privately in more detail):

이희승 (Trustin Lee) wrote at 09:26 (EST):
> 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 [for
> Netty]

As I mentioned in private email today, Conservancy was pretty
resource-strapped for most of 2011 and into 2012, and we had a really
long backlog of project applications.

The good news is that we're just about to clear the queue of evaluations
of projects entirely. (You'll see on Conservancy's website that projects
started joining again back in November, and we'll have at least a few
more joining very soon). Conservancy always has a policy to place the
needs of existing members over new applications, so sometimes we don't
move as quickly as we'd like on new applications.

This is also another common difference between (c)(3)'s and (c)(6)'s.
Because (c)(6)'s are permitted to act directly in the interest of
companies, companies are often more willing to give to (c)(6)'s because
they can "buy" a certain amount of influence. Thus, the (c)(6)'s
budgets are usually larger.

(c)(3)'s, by contrast, are actually legally prohibited from acting in a
way designed to benefit a specific company or individual. As such, it
also means that fundraising is admittedly a bit more difficult sometimes
for a (c)(3) than a (c)(6). So, you'll find the (c)(3)'s in our space
usually have less staffing, etc.

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

Something that isn't a legal entity can't hold copyright. I do see
frequently that some Free Software projects have notices say "Copyright,
The Project". However, if "The Project" isn't a legal entity in some
jurisdiction somewhere in the world, that's probably not a valid
copyright notice, and I recommend against using it. (The good news is
that most jurisdictions don't require copyright notices to have a
copyright claim, so the damage is minimal and more of just a confusion.)
BTW, IANAL and TINLA.

For Conservancy's part, Conservancy doesn't require copyright assignment
nor CLAs for our member projects, but we instead help projects decide
what they want to do in this regard and help them develop policies that
work for the project. Some Conservancy projects use CLAs, some don't,
and the ones that do have varying CLA terms. Some accept copyright
assignment to Conservancy for the project; some don't at all.
--
Bradley M. Kuhn, Executive Director, Software Freedom Conservancy

[Michael Van Geertruy]

Norman,

That is incorrect. I am a committer to the ASF and contribute to a number of projects, and have for a few years now.  Here is the normal structure of the projects I work with:

PMC Chair - the elected leader of the project, this title stands for "Project Management Committee Chairman". For projects that have graduated from incubator status to a Top-Level project, this person is also a Vice President of the ASF.  Elections are usually help annually, but this may vary based on the complexity of the community. 

PMC Member(s) - committers who other PMC members have selected to help lead the project. The title stands for "Project Management Committee Member". Most major changes are evaluated by the PMC, who then discusses changes with thier respective committers, contributors and users.

Committer - A committer is someone who has write-level access to the source-code repository used by the project. A person is normally invited after having built-up trust with the community, donated a major amount of work to the project, or has contributed something of value to the project.  Many projects will not simply make someone a committer because they are a manager in the company that employs some of the other committers.  The reason for this is simple, ASF projects are a meritocracy, not a mirror of the political/managerial process of an associated company or organization.

Contributor - A contributor is someone who has sign the ASF release, and provides a patch to the codebase of a project. A comitter will then review the patch, and either apply it or send it back for specific work.

User - This is simply someone who uses an application. They ask questions, which contributors, committers, and PMC members answer.

The project determines how changes are requested and approved.  In some projects, the PMC Chair is the sole decision maker. In other projects the PMC will vote. In still others, committers get votes. In most projects, everyone gets some form of input into the process. Again, the project determines this, not the ASF. The project when in the incubator phase will make this decision with its existing community, and these internal processes may change if the project so determines a change is necessary.

So, to summarize, if the community chooses to go with ASF, Tim will very likely be the PMC chair, and he and an ASF mentor will assist in setting up the infrastructure, including the internal processes used by the project.  If forking is also performed, and the package structure needs to change, there are many of us in ASF who are very senior developers who are available to help, and who have done this kind of thing in the past.

Mike Van

ASF Committer (Kalumet)

On Thursday, January 10, 2013 8:37:46 AM UTC-6, Norman Maurer wrote:

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

[Matthias Wessendorf]

yeah, I missed those two roles (user + developer/contributor) as well.

Here is actually a good doc, that states the facts:

http://www.apache.org/foundation/how-it-works.html

-M

[Norman Maurer]

Hi Michael,

thanks again for list all the Roles so we have a complete list. But I must disagree with some point, the PMC Chair does not "lead" the Project. It is the PMC which is not "one" person, but a group of.

See also:

http://www.apache.org/foundation/how-it-works.html#pmc-chair

Bye,

Norman

[이희승 (Trustin Lee)]

Thank you very much Bradley for the detailed explanation.  I'd like to apologize if my answer to Mark gave any misinformation or misconception to the public.

Cheers,
T

--

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

[Guillaume Laforge]

The advantage with ASF, at least, is that it's clearly a community-lead / community-driven project, by the very nature of how Apache works.

--
 
 

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

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

Social: @glaforge / Google+

[Alexis Richardson]

Kohsuke,

Thank-you very much for posting this.  I don't know much about SPI, but it looks like another way to do things, and one with appeal to some projects.  Interesting indeed.

alexis

[Alexis Richardson]

Bradley, thank-you! I also wish to apologise for implying that the process may have been 'slow'.

alexis

[Alexis Richardson]

Jim

I just wanted to thank you for posting about the ASF.  When I first started thinking about how VMware might best work with Red Hat as well as the larger community, the ASF was the first idea that came to mind.  Certainly it is a model that has worked well and continues to do so.  

Can I ask for a clarification on your post below?  What are the ASF rules on CLAs in 2013?  My understanding was the copyright was granted and not assigned.  Is that correct?

alexis

[Christian Essl]

Why not just leave (or give back) everything to Tim?

Of course there has to be a legal-entity, which holds the naming-rights, the top-acces-right to source-control, disucssion-grops, docs etc, but this does not have to be a company or an association. This can of course also be a private person - like with most projects - in this case of course Tim Fox.

I think he is the one the community trusts, he is the one who contributes most and he is the one this project live of. And than I hope Tim can arrange with the main sponsors VMWare and Redhat in the following months some form of gooing on in which form or with which organization ever.

But in the mean-time I think the project is doomed dead if this discussion goes on and it is not returned to tim, because neither Tim nor other codes like it and it does not help to increase the trust in the community. And if it is dead nobody wins.

Therefore I think VMWare should return the rights now to Tim Fox in Person (not as emploie of Red Head), or otherwise Tim should fork the project and make legaly binding sure with Red Hat that it is his personal project even if he works paid on it.  

VMWare should in compensation be named as the main sponsor on the home-page, because Tim worked for them and the second most important contributor Pid as well 

Just my 2c

Christian

[Mark Little]

Tim, I suggest you talk with some of our team who work in Eclipse and get real world feedback. I've not heard any complaints from them and we work on projects both big and small.

Sent from my iPhone

--
 
 

[Mark Little]

Red Hat is committed to vert.x and if I have to fill in forms for you then I will.

Sent from my iPhone

--
 
 

[Pid *]

On 11 Jan 2013, at 09:23, Mark Little <markc...@gmail.com> wrote:

Red Hat is committed to vert.x and if I have to fill in forms for you then I will.

I'd second that - I'd be happy to support Tim by taking care of time-consuming administrative stuff.

p

--
 
 

[Alexis Richardson]

Christian,

At VMware, we make open source software that can be used by everyone.  That includes individuals, schools, foundations, governments, and corporations.  These users have different needs.  Some of them wish to participate in open source communities and some don't - they instead want to buy commercial support or commercial licenses.  These require a solid legal foundation in all respects.  In thinking about everyone's needs we have to plan for the long term.  And over the long term, we have always hoped that vert.x can be as big as Tomcat or Node.js.  That's why we made an investment and kept it going.  

We don't think there is only one way to make open source software.  But what we do *know* is that foundations provide certainty.  This in the form of a rock solid legal, social, community and commercial basis for long term investments in open source software.  We strongly prefer a foundation as the way forward for vert.x and our investment in the software and community.  We strongly prefer to grant rights to individuals, no matter how special they are, via known and trusted licenses and/or foundations.  In the light of this, we have concluded some time ago that Red Hat becoming a major backer of vert.x is a great opportunity.  By granting or assigning VMware IP to a foundation, we might lose some unilateral rights, but we and the community gain *far more* by the potential to collaborate with other companies, as well as people, on a fair and sound basis.

Therefore I ask you to help.  I am not sure if this exact situation is precedented, but I hope people can see that VMware and Red Hat can achieve something really good here.

Best wishes

alexis

[Jim Jagielski]

At the ASF, all committers are required to sign an iCLA (Individual Contributor License Agreement: http://www.apache.org/licenses/icla.txt).

These do NOT assign copyright, but instead are agreements that provide IP tracking, indicating that the person providing the code or patch is authorized to do so (they are the copyright holder, for example), AND they allow the ASF to license their code/patch under the AL. It also allows for the ASF to relicense under a later version of the AL, should that be required. The original copyright holder maintains their copyright ;)

[Jim Jagielski]

Tim,

At the ASF there are "leaders", just not "bosses". In effect, all members of the project cmmt (the PMC) are "leaders" of the project.

Now you may ask what's the diff between leaders and bosses, and it's kinda subtle, but a core aspect of Apache. A "boss" sez "We are going to do this" and it gets done. A "boss" sez "This patch is stupid, we're not adding it" and it doesn't get added. A leader sez "We should add this" and explains why and gets people to agree and come to a consensus. A leader sez "This patch is incorrect" and explains why and gets people to agree. It *ensures* community involvement in the project. And it provides some level of continuity.

I'm an old-timer and I recall taking my then girl-friend to see "Fame" (Oh the things you do when in love). And there's this scene where this guy studying music and composition tells the teacher that he doesn't need anyone else to create his music. With the synth's of the day, he can do it all himself. And the teacher replies: "That's not music, Martelli; that's masturbation". A funny line, kinda crude, but it makes a point. A community project should be, well, community involved.

There's more detail on why we consider the community aspect of projects at the ASF so important, and there's some presos from myself and others on Slideshare and Youtube about them if interested.

Cheers!

[Sven Efftinge]

Hi Tim,

On Thursday, January 10, 2013 7:43:28 PM UTC+1, Tim Fox wrote:

I can certainly see the advantages of a neutral foundation such as ASF/Eclipse - I only wish there was a neutral foundation which didn't impose such an onerous development process.

I've been reading through the Eclipse development process: http://www.eclipse.org/projects/dev_process/development_process_2011.php

It seems really complex. I think I will go insane if I have to follow that. I'd also be worried that the project would screech to a halt. Anyone who knows me knows I am really not a process guy.

I've been a project lead to several Eclipse projects for more than five years now. Although the process looks scary it's actually not a big deal. It roughly takes 2% of my time and it is definitely worth it just for the IP-cleaness. Also the foundation staff is super friendly and helpful.

Even if you decide to go with option 2) I'd suggest to think about Eclipse, as the whole issue couldn't have happened at Eclipse and you might not want to run into this twice.

Sven

 

[Tim Fox]

On Friday, 11 January 2013 12:05:24 UTC, Jim Jagielski wrote:

Tim,

At the ASF there are "leaders", just not "bosses". In effect, all members of the project cmmt (the PMC) are "leaders" of the project.

Now you may ask what's the diff between leaders and bosses, and it's kinda subtle, but a core aspect of Apache. A "boss" sez "We are going to do this" and it gets done. A "boss" sez "This patch is stupid, we're not adding it" and it doesn't get added. A leader sez "We should add this" and explains why and gets people to agree and come to a consensus. A leader sez "This patch is incorrect" and explains why and gets people to agree. It *ensures* community involvement in the project. And it provides some level of continuity.

Agreed. I think what you describe is a common sense way to lead a project, and it's the approach I try to take already in Vert.x, but without a formal process to back it up. I think any "leader" who pushes through changes regardless of whether the community thinks it's a good idea will end up with not much of a project/community before too long.

[Jim Jagielski]

Yeppers, that's been our experience and basically why we operate the way we do... 

[Bruce Snyder]

Agreed and good points, Tim. I have worked on a number of projects at the ASF over the years, including taking some through the Incubator. Although there are some requirements of projects, it's all very common sense and community focused. If you're interested to pursue a movement to the ASF, I'm certainly willing to help and I'm an ASF member so I can serve as a project mentor. 

Bruce 

--
 
 

--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );'

ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder

[Tim Fox]

Firstly thanks everyone for your great comments so far. 

It seems much clearer to me now that putting the project into a neutral foundation is the only real way to protect the community in the future.

In my mind, that leaves us with two possibilities:

1) VMware submit the project as-is to a foundation.

2) Fork the project and submit it to a foundation after removing VMware branding.

The main argument for forking has been to remove VMW from a position of absolute control over the community, but if the project was in a foundation then no single party would be able to exert any control over it outside of that allowed by the governance model of the foundation. Bearing that in mind the argument for forking seems weaker. The forking argument becomes weaker still when you consider the extra hassle that a re-branding will involve.

I'd therefore like to recommend to the community that the best way forward is for VMware to submit the project to a foundation and for Vert.x to continue there.

Of course, it is entirely up to VMware as to whether they want to go down this path or not. From what I have heard so far they appear amenable to this idea, but this would need confirmation from them.

If VMware aren't interested in doing this, then I'd recommend option 2).

[Bernardo Rosmaninho]

Option 2!

2013/1/11 Tim Fox <timv...@gmail.com>

--
 
 

--
Bernardo Rosmaninho Oliveira

[Alexis Richardson]

Tim,

VMware would strongly support (1), i.e.: submit the project as-is to a foundation.

It would be great to hear which foundations you feel have the most to offer the project.

alexis

[Norman Maurer]

1) Should be the way to go then…

Bye,

Norman

--
 
 

[Tim Fox]

Please make your disagreement known!!

Since we have no formal process of voting and considering that a) web polls are extremely unsafe b) google groups has no way to organise a poll whereby each member of the group can vote at most once, I suggest that if anyone does NOT agree with my recommendation, then please post on this thread.

If you do agree, no need to say anything.

If we only get a small number of NOs then I think it's a fairly safe assumption that most members of the community agree. If we get quite a lot of NOs then it's indeterminate and we need to find some other way of gauging community approval.

We can leave the question opening until next week, to give everyone a reasonable amount of time to see it.

--
 
 

[bytor99999]

Isn't there three answers and not just yes or no.

You had option 1 and 2 with going to a foundation, then "no" against either.

I think you should drop 2 from the equation. Any type of fork, with or without a foundation won't work for us.

But I am definitely a Yes on option 1.

Based on the posts here, I think it really is the best of all worlds possible.

Thanks

Mark Spritzler

[Bovet Laurent]

From a user perspective, 1) is clearly the best option. As vert.x is quite a new technology, we have to convince our customers and management to adopt it. Forking and changing names would make this a bit more difficult. And the current name is cool, no?

[Matthias Wessendorf]

On Fri, Jan 11, 2013 at 4:32 PM, Bruce Snyder <bruce....@gmail.com> wrote:
> Agreed and good points, Tim. I have worked on a number of projects at the
> ASF over the years, including taking some through the Incubator. Although
> there are some requirements of projects, it's all very common sense and
> community focused. If you're interested to pursue a movement to the ASF, I'm
> certainly willing to help and I'm an ASF member so I can serve as a project
> mentor.

+1
helped on a few incubations as well, and I am happy to help (e.g. as a
mentor/) w/ vert.x, when landing at the ASF.

-M

[Tim Fox]

On 11/01/13 16:18, Alexis Richardson wrote:

Tim,

VMware would strongly support (1), i.e.: submit the project as-is to a foundation.

It would be great to hear which foundations you feel have the most to offer the project.

Personally, I am undecided. I'm going to do a bit more reading over the weekend.

Does VMware have a view on what foundation it prefers?

--
 
 

[Nate McCall]

#1. Ideally at ASF.

However, it's been super cool to see everyone take the time to write
up their experiences and/or describe their orgs and processes in
detail. I've personally learned a great deal the past couple of days
because of this. Many thanks.

[Tim Fox]

+1 To that.

It's been great to hear the foundation stories straight from the "horse's mouth" so to speak :)

[Alexis Richardson]

+1 - and a big thank you to all those who have contributed freely and in such detail.

 

[Paula Hunter]

I am a bit late to the party, but also want to let you know that there are other options out there with regard to orgs.  The Outercurve Foundation is forge and license agnostic, and we allow the project teams to dictate much of the development process and model.   We take a light touch with regard to project oversight, but still provide that vendor neutral home.   Jim and Mike have done a great job explaining many of the benefits of considering a foundation, so I will leave it at that unless there are additional questions.

[Alexis Richardson]

Tim,

On Friday, January 11, 2013 5:10:53 PM UTC, Tim Fox wrote:

On 11/01/13 16:18, Alexis Richardson wrote:

Tim,

VMware would strongly support (1), i.e.: submit the project as-is to a foundation.

It would be great to hear which foundations you feel have the most to offer the project.

Personally, I am undecided. I'm going to do a bit more reading over the weekend.

Does VMware have a view on what foundation it prefers?

VMware would prefer:

1. a foundation that everyone can get going with quickly

2. that strongly supports project leadership, community and merit 

3. and that we have worked with before.  

We have worked with Apache and Eclipse before and rate both highly.  I've asked our people to let me know if we have to jump through more hoops with one or the other.

By "get going with quickly", I think an ideal scenario would enable VMware to submit the project asap, and get to the point where all contributions were to the project assuming it is safely harboured in the foundation or certainly about to be.  If my language appears a little vague, it's because each foundation has a slightly different process.

My own (personal) bias at this minute is slightly towards Eclipse, mainly I feel because Mike made a strong statement on item (2).  That said, I think the ASF folks have also been very impressive.  I am less clear about the other foundations, which should not be interpreted as a negative.

alexis

[Bradley M. Kuhn]

Jim Jagielski wrote at 06:54 (EST):

> At the ASF, all committers are required to sign an iCLA (Individual
> Contributor License Agreement: http://www.apache.org/licenses/
> icla.txt).

...

> These do NOT assign copyright,

I didn't talk much about the cultural differences between Apache and
Conservancy in my previous post, other than to say some Conservancy
projects use CLAs and some don't.

One thing worth noting regarding CLAs is that some projects find CLAs
too broad for their needs. Indeed, most CLAs transfer so many rights,
they don't differ *that* much from Copyright Assignment Agreements
(©AAs). In many cases, the only difference between a ©AA and a CLA is
whose name goes in the copyright notice, and all else is essentially the
same.

Conservancy has found that many of our projects prefer something akin to
Linux's Developer Certificate of Origin (DCO), which is a lightweight
assurance (it's not really a CLA per se) attesting that the developer
has done some due diligence to verify a right to contribute under the
project's own license. Richard Fontana, a lawyer at Red Hat, has often
called this "inbound=outbound" -- where the project's outbound copyright
license is the same thing developers must assent to. I believe oVirt
and OpenShift Origin projects use "inbound=outbound", for example.

Ultimately, I think all this is just cultural differences between
foundational choices. YMMV.
--
Bradley M. Kuhn, Executive Director, Software Freedom Conservancy

[Bruce Snyder]

+1 for option #1 with a clarification. 

I believe that this is understood, but I want to clarify -- the submission to the ASF should be drafted as a joint effort between representatives from VMware and Tim Fox along with community members. Although this task is largely administrative, it's important that those involved understand the process and set expectations appropriately. 

Bruce 

--
 
 

[Mike Milinkovich]

Tim,

As you may have gathered, I certainly agree that going the foundation route is the best path for vert.x. We would love to have your project at Eclipse, but you would undoubtedly be well served at Apache, SPI or others as well. 

I think that all of us involved in free and open source software are fortunate to have such a wide variety of alternatives. It speaks highly of the health of our community (in the broadest sense of the word). This thread has been a particularly positive and thoughtful discussion.

[Oliver Rolle]

Hi,

I followed the discussion and I think 1) with Eclipse is the way to go, bc VMW prefers this option and imo the community slightly favours Eclipse.
Does VMW transfer the vertx brand, website, blog etc. to Eclipse Foundation?

best regards
Oli

[Alexis Richardson]

+1 :-)

[Alexis Richardson]

On Friday, January 11, 2013 6:31:01 PM UTC, Oliver Rolle wrote:

Hi,

I followed the discussion and I think 1) with Eclipse is the way to go, bc VMW prefers this option and imo the community slightly favours Eclipse.
Does VMW transfer the vertx brand, website, blog etc. to Eclipse Foundation?

If people favour Eclipse, we'll first do what Mike says we need to do.  If there is anything left over then we'll seek a way to put that into safe harbour too.  For example, I don't know if Eclipse can 'own' a blog site account.  We'll take steps to make sure such accounts are held safely and neutrally.

alexis

[Mike Milinkovich]

On Friday, January 11, 2013 1:31:01 PM UTC-5, Oliver Rolle wrote:

Does VMW transfer the vertx brand, website, blog etc. to Eclipse Foundation?

If the project comes to Eclipse, then yes ownership of the trademark and domain name would have to transferred[1] to the Eclipse Foundation. I believe the same would be true of the ASF as well.

As we say in our guidelines[2]:

The Eclipse Foundation holds the trademarks for the project names and logos on behalf of, and for the benefit of, the Eclipse projects. The individual projects are not separate legal entities and thus not able to hold trademarks individually. The Eclipse Foundation is a legal entity and thus holds the trademarks on behalf of the projects.

[1] http://www.eclipse.org/legal/Trademark_Transfer_Agreement.pdf

[2] http://www.eclipse.org/legal/logo_guidelines.php

[Alexis Richardson]

Bruce,

On Friday, January 11, 2013 5:56:57 PM UTC, Bruce Snyder wrote:

+1 for option #1 with a clarification. 

I believe that this is understood, but I want to clarify -- the submission to the ASF should be drafted as a joint effort between representatives from VMware and Tim Fox along with community members. Although this task is largely administrative, it's important that those involved understand the process and set expectations appropriately. 

Good point.  If we all pull together, more can get done faster and with better results!

alexis