Discussion: The future of the Vert.x project

4402 views
Skip to first unread message

Tim Fox

unread,
Jan 10, 2013, 4:58:38 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 5:11:42 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 5:18:17 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 5:27:01 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 5:39:06 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 5:47:25 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 6:14:32 AM1/10/13
to ve...@googlegroups.com

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

unread,
Jan 10, 2013, 6:18:04 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 6:38:06 AM1/10/13
to ve...@googlegroups.com
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]

signature.asc

Tim Fox

unread,
Jan 10, 2013, 6:59:07 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 7:08:52 AM1/10/13
to ve...@googlegroups.com


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:


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

unread,
Jan 10, 2013, 7:43:53 AM1/10/13
to ve...@googlegroups.com
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.


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

unread,
Jan 10, 2013, 7:52:00 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 7:57:57 AM1/10/13
to ve...@googlegroups.com
I have asked Mike from the Eclipse Foundation to join the group. I believe another Eclipse representative will also be joining.

Mark.

Nate McCall

unread,
Jan 10, 2013, 8:06:54 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 8:32:38 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 8:34:20 AM1/10/13
to ve...@googlegroups.com

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

Alexis Richardson

unread,
Jan 10, 2013, 8:43:48 AM1/10/13
to ve...@googlegroups.com
I would love to understand why Trustin and RH chose the SFC route.  It seems to have taken a long time.

Mark Little

unread,
Jan 10, 2013, 8:50:58 AM1/10/13
to ve...@googlegroups.com
We didn't choose the SFC route. That came after Trustin left with the Netty project.

Mark.


--
 
 

Alexis Richardson

unread,
Jan 10, 2013, 8:56:10 AM1/10/13
to ve...@googlegroups.com


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

unread,
Jan 10, 2013, 8:57:52 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 9:07:13 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 9:17:50 AM1/10/13
to ve...@googlegroups.com


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

unread,
Jan 10, 2013, 9:25:42 AM1/10/13
to ve...@googlegroups.com
I can ask him.

Mark.


--
 
 

이희승 (Trustin Lee)

unread,
Jan 10, 2013, 9:26:08 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 9:27:24 AM1/10/13
to ve...@googlegroups.com
Thanks Trustin. Now you can ignore the email from me ;-)

Mark.


--
 
 

Alexis Richardson

unread,
Jan 10, 2013, 9:28:18 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 9:31:27 AM1/10/13
to ve...@googlegroups.com
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

Alexis Richardson

unread,
Jan 10, 2013, 9:32:28 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 9:37:46 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 9:38:33 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 9:40:39 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 9:40:59 AM1/10/13
to ve...@googlegroups.com
I like that Eclipse has "clear project leaders" to quote from Mike's post.

Douglas Campos

unread,
Jan 10, 2013, 10:00:54 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 10:13:15 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 10:20:50 AM1/10/13
to ve...@googlegroups.com


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

unread,
Jan 10, 2013, 10:22:08 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 10:22:24 AM1/10/13
to ve...@googlegroups.com


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

unread,
Jan 10, 2013, 10:41:15 AM1/10/13
to ve...@googlegroups.com
My preference is certainly a foundation, and of the ones mentioned so far, Eclipse is my favourite.

Mark.
> --
>
>

Jim Jagielski

unread,
Jan 10, 2013, 10:54:55 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 11:04:16 AM1/10/13
to ve...@googlegroups.com

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

unread,
Jan 10, 2013, 11:05:24 AM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 1:12:29 PM1/10/13
to ve...@googlegroups.com

My vote is for ASF

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

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

--


Tim Fox

unread,
Jan 10, 2013, 1:37:26 PM1/10/13
to ve...@googlegroups.com


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

unread,
Jan 10, 2013, 1:43:28 PM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 1:45:48 PM1/10/13
to ve...@googlegroups.com


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.


alexis

Mike Milinkovich

unread,
Jan 10, 2013, 2:05:02 PM1/10/13
to ve...@googlegroups.com


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

unread,
Jan 10, 2013, 2:05:07 PM1/10/13
to ve...@googlegroups.com
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.


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

unread,
Jan 10, 2013, 2:09:33 PM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 2:21:14 PM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 2:40:31 PM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 2:42:07 PM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 3:05:12 PM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 3:08:03 PM1/10/13
to ve...@googlegroups.com


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

unread,
Jan 10, 2013, 3:20:43 PM1/10/13
to ve...@googlegroups.com



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

unread,
Jan 10, 2013, 3:34:02 PM1/10/13
to ve...@googlegroups.com
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]

signature.asc

Matthias Wessendorf

unread,
Jan 10, 2013, 6:33:36 PM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 7:28:08 PM1/10/13
to ve...@googlegroups.com
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

unread,
Jan 10, 2013, 7:58:11 PM1/10/13
to ve...@googlegroups.com
[ 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

unread,
Jan 10, 2013, 8:56:08 PM1/10/13
to ve...@googlegroups.com
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.