Discussion: The future of the Vert.x project

Showing 1-227 of 227 messages
Discussion: The future of the Vert.x project Tim Fox 1/10/13 1:58 AM
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.

Re: Discussion: The future of the Vert.x project Daryl Teo 1/10/13 2:11 AM
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
Re: [vertx:5844] Re: Discussion: The future of the Vert.x project Tim Fox 1/10/13 2:18 AM
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.


--
 
 

Re: Discussion: The future of the Vert.x project Oliver Rolle 1/10/13 2:27 AM
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.

Am Donnerstag, 10. Januar 2013 10:58:38 UTC+1 schrieb Tim Fox:
Re: [vertx:5842] Discussion: The future of the Vert.x project Tim Fox 1/10/13 2:39 AM
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.
>
> --
>
>

Re: [vertx:5842] Discussion: The future of the Vert.x project Brian Lalor 1/10/13 2:47 AM
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.
Re: Discussion: The future of the Vert.x project Henri Gomez 1/10/13 3:14 AM

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.


Re: Discussion: The future of the Vert.x project Andy Piper 1/10/13 3:18 AM
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
Re: [vertx:5842] Discussion: The future of the Vert.x project Pid 1/10/13 3:38 AM
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]

Re: [vertx:5854] Discussion: The future of the Vert.x project Tim Fox 1/10/13 3:59 AM
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).
Re: Discussion: The future of the Vert.x project Tim Fox 1/10/13 4:08 AM


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.
Re: Discussion: The future of the Vert.x project Andy Piper 1/10/13 4:43 AM
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
Re: [vertx:5910] Re: Discussion: The future of the Vert.x project Henri Gomez 1/10/13 4:52 AM
Netty didn't seems to be in current sfconservancy yet :

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


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

Re: Discussion: The future of the Vert.x project Mark Little 1/10/13 4:57 AM
I have asked Mike from the Eclipse Foundation to join the group. I believe another Eclipse representative will also be joining.

Mark.
Re: [vertx:5864] Re: Discussion: The future of the Vert.x project Nate McCall 1/10/13 5:06 AM
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 :)
Re: Discussion: The future of the Vert.x project Bob McWhirter 1/10/13 5:32 AM
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
Re: Discussion: The future of the Vert.x project Mike Milinkovich 1/10/13 5:34 AM

I'm here! My day is just starting in Ottawa....I will read the thread and answer where I can.
Re: [vertx:5910] Re: Discussion: The future of the Vert.x project Alexis Richardson 1/10/13 5:43 AM
I would love to understand why Trustin and RH chose the SFC route.  It seems to have taken a long time.
Re: [vertx:5872] Discussion: The future of the Vert.x project Mark Little 1/10/13 5:50 AM
We didn't choose the SFC route. That came after Trustin left with the Netty project.

Mark.


--
 
 

Re: [vertx:5872] Discussion: The future of the Vert.x project Alexis Richardson 1/10/13 5:56 AM


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 :-)
Re: Discussion: The future of the Vert.x project Mike Milinkovich 1/10/13 5:57 AM
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.



Re: Discussion: The future of the Vert.x project Alexis Richardson 1/10/13 6:07 AM
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
Re: Discussion: The future of the Vert.x project Mike Milinkovich 1/10/13 6:17 AM


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.
 
Re: [vertx:5874] Discussion: The future of the Vert.x project Mark Little 1/10/13 6:25 AM
I can ask him.

Mark.


--
 
 

Re: [vertx:5874] Discussion: The future of the Vert.x project Trustin Lee 이희승 1/10/13 6:26 AM
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
Re: [vertx:5878] Discussion: The future of the Vert.x project Mark Little 1/10/13 6:27 AM
Thanks Trustin. Now you can ignore the email from me ;-)

Mark.


On 10 Jan 2013, at 14:26, 이희승 (Trustin Lee) wrote:

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

On Thu, Jan 10, 2013 at 10:56 PM, Alexis Richardson <alexis.r...@gmail.com> wrote:


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 :-)




 

Mark.


On 10 Jan 2013, at 13:43, Alexis Richardson wrote:

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



On Thursday, January 10, 2013 12:52:00 PM UTC, Henri Gomez wrote:
Netty didn't seems to be in current sfconservancy yet :

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


2013/1/10 Andy Piper <andyp...@gmail.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

On Thursday, 10 January 2013 12:08:52 UTC, Tim Fox wrote:


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.
 

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


On Thursday, 10 January 2013 09:58:38 UTC, Tim Fox wrote:
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.


--
 
 


--
 
 


--
 
 



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

--
 
 

Re: [vertx:5874] Discussion: The future of the Vert.x project Alexis Richardson 1/10/13 6:28 AM
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
Re: [vertx:5878] Discussion: The future of the Vert.x project Guillaume Laforge 1/10/13 6:31 AM
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

Re: Discussion: The future of the Vert.x project Alexis Richardson 1/10/13 6:32 AM
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.



On Thursday, January 10, 2013 2:17:50 PM UTC, Mike Milinkovich wrote:


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.
 
Re: Discussion: The future of the Vert.x project Norman Maurer 1/10/13 6:37 AM
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


Am Donnerstag, 10. Januar 2013 14:32:38 UTC+1 schrieb 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


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


On Thursday, 10 January 2013 17:58:38 UTC+8, Tim Fox wrote:
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.

Re: [vertx:5874] Discussion: The future of the Vert.x project Norman Maurer 1/10/13 6:38 AM
Yeah something like the SFC would be nice for Netty, but so far everything worked out like it is for us. 

Bye,
Norman


Am Donnerstag, 10. Januar 2013 15:26:08 UTC+1 schrieb Trustin Lee:




 

Mark.




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


On Thursday, 10 January 2013 09:58:38 UTC, Tim Fox wrote:
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.


--
 
 


--
 
 

--
 
 



--
https://twitter.com/trustin
https://twitter.com/trustin_ko
https://twitter.com/netty_project
Re: Discussion: The future of the Vert.x project Mike Milinkovich 1/10/13 6:40 AM
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 :)
Re: Discussion: The future of the Vert.x project Alexis Richardson 1/10/13 6:40 AM
I like that Eclipse has "clear project leaders" to quote from Mike's post.
Re: [vertx:5886] Discussion: The future of the Vert.x project Douglas Campos 1/10/13 7:00 AM
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
> --
>  
>  

Re: [vertx:5886] Discussion: The future of the Vert.x project Mike Milinkovich 1/10/13 7:13 AM
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.
Re: [vertx:5886] Discussion: The future of the Vert.x project Mike Milinkovich 1/10/13 7:20 AM


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. 

Re: Discussion: The future of the Vert.x project bytor99999 1/10/13 7:22 AM
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
Re: [vertx:5886] Discussion: The future of the Vert.x project Andy Piper 1/10/13 7:22 AM


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

Re: [vertx:5886] Discussion: The future of the Vert.x project Mark Little 1/10/13 7:41 AM
My preference is certainly a foundation, and of the ones mentioned so far, Eclipse is my favourite.

Mark.
> --
>  
>  

Re: Discussion: The future of the Vert.x project Jim Jagielski 1/10/13 7:54 AM
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.


On Thursday, January 10, 2013 4:58:38 AM UTC-5, Tim Fox wrote:
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.

Re: [vertx:5896] Discussion: The future of the Vert.x project Mark Little 1/10/13 8:04 AM

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.
Re: Discussion: The future of the Vert.x project Jim Jagielski 1/10/13 8:05 AM
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


On Thursday, 10 January 2013 17:58:38 UTC+8, Tim Fox wrote:
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.

Re: [vertx:5897] Discussion: The future of the Vert.x project Alex Tkachman 1/10/13 10:12 AM

My vote is for ASF

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

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

--


Re: Discussion: The future of the Vert.x project Tim Fox 1/10/13 10:37 AM


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.

 
 
Re: [vertx:5886] Discussion: The future of the Vert.x project Tim Fox 1/10/13 10:43 AM
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 :(
Re: Discussion: The future of the Vert.x project Alexis Richardson 1/10/13 10:45 AM


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
Re: [vertx:5886] Discussion: The future of the Vert.x project Mike Milinkovich 1/10/13 11:05 AM


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.
Re: [vertx:5907] Re: Discussion: The future of the Vert.x project Tim Fox 1/10/13 11:05 AM
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.

 
 
--
 
 

Re: [vertx:5886] Discussion: The future of the Vert.x project Kohsuke Kawaguchi 1/10/13 11:09 AM
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.
Re: [vertx:5886] Discussion: The future of the Vert.x project Tim Fox 1/10/13 11:21 AM
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.
Re: [vertx:5907] Re: Discussion: The future of the Vert.x project Andy Piper 1/10/13 11:40 AM
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
Re: Discussion: The future of the Vert.x project Joern Bernhardt 1/10/13 11:42 AM
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?
Re: Discussion: The future of the Vert.x project Norman Maurer 1/10/13 12:05 PM


Am Donnerstag, 10. Januar 2013 20:42:07 UTC+1 schrieb Joern Bernhardt:
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

Re: [vertx:5907] Re: Discussion: The future of the Vert.x project Tim Fox 1/10/13 12:08 PM


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
Re: [vertx:5959] Discussion: The future of the Vert.x project Kohsuke Kawaguchi 1/10/13 12:20 PM



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
Re: [vertx:5915] Re: Discussion: The future of the Vert.x project Pid 1/10/13 12:34 PM
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]

Re: [vertx:5914] Re: Discussion: The future of the Vert.x project Matthias Wessendorf 1/10/13 3:33 PM
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
Re: [vertx:5918] Re: Discussion: The future of the Vert.x project Norman Maurer 1/10/13 4:28 PM
Am 11.01.2013 um 00:33 schrieb Matthias Wessendorf <mat...@apache.org>:
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
[vertx:5874] Conservancy & other fiscal sponsor options (was Re: Discussion: The future of the Vert.x project) Bradley M. Kuhn 1/10/13 4:58 PM
[ 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
Re: Discussion: The future of the Vert.x project Michael Van Geertruy 1/10/13 5:56 PM
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


Am Donnerstag, 10. Januar 2013 14:32:38 UTC+1 schrieb Bob McWhirter:
Re: [vertx:5922] Re: Discussion: The future of the Vert.x project Matthias Wessendorf 1/10/13 11:26 PM
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
Re: Discussion: The future of the Vert.x project Norman Maurer 1/10/13 11:31 PM
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:

Bye,
Norman


Am Freitag, 11. Januar 2013 02:56:08 UTC+1 schrieb Michael Van Geertruy:
Re: [vertx:5920] Conservancy & other fiscal sponsor options (was Re: Discussion: The future of the Vert.x project) Trustin Lee 이희승 1/10/13 11:35 PM
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
Re: [vertx:5925] Re: Discussion: The future of the Vert.x project Guillaume Laforge 1/10/13 11:44 PM
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

Re: [vertx:5886] Discussion: The future of the Vert.x project Alexis Richardson 1/11/13 12:44 AM
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
Re: [vertx:5920] Conservancy & other fiscal sponsor options (was Re: Discussion: The future of the Vert.x project) Alexis Richardson 1/11/13 12:46 AM
Bradley, thank-you! I also wish to apologise for implying that the process may have been 'slow'.

alexis
Re: Discussion: The future of the Vert.x project Alexis Richardson 1/11/13 12:53 AM
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
Re: Discussion: The future of the Vert.x project Christian Essl 1/11/13 1:14 AM
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

On Thursday, January 10, 2013 10:58:38 AM UTC+1, Tim Fox wrote:
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.

Re: [vertx:5906] Discussion: The future of the Vert.x project Mark Little 1/11/13 1:21 AM
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
--
 
 
Re: [vertx:5911] Discussion: The future of the Vert.x project Mark Little 1/11/13 1:23 AM
Red Hat is committed to vert.x and if I have to fill in forms for you then I will.

Sent from my iPhone
--
 
 
Re: [vertx:5932] Discussion: The future of the Vert.x project Pid 1/11/13 1:26 AM
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



--
 
 
Re: Discussion: The future of the Vert.x project Alexis Richardson 1/11/13 3:00 AM
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
Re: Discussion: The future of the Vert.x project Jim Jagielski 1/11/13 3:54 AM
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 ;)
Re: [vertx:5886] Discussion: The future of the Vert.x project Jim Jagielski 1/11/13 4:05 AM
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!
Re: [vertx:5886] Discussion: The future of the Vert.x project Sven Efftinge 1/11/13 4:15 AM
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

 
Re: [vertx:5886] Discussion: The future of the Vert.x project Tim Fox 1/11/13 4:27 AM


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.
Re: [vertx:5886] Discussion: The future of the Vert.x project Jim Jagielski 1/11/13 5:44 AM
Yeppers, that's been our experience and basically why we operate the way we do... 
Re: [vertx:5942] Discussion: The future of the Vert.x project Bruce Snyder 1/11/13 7:32 AM
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
Re: Discussion: The future of the Vert.x project Tim Fox 1/11/13 8:11 AM
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).
Re: [vertx:5945] Re: Discussion: The future of the Vert.x project Bernardo Rosmaninho 1/11/13 8:16 AM
Option 2!


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



--
Bernardo Rosmaninho Oliveira

Re: Discussion: The future of the Vert.x project Alexis Richardson 1/11/13 8:18 AM
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
Re: [vertx:5945] Re: Discussion: The future of the Vert.x project Norman Maurer 1/11/13 8:19 AM
1) Should be the way to go then…

Bye,
Norman

Am 11.01.2013 um 17:11 schrieb Tim Fox <timv...@gmail.com>:

--
 
 

Re: [vertx:5945] Re: Discussion: The future of the Vert.x project Tim Fox 1/11/13 8:27 AM
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.
--
 
 

Re: [vertx:5945] Re: Discussion: The future of the Vert.x project bytor99999 1/11/13 8:50 AM
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
Re: Discussion: The future of the Vert.x project Laurent Bovet 1/11/13 8:52 AM
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?
Re: [vertx:5943] Discussion: The future of the Vert.x project Matthias Wessendorf 1/11/13 8:57 AM
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
Re: [vertx:5947] Re: Discussion: The future of the Vert.x project Tim Fox 1/11/13 9:10 AM
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?
--
 
 

Re: [vertx:5951] Discussion: The future of the Vert.x project Nate McCall 1/11/13 9:13 AM
#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.
Re: [vertx:5951] Discussion: The future of the Vert.x project Tim Fox 1/11/13 9:38 AM
+1 To that.

It's been great to hear the foundation stories straight from the "horse's mouth" so to speak :)
Re: [vertx:5951] Discussion: The future of the Vert.x project Alexis Richardson 1/11/13 9:43 AM
+1 - and a big thank you to all those who have contributed freely and in such detail.

 
Re: [vertx:5951] Discussion: The future of the Vert.x project Paula Hunter 1/11/13 9:48 AM
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.
Re: [vertx:5947] Re: Discussion: The future of the Vert.x project Alexis Richardson 1/11/13 9:52 AM
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
Re: [vertx:5939] Re: Discussion: The future of the Vert.x project Bradley M. Kuhn 1/11/13 9:52 AM
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
Re: [vertx:5945] Re: Discussion: The future of the Vert.x project Bruce Snyder 1/11/13 9:56 AM
+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 


--
 
 



--
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
Re: Discussion: The future of the Vert.x project Mike Milinkovich 1/11/13 10:24 AM
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.


Re: Discussion: The future of the Vert.x project Oliver Rolle 1/11/13 10:31 AM
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

Am Freitag, 11. Januar 2013 17:11:49 UTC+1 schrieb Tim Fox:
Re: Discussion: The future of the Vert.x project Alexis Richardson 1/11/13 10:32 AM
+1 :-)
Re: Discussion: The future of the Vert.x project Alexis Richardson 1/11/13 10:35 AM


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
Re: Discussion: The future of the Vert.x project Mike Milinkovich 1/11/13 10:37 AM


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.

Re: [vertx:5945] Re: Discussion: The future of the Vert.x project Alexis Richardson 1/11/13 10:41 AM
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
Re: [vertx:5958] Re: Discussion: The future of the Vert.x project Mark Little 1/11/13 10:55 AM
I can add that Red Hat has good experience with ASF and Eclipse. However, feedback is that Eclipse can be less red tape. As I said earlier, my personal preference is Eclipse.

Sent from my iPhone
--
 
 
Re: [vertx:5947] Re: Discussion: The future of the Vert.x project cctrieloff 1/11/13 10:59 AM


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.



Both Foundations are top notch, worked in both of them over the years. Given what vertx is I believe (subjectively) it will ride a stronger wave through the association with other projects at Apache, than at Eclispe.  In sure Mike will disagree and add colour for Eclipse...
Re: Discussion: The future of the Vert.x project Chris Aniszczyk 1/11/13 11:02 AM
On Friday, January 11, 2013 12:35:43 PM UTC-6, Alexis Richardson wrote:


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.

If you move your project over to Eclipse, I would love to mentor the project to make sure things move quickly. I recently helped see through the migration to Git [1] which took longer than I wanted it too, but we did it. We are in a much better place now.

Also I've mentored many projects at Eclipse and actually enjoy it, feel free to email me if you have any questions Tim.

 
Re: [vertx:5947] Re: Discussion: The future of the Vert.x project Mike Milinkovich 1/11/13 11:10 AM


On Friday, January 11, 2013 1:59:38 PM UTC-5, cctri...@gmail.com wrote:

Both Foundations are top notch, worked in both of them over the years. Given what vertx is I believe (subjectively) it will ride a stronger wave through the association with other projects at Apache, than at Eclispe.  In sure Mike will disagree and add colour for Eclipse

Carl, 

My guess is that since its been several years since your involvement at Eclipse you're perhaps not up to speed on far we've gone beyond our roots in tools. Eclipse runtime projects like Virgo and Jetty have been doing pretty well.  But there is no doubt that we still struggle a bit with the perception that Eclipse only does tools, even though that stopped being true in 2004.
Re: [vertx:5947] Re: Discussion: The future of the Vert.x project Jim Jagielski 1/11/13 11:28 AM


On Friday, January 11, 2013 12:52:59 PM UTC-5, Alexis Richardson wrote:

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.



Eclipse is a great place, no doubt. The ASF has kinda wrote the book on community and merit, and I've talked a bit about the project leadership aspects. Awhile ago, iirc, Simon Phipps did an article about "open governance" and "rated" a number of FOSS entities on "how open they really are" and, again iirc, Apache was the only one that rated 10/10.

At Apache we try to keep company's at "arm's length" so to speak...
Re: [vertx:5947] Re: Discussion: The future of the Vert.x project Jim Jagielski 1/11/13 11:29 AM


On Friday, January 11, 2013 1:59:38 PM UTC-5, cctrieloff wrote:

Both Foundations are top notch, worked in both of them over the years. Given what vertx is I believe (subjectively) it will ride a stronger wave through the association with other projects at Apache, than at Eclispe.

You mean like Deft? *grin* (http://incubator.apache.org/deft/
Re: [vertx:5947] Re: Discussion: The future of the Vert.x project Mike Milinkovich 1/11/13 11:35 AM


On Friday, January 11, 2013 2:28:09 PM UTC-5, Jim Jagielski wrote:
At Apache we try to keep company's at "arm's length" so to speak...

The differences here between Apache and Eclipse here are very minor in reality. Eclipse has corporate members, this is true. But because we do, we have to be even more vendor-neutral than other organizations. As one example, we won't use free licenses for Jira and Confluence from Atlassian because of the implied endorsement inherent in such use. All of our infrastructure has to be 100% FLOSS as a result. 

Another difference is that many Eclipse committers use their work emails (vmware.com, ibm.com, etc.) rather than personal ones. We neither encourage nor discourage the practice. I would assert that making those corporate affiliations completely transparent to the community does more good than harm. But I do recognize that there may be a variety of opinions on that :) 
Re: [vertx:5974] Discussion: The future of the Vert.x project Mark Little 1/11/13 11:39 AM
I can certainly second Chris. He's done a great job elsewhere and would be a great shepherd/mentor.

Mark.


--
 
 

Re: [vertx:5973] Discussion: The future of the Vert.x project Mark Little 1/11/13 11:50 AM
Red Hat has a lot of positive experience of both ASF and Eclipse. Trying to be objective here and putting aside any incorrectly perceived biases against one organisation or another, I still feel that Eclipse would be a better fit for vert.x than ASF due to the way in which the vert.x project has been managed so far. I've been a lurker on the google group for about a year, promising to do some work on transactions but not being able to find the time so far. From what I've seen and discussions I've had with Tim over the past few months, it seems to me that Eclipse offers the path of least resistance to the current vert.x project than anything else. However, ultimately it is Tim and the community that needs to make the choice, with the input of others of course.

And before anyone jumps to conclusions, I am not suggesting that there are problems with ASF or other organisations/foundations. I am simply looking at the facts behind the way in which Tim and the community have run the project to date and my knowledge of how these other foundations work, looking for the least impedance mismatch to facilitate a smooth transition from the current to the future. ASF is good for some things, otherwise we (Red Hat) wouldn't have taken the DeltaSpike project there in the first place, and since the Fuse acquisition we now have significant input to a wider range of projects there such as Camel and CXF. But I think everyone would agree that no one organisation/foundation is good for everything.

Mark.


--
 
 

Re: [vertx:5945] Discussion: The future of the Vert.x project Mark Little 1/11/13 11:52 AM
+1


On 11 Jan 2013, at 16:11, Tim Fox wrote:

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.

Re: [vertx:5974] Discussion: The future of the Vert.x project Alexis Richardson 1/11/13 12:01 PM
I don't know Chris but he has strong credentials.  I'd like to see mentors from 'end user' companies like Twitter if possible.

alexis
Re: [vertx:5974] Discussion: The future of the Vert.x project Jim Jagielski 1/11/13 12:08 PM
That's one thing that would be different at the ASF: the mentors aren't associated with their "end user" companies... they don't represent their companies at all, just themselves. 
Re: [vertx:5947] Re: Discussion: The future of the Vert.x project Jim Jagielski 1/11/13 12:11 PM
Whatever is best for vert.x is what matters... 
Re: [vertx:5983] Discussion: The future of the Vert.x project Wayne Beaton 1/11/13 12:15 PM
Eclipse mentors do no represent their companies in any formal sense.

Wayne
--
 
 

--
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse Projects
EclipseCon
          2013
Re: [vertx:5945] Discussion: The future of the Vert.x project bytor99999 1/11/13 12:37 PM
So then are we saying it is now a matter of choosing the Eclipse or Apache foundations?

Should we just flip a coin? ;)

Basically, I would be happy with either. There are definitely pros and cons to either one. Of course, the cons list on both sides seem pretty small.

Viva Le vert.x!

Mark
Re: [vertx:5986] Discussion: The future of the Vert.x project Mark Little 1/11/13 12:47 PM
I believe Tim is going to think about things over the weekend and try to condense all of this information of the past week into a coherent choice. As I have said before, I trust Tim to help the community come to the right decision and I am not going to force him in one direction or another. He is far more in tune with the community than I.

Mark.


--
 
 

Re: [vertx:5986] Discussion: The future of the Vert.x project Brian Lalor 1/11/13 12:53 PM
On Jan 11, 2013, at 3:37 PM, bytor99999 <bytor...@gmail.com> wrote:

Basically, I would be happy with either. There are definitely pros and cons to either one. Of course, the cons list on both sides seem pretty small.

The loss of the ability to use GitHub is a pretty major one, unfortunately.  Pull Requests == the way of the future.  Whatever it takes to keep on keepin' on, tho…
Re: [vertx:5987] Discussion: The future of the Vert.x project Wayne Beaton 1/11/13 1:04 PM
Eclipse projects work with Pull requests. They just can't pull them directly as there are certain key auditing requirements that are not met.

Linus has some relevant things to say on the matter:

https://github.com/torvalds/linux/pull/17

Wayne
--
 
 

--
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse Projects
EclipseCon
          2013
Re: [vertx:5986] Discussion: The future of the Vert.x project Joern Bernhardt 1/11/13 1:37 PM

I just hope we get a good issue tracker, which doesn't look like it's from the 90's and allows to search and categorize issues easy. GH was okay in that regard. A roadmap and/or forum would be nice, too. Searching the mailing list to find information about feature X almost never works well.
Re: [vertx:5951] Discussion: The future of the Vert.x project Paula Hunter 1/11/13 1:55 PM
Tim, would you like me to post more specifics regarding the Outercurve Foundation here?   We have some characteristics of both Apache and Eclipse, but there are also distinctions that may be appealing.   One of our mentors suggested we chime in (and by way of disclosure, Jim Jagielski is also on the Outercurve board of directors).

On Friday, January 11, 2013 12:43:08 PM UTC-5, Alexis Richardson wrote:


On Friday, January 11, 2013 5:38:50 PM UTC, Tim Fox wrote:


On Friday, 11 January 2013 17:13:52 UTC, Nate McCall wrote:
#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.

+1 To that.

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

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

 
Re: [vertx:6038] Discussion: The future of the Vert.x project Michael Van Geertruy 1/11/13 2:02 PM

Brian,


Which choice do you feel would preclude the use of Git?

From: Brian Lalor <bla...@bravo5.org>
To: ve...@googlegroups.com
Subject: Re: [vertx:6038] Discussion: The future of the Vert.x project
Date: 1/11/13, 2:53 PM




On Jan 11, 2013, at 3:37 PM, bytor99999 <bytor...@gmail.com> wrote:
Basically, I would be happy with either. There are definitely pros and cons to either one. Of course, the cons list on both sides seem pretty small.


The loss of the ability to use GitHub is a pretty major one, unfortunately.  Pull Requests == the way of the future.  Whatever it takes to keep on keepin' on, tho�

--
 
 
Re: [vertx:5990] Discussion: The future of the Vert.x project Pid 1/11/13 2:25 PM
Perhaps now would be a good time to find out if people have a wish list as well as thinking about the more pressing concerns. Seems like we have a great opportunity to talk about the future.


p



Re: [vertx:5991] Discussion: The future of the Vert.x project Pid 1/11/13 2:56 PM
On 11 Jan 2013, at 21:55, Paula Hunter <hunter...@gmail.com> wrote:

Tim, would you like me to post more specifics regarding the Outercurve Foundation here?   We have some characteristics of both Apache and Eclipse, but there are also distinctions that may be appealing.   One of our mentors suggested we chime in (and by way of disclosure, Jim Jagielski is also on the Outercurve board of directors).

I would like to hear more.


p


On Friday, January 11, 2013 12:43:08 PM UTC-5, Alexis Richardson wrote:


On Friday, January 11, 2013 5:38:50 PM UTC, Tim Fox wrote:


On Friday, 11 January 2013 17:13:52 UTC, Nate McCall wrote:
#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.

+1 To that.

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

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

 

--
 
 
Re: [vertx:5990] Discussion: The future of the Vert.x project Pid 1/11/13 3:02 PM


On 11 Jan 2013, at 21:37, Joern Bernhardt <joern.b...@googlemail.com> wrote:

I think it would be reasonable to explore some of the practical matters like, how does a release occur and to where - e.g. Maven Central - and if/how the options differ, if at all.

I would like to know about things like CI, because vert.x has a variety of integration challenges - could we have CI requiring a MongoDB instance for example?


p
Re: [vertx:5991] Discussion: The future of the Vert.x project Brian Lalor 1/11/13 3:32 PM
On Jan 11, 2013, at 5:02 PM, vangee...@gmail.com wrote:

Which choice do you feel would preclude the use of Git?

It's not the use of Git, it's the use of GitHub.  Both Apache and Eclipse demand that primary source code hosting be on their own hardware.  I think GitHub really encourages participation by inviting people to make patches and other contributions through their pull request mechanism.

Maybe I'm making too much noise about this, as I've never contributed to Apache or Eclipse foundation projects.  How would an outsider to the project (such as everyone on this list minus Pid and Tim) submit patches or new code?  There's essentially zero barrier to entry with GitHub; I have an account, I can send a pull request.  How does that work with Eclipse, Apache, and Outercurve?
Re: [vertx:6046] Discussion: The future of the Vert.x project Michael Van Geertruy 1/11/13 4:47 PM

Brian,


I can't comment on Eclipse, but on the project in ASF that I'm a committee on, we use github. Perhaps Jim J. can speak to the version control requirements of ASF.

From: Brian Lalor <bla...@bravo5.org>
To: ve...@googlegroups.com
Subject: Re: [vertx:6046] Discussion: The future of the Vert.x project
Date: 1/11/13, 5:32 PM

--
 
 
Re: [vertx:6046] Discussion: The future of the Vert.x project Oliver Rolle 1/11/13 4:53 PM
I think blalors point is a major one. It must be very simple to submit BusMods and make them public through the offical repository without getting a headach about licences or if the publishing of the BusMod followed the publishing process the foundation wants to see. I think npm is the best example how to do it user and community friendly.

Re: [vertx:5991] Discussion: The future of the Vert.x project elliot 1/12/13 4:15 AM

On a personal note, I find it very encouraging to see so many prestigious faces and organisations looking to get behind and support this initiative.  I find a few things damage any migration more than most:

- Personality: at the personal or organisational level can destroy the leadership and vision that brought the concept to life.
- Time: can lead to a productivity slump, negatively impacting energy and enthusiasm.
- Process: hamper or kill innovation through the methodology of decision making

As this project is at it's infancy the needs and desires of Tim, Stuart, etc are paramount.  My advice is look at what the project has now: Leadership, Community, Communication and Resourcing decide what works and doesn't. Over the next week, talk to each of the foundations on how they may address short any comings and put a migration plan down for each of the stake holders to sign off on.

As everyone wants what's best for the project, this should be able to move relatively quickly. :)

E

 


Re: [vertx:5990] Discussion: The future of the Vert.x project Tim Fox 1/13/13 1:22 AM
IMO, any neutral foundation we go with should provide

a) Hosting for git repository, mirrorable to the _current_ project at github. Please no svn, cvs or mercurial
b) Hosting for issue tracker. JIRA preferred. Don't like bugzilla.
c) Hosting for mailing lists 
d) Hosted for project web site
e) Hosting for downloads
f) Hosting for public module repository - in Vert.x 2.0 this is likely to be a Maven repository.
g) Ability to use external CI, e.g. CloudBees or Travis
h) Can accept pull requests via github

The hosting is important otherwise we're going to have to figure out how to host this stuff in a "neutral" way.
Re: [vertx:6014] Discussion: The future of the Vert.x project Brian Lalor 1/13/13 4:07 AM
On Jan 13, 2013, at 4:22 AM, Tim Fox <timv...@gmail.com> wrote:

h) Can accept pull requests via github

I've given this a little thought.  Under the covers, a pull request is just  a merge.  GitHub's got an API for just about everything, it seems.  So if there's a live mirror from $FOUNDATION's Git repo to GitHub and GitHub is treated as read-only, it should be possible to still allow the pull request mechanism to work.  It couldn't be accepted/closed via GitHub.com, but I understand the internals of Git and GitHub well enough that I think you could start out doing the merge manually (fetch pull requests from GitHub into local repo, merge, push to $FOUNDATION, manually close pull request on GitHub.com), and then create a private UI or post-receive hook to do the bookkeeping.
Re: [vertx:6015] Discussion: The future of the Vert.x project Tim Fox 1/13/13 4:14 AM
On 13/01/13 12:07, Brian Lalor wrote:
On Jan 13, 2013, at 4:22 AM, Tim Fox <timv...@gmail.com> wrote:

h) Can accept pull requests via github

I've given this a little thought.  Under the covers, a pull request is just  a merge.  GitHub's got an API for just about everything, it seems.  So if there's a live mirror from $FOUNDATION's Git repo to GitHub and GitHub is treated as read-only, it should be possible to still allow the pull request mechanism to work.  It couldn't be accepted/closed via GitHub.com, but I understand the internals of Git and GitHub well enough that I think you could start out doing the merge manually (fetch pull requests from GitHub into local repo, merge,

+1 I agree that should work.

push to $FOUNDATION, manually close pull request on GitHub.com), and then create a private UI or post-receive hook to do the bookkeeping.
--
 
 

Re: [vertx:6014] Discussion: The future of the Vert.x project Tom Carchrae 1/13/13 8:34 AM
a) Hosting for git repository, mirrorable to the _current_ project at github. Please no svn, cvs or mercurial

any reason the project can't mirror github?  i don't see the big issue with who is mirroring who.  especially in the land of git (where there is no 'master' repo).  that sounds like it would fix the pull request problem of h).

tom




Re: [vertx:5863] Discussion: The future of the Vert.x project Guillaume Laforge 1/13/13 9:06 AM
For the Groovy project, for example, we do use Github (including for pull requests) and mirror to Codehaus (since Groovy is a Codehaus project).

Le dimanche 13 janvier 2013, Tom Carchrae a écrit :
a) Hosting for git repository, mirrorable to the _current_ project at github. Please no svn, cvs or mercurial

any reason the project can't mirror github?  i don't see the big issue with who is mirroring who.  especially in the land of git (where there is no 'master' repo).  that sounds like it would fix the pull request problem of h).

tom




--
 
 


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


Re: [vertx:6014] Discussion: The future of the Vert.x project Andy Piper 1/13/13 1:47 PM

On Sunday, 13 January 2013 16:34:41 UTC, Tom Carchrae wrote:
a) Hosting for git repository, mirrorable to the _current_ project at github. Please no svn, cvs or mercurial

any reason the project can't mirror github?  i don't see the big issue with who is mirroring who.  especially in the land of git (where there is no 'master' repo).  that sounds like it would fix the pull request problem of h).

Not sure what the policy is - I thin Mike Milinkovich may have stated it on one of these threads - but Eclipse projects are hosted at Eclipse, and mirror to Github. They actually get mirrored to a specific location - the Eclipse organisation at Github - for instance, I work on Paho which has 3 repos currently, and one of these is at https://github.com/eclipse/paho.mqtt.java on Github. You'll notice I've changed the repo info text to direct bug reports to our Bugzilla at Eclipse (yes, per b, Eclipse runs Bugzilla rather than other trackers). A pull request made against Github would need to be IP reviewed by an existing committer and applied on the Eclipse Git instead.

If we decide to go along the Eclipse path then we may be able to work with the admins on e.g. how the mirroring works, but I don't think the Foundation would switch to Jira for one project... the Board might have the ability to make an exception but I just don't know.

Andy
Re: [vertx:6023] Discussion: The future of the Vert.x project Tim Fox 1/13/13 1:57 PM
On 13/01/13 21:47, Andy Piper wrote:

On Sunday, 13 January 2013 16:34:41 UTC, Tom Carchrae wrote:
a) Hosting for git repository, mirrorable to the _current_ project at github. Please no svn, cvs or mercurial

any reason the project can't mirror github?  i don't see the big issue with who is mirroring who.  especially in the land of git (where there is no 'master' repo).  that sounds like it would fix the pull request problem of h).

Not sure what the policy is - I thin Mike Milinkovich may have stated it on one of these threads - but Eclipse projects are hosted at Eclipse, and mirror to Github. They actually get mirrored to a specific location - the Eclipse organisation at Github
That should be ok - I want to keep the current project (because of our followers mainly), but github supports moving a project to a new organisation.


- for instance, I work on Paho which has 3 repos currently, and one of these is at https://github.com/eclipse/paho.mqtt.java on Github. You'll notice I've changed the repo info text to direct bug reports to our Bugzilla at Eclipse (yes, per b, Eclipse runs Bugzilla rather than other trackers).

This is an issue for me. Bugzilla really sucks. I really, really, hope there's another option there. Does Eclipse explicitly prohibit projects running external issue trackers?


A pull request made against Github would need to be IP reviewed by an existing committer and applied on the Eclipse Git instead.

That's fair enough. The important thing is users can _submit_ PRs via the normal github mechanism. If we have to process them in a different way that's not such an issue, and I understand that would probably be necessary given Eclipse's more stringent IP policy.

If we decide to go along the Eclipse path then we may be able to work with the admins on e.g. how the mirroring works, but I don't think the Foundation would switch to Jira for one project... the Board might have the ability to make an exception but I just don't know.

Andy
--
 
 

Re: [vertx:6014] Discussion: The future of the Vert.x project Wayne Beaton 1/13/13 3:37 PM
On 01/13/2013 04:22 AM, Tim Fox wrote:
IMO, any neutral foundation we go with should provide

a) Hosting for git repository, mirrorable to the _current_ project at github. Please no svn, cvs or mercurial

On December 21/2012, we killed our CVS server after spending more than two years hardening our support for Git and migrating all of our projects to it. We still have a small handful of projects working on SVN, but have stopped allowing new projects to use it. We are for all intents and purposes a Git shop.

GitHub mirrors our repositories. So does Google Source. We have a group of people from our community that administer the Eclipse organization on GitHub. So far, there hasn't been a need for administration on Google Source. We provide a link that anybody can use to get a list of our repositories. Where possible/sensible, we provide links to the mirrors. In the spirit of vendor neutrality, we list all the mirrors that we know about (if many more start doing it, we may have to rethink the UI).


b) Hosting for issue tracker. JIRA preferred. Don't like bugzilla.

We use Bugzilla. Our policy of vendor neutrality prevents us from using commercial products like JIRA. Even if they do give us a free license. All of our services a based on open source software.


c) Hosting for mailing lists
Yes

d) Hosted for project web site

Eclipse projects have a lot of choice here. We're in the process of rolling out a Drupal-based project website that provides a lot of automatically-generated information. Projects can opt to use this as their project website. Alternatively, they can build their own using whatever technology they choose.

e) Hosting for downloads

Yes


f) Hosting for public module repository - in Vert.x 2.0 this is likely to be a Maven repository.

Anything that is distributed by a project from any eclipse.org property is subject to our IP policy. Hosting a Maven repository that provides IP cleared artefacts is certainly possible. We are currently working on building a centralized Maven repository for Eclipse project (and vetted third party libraries).


g) Ability to use external CI, e.g. CloudBees or Travis

There are some possibilities here. I'd have to better understand what you're trying to do in order to provide a more definitive response.

We do have several projects doing CI today with Git/Gerrit/Hudson/Maven. We have a common build infrastructure that many of our projects leverage to reduce the effort involved with producing and maintaining a build, along with a full time build engineer to provide support.


h) Can accept pull requests via github

Eclipse projects can accept GitHub pull requests from existing project committers. Unfortunately, GitHub doesn't provide the necessary legal protections required to accept a request from somebody outside of the project. We require that all contributors consent to our terms of use and must explicitly sign off individual contributions by asserting that they have authored 100% of the content, have the rights to donate the content to Eclipse; and contribute the content under the project's license(s). We are working on implementing something similar to the certificate of authenticity that kernel.org uses that should simplify the process somewhat.

The hosting is important otherwise we're going to have to figure out how to host this stuff in a "neutral" way.
You've missed a few important considerations.

How important is vendor neutrality?

How important is intellectual property management? Do the developers like doing their own intellectual property management, or would it be helpful to have a dedicated team who can do this on their behalf?

Wayne
--
Wayne Beaton
Director of Open Source Projects

The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse Projects
EclipseCon
          2013
Re: Discussion: The future of the Vert.x project Craig McClanahan 1/13/13 7:01 PM
As an Apache Software Foundation member, I'm clearly a bit biased.  But I can speak to the fact that several projects I have been involved in (including Tomcat and Struts) have been vastly more successful hosted at ASF than they ever would have been elsewhere.  In addition, I'm totally up for being an active participant in the incubation process, should the vert.x community choose to go the ASF way.  Ideally, that would be option 3, but even in the "Hudson vs. Jenkins" scenario, who is winning that battle?  :-)

Details of technologies and tools can be addressed.  Process stuff at ASF is more oriented around clear IP provenance than anything else (and you should definitely want that).  I think vert.x at Apache would be a wonderful combination of technology and environment.

Craig McClanahan
Apache Software Foundation member (crai...@apache.org)

Re: [vertx:6024] Discussion: The future of the Vert.x project Tim Fox 1/14/13 12:13 AM
Hi Wayne,

Comments below,


On 13/01/13 23:37, Wayne Beaton wrote:
On 01/13/2013 04:22 AM, Tim Fox wrote:
IMO, any neutral foundation we go with should provide

a) Hosting for git repository, mirrorable to the _current_ project at github. Please no svn, cvs or mercurial

On December 21/2012, we killed our CVS server after spending more than two years hardening our support for Git and migrating all of our projects to it. We still have a small handful of projects working on SVN, but have stopped allowing new projects to use it. We are for all intents and purposes a Git shop.

GitHub mirrors our repositories. So does Google Source. We have a group of people from our community that administer the Eclipse organization on GitHub. So far, there hasn't been a need for administration on Google Source. We provide a link that anybody can use to get a list of our repositories. Where possible/sensible, we provide links to the mirrors. In the spirit of vendor neutrality, we list all the mirrors that we know about (if many more start doing it, we may have to rethink the UI).

b) Hosting for issue tracker. JIRA preferred. Don't like bugzilla.

We use Bugzilla. Our policy of vendor neutrality prevents us from using commercial products like JIRA. Even if they do give us a free license. All of our services a based on open source software.

Do you also explicit forbid projects from creating accounts external to the eclipse infrastructure for project stuff, i.e. could the project use an external JIRA?


c) Hosting for mailing lists
Yes
d) Hosted for project web site

Eclipse projects have a lot of choice here. We're in the process of rolling out a Drupal-based project website that provides a lot of automatically-generated information. Projects can opt to use this as their project website. Alternatively, they can build their own using whatever technology they choose.

e) Hosting for downloads

Yes

f) Hosting for public module repository - in Vert.x 2.0 this is likely to be a Maven repository.

Anything that is distributed by a project from any eclipse.org property is subject to our IP policy. Hosting a Maven repository that provides IP cleared artefacts is certainly possible. We are currently working on building a centralized Maven repository for Eclipse project (and vetted third party libraries).

This is a tricky one. We want to host a repo that contains Vert.x modules - most of these would be from 3rd parties (not created by Vert.x project). I guess you could think of it as like the npm repository in the node.js world, or a "Maven central" for Vert.x

Like Maven central, each user of a repository would have their own account and would manage the modules that they wish to publish. Note that it's them that's publishing stuff not the Vert.x project. We feel that having such a module repo is essential for a healthy vert.x module ecosystem.

Having to centrally administer such a repository and IP vet everything wouldn't scale.

If Eclipse wouldn't want to _host_ such a repository, would you object to it existing externally to the eclipse infrastructure?


g) Ability to use external CI, e.g. CloudBees or Travis

There are some possibilities here. I'd have to better understand what you're trying to do in order to provide a more definitive response.

We do have several projects doing CI today with Git/Gerrit/Hudson/Maven. We have a common build infrastructure that many of our projects leverage to reduce the effort involved with producing and maintaining a build, along with a full time build engineer to provide support.

Again, would eclipse object to us using an external account for CI?


h) Can accept pull requests via github

Eclipse projects can accept GitHub pull requests from existing project committers. Unfortunately, GitHub doesn't provide the necessary legal protections required to accept a request from somebody outside of the project. We require that all contributors consent to our terms of use and must explicitly sign off individual contributions by asserting that they have authored 100% of the content, have the rights to donate the content to Eclipse; and contribute the content under the project's license(s). We are working on implementing something similar to the certificate of authenticity that kernel.org uses that should simplify the process somewhat.

I'm not sure why this means that developers can's submit a PR via github. Once it's submitted and they have signed the appropriate paperwork, couldn't we simply git pull the appropriate branch from their clone?


The hosting is important otherwise we're going to have to figure out how to host this stuff in a "neutral" way.
You've missed a few important considerations.

How important is vendor neutrality?

I would say this is pretty important for this project.


How important is intellectual property management? Do the developers like doing their own intellectual property management, or would it be helpful to have a dedicated team who can do this on their behalf?

I think the more help we could have on this the better :)

Wayne
--
Wayne Beaton
Director of Open Source Projects
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse Projects
EclipseCon
            2013
--
 
 

Re: [vertx:6024] Discussion: The future of the Vert.x project Tim Fox 1/14/13 12:15 AM
I'd also be very interested in hearing the answers to the same questions, but about the ASF, from an ASF person, so we can compare and contrast.
Re: [vertx:6024] Discussion: The future of the Vert.x project Pid 1/14/13 12:52 AM
A few things spring to mind: running the test suite on various OS,
integration testing with modules that depend on external services (e.g.
MongoDB), automating release procedures, etc.

I can probably think of a few more.


p
> Explore Eclipse Projects <http://www.eclipse.org/projects>
> EclipseCon 2013 <http://www.eclipsecon.org/2013>
>
> --
>  
>  


--

[key:62590808]

Re: Discussion: The future of the Vert.x project Henry Saputra 1/14/13 4:49 AM
Would love to have option #1 with ASF. Like many others have commented seems like ASF with community driven approach should work for vert.x.

I am also PMC members to couple ASF projects and could help moving the project in the incubation project.

Thx,

- Henry

Re: [vertx:6015] Discussion: The future of the Vert.x project Mike Milinkovich 1/14/13 8:00 AM
 For the reasons that Wayne Beaton mentioned, a classic github pull request to a git repo at Eclipse is not supported. However, I think what you're saying here is that what you really want is a path whereby a github user can have their contribution brought to an your project. This we can do. The best way to have this happen would be for the project to use gerrit. Then github users would push to the the gerrit instance and to have it reviewed and accepted by a project committer. I'm not sure if you've used gerrit, but it works pretty well.

On the CI front, I noticed that you've assumed that the CI must happen elsewhere. If you choose to, you can host your CI and builds at eclipse.org. That has the added advantage that if you're using gerrit, you can have contributions built automatically as they come in, and committers only need to spend time reviewing code that actually builds.

Re: [vertx:6024] Discussion: The future of the Vert.x project Mike Milinkovich 1/14/13 8:43 AM


On Monday, January 14, 2013 3:13:27 AM UTC-5, Tim Fox wrote:
b) Hosting for issue tracker. JIRA preferred. Don't like bugzilla.

We use Bugzilla. Our policy of vendor neutrality prevents us from using commercial products like JIRA. Even if they do give us a free license. All of our services a based on open source software.

Do you also explicit forbid projects from creating accounts external to the eclipse infrastructure for project stuff, i.e. could the project use an external JIRA?


In general, any piece of infrastructure that is involved in tracking the provenance of intellectual property we want hosted at eclipse.org

We have been asked this JIRA question many times, and as much as I wish the answer was "yes", we cannot use it as long as it is not open source. We don't want the Eclipse Foundation to be implicitly endorsing a vendor product.

For those who use Eclipse as their tool, the Mylyn UI into bugzilla gives you a quite different experience. Just like the reason CVS was able to last at Eclipse for a very long time because of great tools, a lot of folks working on Eclipse projects rely on Mylyn when they're dealing with bugzilla.

It is not that we are stuck on bugzilla for religious reasons. The fact is that we have never been able to find an open source issue tracker that scales as well as bugzilla does. We have almost 400K bugs in our system at the moment. 

If anyone has any suggestions, we could look at them in the future. A couple of years ago I firmly believed that moving the entire Eclipse community off of CVS and onto git was basically impossible. I am not going to make that mistake again. One interesting potential is the code2cloud project which provides a modern web ui on top of the existing bugzilla UI. (See http://code2cloud.org)


Re: [vertx:6024] Discussion: The future of the Vert.x project Mike Milinkovich 1/14/13 9:37 AM


On Monday, January 14, 2013 3:13:27 AM UTC-5, Tim Fox wrote:
f) Hosting for public module repository - in Vert.x 2.0 this is likely to be a Maven repository.

Anything that is distributed by a project from any eclipse.org property is subject to our IP policy. Hosting a Maven repository that provides IP cleared artefacts is certainly possible. We are currently working on building a centralized Maven repository for Eclipse project (and vetted third party libraries).

This is a tricky one. We want to host a repo that contains Vert.x modules - most of these would be from 3rd parties (not created by Vert.x project). I guess you could think of it as like the npm repository in the node.js world, or a "Maven central" for Vert.x

Like Maven central, each user of a repository would have their own account and would manage the modules that they wish to publish. Note that it's them that's publishing stuff not the Vert.x project. We feel that having such a module repo is essential for a healthy vert.x module ecosystem.

Having to centrally administer such a repository and IP vet everything wouldn't scale.

If Eclipse wouldn't want to _host_ such a repository, would you object to it existing externally to the eclipse infrastructure?

There are several projects at Eclipse that host independent third party module repositories, and I am comfortable that there is nothing in vert.x that would prevent that from happening. So I don't see a problem with having a vert.x module repository created elsewhere.

What we care about is whether those modules are truly optional. If, for example, vert.x won't load or run without a particular module, then we treat those differently. Basically, all of the components necessary for the project to actually run need to be included, or declared as a prerequisite. But if you want to create an ecosystem of modules (or extensions) that add value on top, then I do not see that as a problem at all.

If you wanted to host such a repository at eclipse.org, we could talk about it, but given our IP regime it might be tough. But I honestly don't think that is either necessary or what you're asking for.

Another possibility would be to emulate the Eclipse Marketplace[1] which provides a user-friendly catalogue of modules, but where the bits are actually hosted by their providers. In fact, Marketplace pretty much works exactly as you've described, except it doesn't assume that the modules are all stored in one place. We host the metadata, but not the bits. In the simplest case, we could simply create a vert.x market on Eclipse Marketplace and manage it exactly how we do the existing Eclipse plug-in ecosystem.

Hope that helps.

Re: [vertx:5886] Discussion: The future of the Vert.x project J Arthorn 1/14/13 10:49 AM
I just wanted to give some perspective on the Eclipse process from a committer and project lead's point of view. I handle all matters of process for the Eclipse platform, and I've done it for other Eclipse projects of various sizes in the past. I'm also a committer and spend much of my time coding and reviewing patches. Most of the above document is just definitions of projects, committers, leads, etc, and doesn't result in noticeable overhead. So that your community makes a decision with clear eyes, I can outline the aspects of Eclipse dev process that actually do create work for project leads and committers (from my personal experience):

1) Proposing a new project at Eclipse. This involves some real work in drafting a proposal, defining the project scope and initial committers. There is then a creation review, although the main test here is to show that it's not just a dump of unwanted code and there is intent to continue developing. In your case this is a non-issue and as long as you and VMWare are onside this step should be easy. Project mentors can help with a lot with guiding you through it. This is all a "once only" exercise.

2) IP Process. Any code not written by a committer that you want to include or have non-optional dependency on requires IP review. The nice part is that the Eclipse Foundation staff do most of the work here, but you need to submit them and await review. The main issues are license compatibility and provenance (someone needs to have a clue who wrote the code and whether they had the right to contribute it). Overall I would say the IP process doesn't create much work for committers, but it can be a barrier if you absolutely require some code that has unknown provenance or incompatible license. On the other hand if you are interested in large scale commercial adoption having gone through this process (and having EF doing much of the work) is a huge value to your project.

3) Release reviews. Every time you release you need to put some words together describing what's new in your release, and a short summary of the state of the project. For me as a project lead this is the only real process step that requires regular ongoing work (especially for a web project that releases often). On the other hand I think this material is valuable information for consumers and although I'd rather be coding I realize there is a tangible benefit to the project in writing this. Despite the name, there is really no formal "review" that happens. There is a period where the community can voice objections or concerns with the release but I don't think this has actually ever happened at Eclipse. To get an idea what the release material looks like, here is an example from JGit: http://dev.eclipse.org/mhonarc/lists/technology-pmc/pdfoBVfSdYA7e.pdf

Anyway, that was a bit more long-winded than I intended, but wanted to give a committer POV perspective on what Eclipse dev process is like to live with. Other committers' experience may vary. I hope you find that helpful and I wish your community all the best with making the decision.

John Arthorne

On Thursday, January 10, 2013 1:43:28 PM UTC-5, Tim Fox wrote:
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 :(

On Thursday, 10 January 2013 15:41:15 UTC, Mark Little wrote:
My preference is certainly a foundation, and of the ones mentioned so far, Eclipse is my favourite.

Mark.


On 10 Jan 2013, at 14:40, Mike Milinkovich wrote:

> 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 :)
>
> --
>  
>  

Re: [vertx:5990] Discussion: The future of the Vert.x project Paula Hunter 1/14/13 11:42 AM
Tim, since most of that is covered on GitHub, why would you need to change at all?
Re: [vertx:6050] Discussion: The future of the Vert.x project Tim Fox 1/14/13 12:11 PM
Hi Paula,

My reasoning here is that if we want the project to be completely neutral and not favour any particular company or individual then github is tricky since who gets to be the owner of the github resources?

We either have to choose one person to do that - and that can introduce a bias to an individual or company. Or maybe we share ownership, but that doesn't protect against one owner going rogue and deleting the other owners or doing damage to the repo or other resources.

Admittedly it's unlikely to happen, but it could.

So in my mind, a better solution would be to let the foundation handle the administration of the project resources (repo, tracker etc)


On 14/01/13 19:42, Paula Hunter wrote:
Tim, since most of that is covered on GitHub, why would you need to change at all?

On Sunday, January 13, 2013 4:22:30 AM UTC-5, Tim Fox wrote:
IMO, any neutral foundation we go with should provide

a) Hosting for git repository, mirrorable to the _current_ project at github. Please no svn, cvs or mercurial
b) Hosting for issue tracker. JIRA preferred. Don't like bugzilla.
c) Hosting for mailing lists�
d) Hosted for project web site
e) Hosting for downloads
f) Hosting for public module repository - in Vert.x 2.0 this is likely to be a Maven repository.
g) Ability to use external CI, e.g. CloudBees or Travis
h) Can accept pull requests via github

The hosting is important otherwise we're going to have to figure out how to host this stuff in a "neutral" way.

On Friday, 11 January 2013 22:25:15 UTC, Pid wrote:


On 11 Jan 2013, at 21:37, Joern Bernhardt <joern.b...@googlemail.com> wrote:

On Friday, January 11, 2013 9:53:04 PM UTC+1, blalor wrote:
On Jan 11, 2013, at 3:37 PM, bytor99999 <bytor...@gmail.com> wrote:

Basically, I would be happy with either. There are definitely pros and cons to either one. Of course, the cons list on both sides seem pretty small.

The loss of the ability to use GitHub is a pretty major one, unfortunately. �Pull Requests == the way of the future. �Whatever it takes to keep on keepin' on, tho�

I just hope we get a good issue tracker, which doesn't look like it's from the 90's and allows to search and categorize issues easy. GH was okay in that regard. A roadmap and/or forum would be nice, too. Searching the mailing list to find information about feature X almost never works well.

Perhaps now would be a good time to find out if people have a wish list as well as thinking about the more pressing concerns. Seems like we have a great opportunity to talk about the future.


p



--
�
�

Re: [vertx:6050] Discussion: The future of the Vert.x project Stephen Walli 1/14/13 1:58 PM
Hi Tim:  I'm technical director at the Outercurve Foundation.  There are lots of concerns with the number of projects that are "open source" on Github without a license of any kind.  Mike Milinkovich and I, Simon Phipps, and Mark Radcliffe have all blogged/commented publicly about this very messy problem.  (My comments are here: http://opensource.com/law/12/9/declare-software-license)

That isn't an issue in this case or for a project on any forge with a declared [OSI-approved] license. The neutrality of ownership of the project lies with the foundation, not the forge.  If you assign the copyright of the project to the Apache Software Foundation, the Eclipse Foundation, or the Outercurve Foundation, then the foundation is the neutral non-profit owner of the software.  This is regardless of where the software repositories exist -- they could be on any forge. 

With respect to rogue players, a project's committers (i.e. people with write access on the primary repositories) have the authority and responsibility for the source repositories and enabling new committers.  This again is regardless of forge OR foundation.  For example, Outercurve project communities have their respective projects on Github,  Microsoft's codeplex.com, launchpad, and a few university backed sites (to name a few off the top of my head).   Project's govern themselves, and mature projects have mature processes in place for allowing new committers write access to a project's repositories.  Just because anyone can read a project's repositories at the ASF (foundation) OR Github (forge) doesn't mean they have write access to them. 

Does this make sense?
cheers, stephe
Re: [vertx:6014] Discussion: The future of the Vert.x project Bradley M. Kuhn 1/14/13 3:12 PM
Upon reading Tim's email about what he's looking for, I think it's
useful to point out again that there are some key differences between
the types of fiscal sponsors available, on many spectra.  My previous
email discussed the (c)(6)/(c)(3) differences.  Below, I talk about how
Conservancy differs on the issue of what services are provided to its
projects.

Tim Fox wrote at 04:22 (EST) on Sunday:
> IMO, any neutral foundation we go with should provide: [a list of
> technological infrastructure items]

Conservancy actually doesn't directly provide the services Tim listed,
but rather *helps* its projects find/fundraise to get those services
from elsewhere.  That was by explicit plan of Conservancy.

Specifically, Conservancy just never had new potential member projects
approaching us who didn't have any hosting services set up yet.  Hosting
services are widely available -- separate from the non-profit home of
the project (e.g., OSU-OSL, as an example, is another non-profit that
focuses on just the issue of providing technological infrastructure to
Free Software projects).  Conservancy couldn't possibly offer hosting
services that would be better than those that were already available.
Conservancy thus never built any hosting for our projects.  In fact,
nearly all our projects "show up" as Conservancy applicants with
existing, preferred hosting solutions for the "usual stuff" already
configured and in-place.  (Vert.x, frankly, seems similar in that regard.)

You'll thus find Conservancy projects using all sorts of different code
hosting, CI systems, mailing list hosting, bug tracking, and the like.
Conservancy does often help our projects *get* these services.  For
example, we work with our projects often to get VPS-hosting donated to
the project.  Thus, while infrastructure is almost always provided by a
third-party, Conservancy will help find those third-parties, try to get
the services donated, and then help raise money to pay for the services
if an in-kind donation isn't possible.

In essence, the services that Conservancy offers relate to things that
aren't technological, but are at the meta-level of Free Software project
management.  (A full list of Conservancy's services is here:
http://sfconservancy.org/members/services/ ) In short, our goal has
always been to do those things that a project can't get anywhere else
but from their non-profit home.

Thus, if the Vert.x project wants to keep its infrastructure roughly as
it is (i.e., code on GitHub, mailing list here, etc.), but *does* need
everything else that a non-profits can provide (e.g., trademark
stewardship, holding donations and assets for the project in an
earmarked account), Conservancy might be a good choice, since the latter
types of items are Conservancy's focus.

BTW, Conservancy doesn't believe in a one-size-fits-all policy for *any*
of these issues.  Conservancy seeks to negotiate with a projects'
leaders with regard to copyright, trademark, and CLA policies.  Our goal
is to help projects understand the risks of certain policies and help
them decide where the right trade-offs are (and that decision can be
very different for different projects).  For example, many Conservancy
projects believe that strict copyright, trademark, and/or licensing
policies can negatively impact the ability of the project to get
volunteer contributions, so we seek to build specific policies for each
project that fit their culture.

Tim asked at 15:11 (EST) today:
> My reasoning here is that if we want the project to be completely
> neutral and not favour any particular company or individual then
> github is tricky since who gets to be the owner of the github
> resources?
...
> We either have to choose one person to do that - and that can
> introduce a bias to an individual or company.

FWIW, many Conservancy projects have used GitHub and have been able to
stay neutral.  If it's a question of who legally is in control of the
master GitHub account for the project, the non-profit home could simply
be the legal authority who is in control of the account, and then
authorize various volunteers to act on the project's behalf with regard
to accepting pull requests and the like.

IIUC, on GitHub, some entities chose to make an "organizational" account
and then have employees who have actual personal GitHub accounts to do
the day-to-day work and are associated with that organizational account.
No Conservancy project on GitHub has ever asked us before to set up an
organizational account, but I don't see any reason Conservancy couldn't
do that, and then member projects could exist under that organizational
account.  That would be YA way to gain neutrality using GitHub.
--
Bradley M. Kuhn, Executive Director, Software Freedom Conservancy
Re: [vertx:5958] Re: Discussion: The future of the Vert.x project Tim Fox 1/15/13 2:03 AM
On 11/01/13 17:52, Alexis Richardson wrote:
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.

I'm not really sure how these things work, but I guess that the main piece of work involved in being accepted (or not) by a foundation is for the IP of the project to be reviewed, i.e. check all the contributions (?)

I wonder if the different foundations could give a (very) rough estimate of how long the acceptance process would take? Are we talking a few months or a few months here?

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

For the "full-service" foundations (i.e. ASF and Eclipse) my personal bias is towards Eclipse too. I like everything in ASF apart from the voting process and the weaker notion of leadership. I like Eclipse but I'm still put off by the stricter process. All in all, between the two, Eclipse has the edge for me.

 That said, I think the ASF folks have also been very impressive. 

+1

I am less clear about the other foundations,

Until this morning I was quite strongly aligning behind a recommendation for Eclipse - this was based on my assumption that we'd really need a "full service" (i.e. repo, tracker, etc hosted by the foundation).

However, after reading Stephen Walli and Bradley Kuhn's most recent posts on this thread, this has made me think again that perhaps just a minimal foundation approach (i.e. just holding the IP) would be better for Vert.x. This would allow the project to continue almost exactly as-is, i.e. stay on github and the google group. This might be a lot less disruptive for Vert.x

I'd like to hear a little more about VMware's view on that. Is this still in the running from VMware's point of view?

which should not be interpreted as a negative.

alexis




 

alexis




On Friday, January 11, 2013 4:11:49 PM UTC, Tim Fox wrote:
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).

On Thursday, 10 January 2013 09:58:38 UTC, Tim Fox wrote:
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.

--
 
 

--
 
 

Re: [vertx:5958] Re: Discussion: The future of the Vert.x project Jim Jagielski 1/15/13 4:41 AM
Tim, as  Paula and Stephen noted, I'm also on the Board of Outercurve and I think that Outercurve would also be a good fit for virt.x. As you say, you get to continue with the existing "infrastructure" setup, but have the protection of a foundation with minimal overhead, which sounds to be exactly what you want. And I can assure VMware that it is a "real" foundation and can (and will) provide the neutrality they are looking for.
Re: [vertx:5958] Re: Discussion: The future of the Vert.x project Alexis Richardson 1/15/13 5:03 AM
Tim,

> This would allow the project to continue almost exactly as-is, i.e. stay on
> github and the google group. This might be a lot less disruptive for Vert.x

Is the issue here how the GH org and the Google Group are structured?  I believe we can resolve that.


> I'd like to hear a little more about VMware's view on that. Is this still in
> the running from VMware's point of view?

We'd need look into the details for the newer foundations.  ASF and Eclipse embody years of good practice and make us feel a lot more comfortable that vert.x can grow as a project.  ISTM that the newer guys may be a bit ahead of the curve in terms of 'hot features', but we need to understand the whole picture to feel completely happy.

So, initially, given your comments on Eclipse, I would like to understand how far we can push the envelope with the use of the existing GH and Google accounts in an Eclipse context.

alexis
Re: [vertx:6062] Re: Discussion: The future of the Vert.x project Tim Fox 1/15/13 5:27 AM
On 15/01/13 13:03, Alexis Richardson wrote:
Tim,

> I'd like to hear a little more about VMware's view on that. Is this still in
> the running from VMware's point of view?

We'd need look into the details for the newer foundations.  ASF and Eclipse embody years of good practice and make us feel a lot more comfortable that vert.x can grow as a project.  ISTM that the newer guys may be a bit ahead of the curve in terms of 'hot features', but we need to understand the whole picture to feel completely happy.

Aiui, SC/OuterCurve basically are a way of resolving the current IP issues with Vert.x, but don't say much about the way the project is run on a day to day basis and don't mandate any particular hosting infrastructure.

I think the argument is, if we accept that the issue with Vert.x right now revolves around IP and is not an issue on how the project is run day-to-day and we're pretty happy with github and google groups, then it might be more appropriate to do the minimum to resolve the current problem which would be to go with a "minimal" foundation.



So, initially, given your comments on Eclipse, I would like to understand how far we can push the envelope with the use of the existing GH and Google accounts in an Eclipse context.

Aiui, with Eclipse, you can use the github project as a mirror to the main git repo which is hosted by eclipse, but wouldn't be able to use the github issue tracker, and wouldn't be able to use the google group as this would all have to move to an eclipse hosted solution.
--
 
 

Re: [vertx:6062] Re: Discussion: The future of the Vert.x project Jim Jagielski 1/15/13 5:53 AM
The other thing is that Outercurve would also provide guidance and insight on how to build the community... Outercurve has a number of community experts associated with it, including Jono Bacon, Dave Neary, Leslie Hawthorn, etc... (and me :) ).

So Outercurve allows no discontinuity in process, but IP protection, neutrality and expertise when needed.


On Tuesday, January 15, 2013 8:27:22 AM UTC-5, Tim Fox wrote:

I think the argument is, if we accept that the issue with Vert.x right now revolves around IP and is not an issue on how the project is run day-to-day and we're pretty happy with github and google groups, then it might be more appropriate to do the minimum to resolve the current problem which would be to go with a "minimal" foundation.


Re: [vertx:6055] Discussion: The future of the Vert.x project Mark Little 1/15/13 5:56 AM
I'm deliberately trying to stay out of this as much as possible, in order to allow for a vendor neutral decision to be made. However, taking my Red Hat/JBoss hat off and trying to be objective, I continue to believe that Eclipse offers a good route for vert.x based on the experiences we've had working in it. ASF works too, but I feel that in this case Eclipse would be better.

In terms of the other foundations, I don't think anyone in JBoss has sufficient experience to say whether they would or wouldn't be appropriate. But that in itself makes me worried: maybe they are a little bit too new.

Mark.


On 15 Jan 2013, at 10:03, Tim Fox wrote:

Until this morning I was quite strongly aligning behind a recommendation for Eclipse - this was based on my assumption that we'd really need a "full service" (i.e. repo, tracker, etc hosted by the foundation).

However, after reading Stephen Walli and Bradley Kuhn's most recent posts on this thread, this has made me think again that perhaps just a minimal foundation approach (i.e. just holding the IP) would be better for Vert.x. This would allow the project to continue almost exactly as-is, i.e. stay on github and the google group. This might be a lot less disruptive for Vert.x

Re: [vertx:6062] Re: Discussion: The future of the Vert.x project Alexis Richardson 1/15/13 5:57 AM
Tim,


On Tuesday, January 15, 2013 1:27:22 PM UTC, Tim Fox wrote:
Aiui, with Eclipse, you can use the github project as a mirror to the main git repo which is hosted by eclipse, but wouldn't be able to use the github issue tracker, and wouldn't be able to use the google group as this would all have to move to an eclipse hosted solution.

Please can we drill into the scope of this a bit more with Mike M?  

alexis
Re: [vertx:6055] Discussion: The future of the Vert.x project Jim Jagielski 1/15/13 6:02 AM
Why is this a JBoss concern at all?
Re: [vertx:6067] Discussion: The future of the Vert.x project Pid 1/15/13 6:37 AM
On 15/01/2013 14:02, Jim Jagielski wrote:
> Why is this a JBoss concern at all?

Source of other people in close proximity to Mark who he can talk to
about it?


p


> On Tuesday, January 15, 2013 8:56:59 AM UTC-5, Mark Little wrote:
>
>
>     In terms of the other foundations, I don't think anyone in JBoss has
>     sufficient experience to say whether they would or wouldn't be
>     appropriate. But that in itself makes me worried: maybe they are a
>     little bit too new.
>
>
> --
>  
>  


--

[key:62590808]

Re: [vertx:6062] Re: Discussion: The future of the Vert.x project Ian Skerrett 1/15/13 6:38 AM


On Tuesday, January 15, 2013 8:27:22 AM UTC-5, Tim Fox wrote:
On 15/01/13 13:03, Alexis Richardson wrote:
Tim,

> I'd like to hear a little more about VMware's view on that. Is this still in
> the running from VMware's point of view?

We'd need look into the details for the newer foundations.  ASF and Eclipse embody years of good practice and make us feel a lot more comfortable that vert.x can grow as a project.  ISTM that the newer guys may be a bit ahead of the curve in terms of 'hot features', but we need to understand the whole picture to feel completely happy.

Aiui, SC/OuterCurve basically are a way of resolving the current IP issues with Vert.x, but don't say much about the way the project is run on a day to day basis and don't mandate any particular hosting infrastructure.

I think the argument is, if we accept that the issue with Vert.x right now revolves around IP and is not an issue on how the project is run day-to-day and we're pretty happy with github and google groups, then it might be more appropriate to do the minimum to resolve the current problem which would be to go with a "minimal" foundation.


One thing to keep in mind is the governance around the IP issues. How you do CLAs or licensing, who makes decision on trademark usage, how are new committers granted access to the repo or revoked access to the repo, etc.  As Kohsuke pointed out in a previous post, these are things you will eventually need to figure out. You might not need them at this moment but over time they will be issues that need to be resolved.  Apache and Eclipse have their own set of governance policies that have evolved out of many years of experience.

So, initially, given your comments on Eclipse, I would like to understand how far we can push the envelope with the use of the existing GH and Google accounts in an Eclipse context.

Aiui, with Eclipse, you can use the github project as a mirror to the main git repo which is hosted by eclipse, but wouldn't be able to use the github issue tracker, and wouldn't be able to use the google group as this would all have to move to an eclipse hosted solution.

This is correct.

FWIW, I work at the Eclipse Foundation.

 
Re: [vertx:6067] Discussion: The future of the Vert.x project Mark Little 1/15/13 6:40 AM
It is not. I meant that there is no experience of these groups within JBoss so I cannot ask people what they think from working in them/with them. Experience counts. And we have a lot of experience with Eclipse and ASF, both within JBoss and the larger Red Hat organisation.

Mark.


--
 
 

Re: [vertx:6067] Discussion: The future of the Vert.x project Mark Little 1/15/13 6:40 AM
+1
Re: [vertx:6067] Discussion: The future of the Vert.x project Jim Jagielski 1/15/13 6:45 AM
I had thought that it was a community decision and that the discussions were being done here, on-list and in-public.
Re: [vertx:6072] Discussion: The future of the Vert.x project Mark Little 1/15/13 6:53 AM
Jim, we're looking for fact based decisions, not emotional knee-jerk reactions. If people in JBoss, Red Hat, VMWare, or anywhere else have real world experiences with any of these organisations, then I think it would be good for them to be brought to this discussion in order for everyone to understand the pros and cons. Whilst it is great for the people behind these foundations to come and say what they can about how they work, ultimately it is the developers of the projects who can really shine a light on what works and what doesn't work.

Mark.


--
 
 

Re: [vertx:6072] Discussion: The future of the Vert.x project Jim Jagielski 1/15/13 7:13 AM
Agreed. So far, I've not seen any "emotional knee-jerk" reactions, which is great.

My point is that, imo at least, it is unfortunate and unwise to disregard potential foundations simply because JBoss lacks experience with them. The world of FOSS foundations is much larger. However, fwiw, Red Hat does have experience w/ Outercurve since, as I indicated, myself, Dave Neary and Leslie Hawthorn are associated with them.

However, I've tried to avoid any reference to my status as a Red Hat employee because I don't want to muddy the waters and reinforce the growing impression that Red Hat is "directing" directions for virt.x (which, of course, is totally bogus). 
Re: [vertx:6074] Discussion: The future of the Vert.x project Mark Little 1/15/13 7:34 AM
Jim, I think it would be better for this discussion in you stopped reading more into things that was intended or given. This is not a Red Hat or JBoss driven decision and if you think I've said that then you need to show where that occurred. As I and others have pointed out, the reference to JBoss was made solely in terms of where we might have some experience in these foundations that we can share with others in the vert.x community who may not have that experience. In the case of SC and OuterCurve, that experience does not exist within JBoss, whereas we have plenty of experience with Eclipse and ASF.

Hopefully I do not have to state the same thing again in yet another way for you to understand.

Mark.


--
 
 

Re: [vertx:6062] Re: Discussion: The future of the Vert.x project Alexis Richardson 1/15/13 7:41 AM
Ian,


On Tuesday, January 15, 2013 2:38:45 PM UTC, Ian Skerrett wrote:

Aiui, SC/OuterCurve basically are a way of resolving the current IP issues with Vert.x, but don't say much about the way the project is run on a day to day basis and don't mandate any particular hosting infrastructure.

I think the argument is, if we accept that the issue with Vert.x right now revolves around IP and is not an issue on how the project is run day-to-day and we're pretty happy with github and google groups, then it might be more appropriate to do the minimum to resolve the current problem which would be to go with a "minimal" foundation.


One thing to keep in mind is the governance around the IP issues. How you do CLAs or licensing, who makes decision on trademark usage, how are new committers granted access to the repo or revoked access to the repo, etc.  As Kohsuke pointed out in a previous post, these are things you will eventually need to figure out. You might not need them at this moment but over time they will be issues that need to be resolved.  Apache and Eclipse have their own set of governance policies that have evolved out of many years of experience.

This is a good summary of where I think ASF and Eclipse have the edge over the new foundations on the block.  Of the two, I feel Eclipse gives the stronger continuity around project leadership which I like because it puts Tim in the driving seat.  However (see below).
 

So, initially, given your comments on Eclipse, I would like to understand how far we can push the envelope with the use of the existing GH and Google accounts in an Eclipse context.

Aiui, with Eclipse, you can use the github project as a mirror to the main git repo which is hosted by eclipse, but wouldn't be able to use the github issue tracker, and wouldn't be able to use the google group as this would all have to move to an eclipse hosted solution.

This is correct.

OK, so I agree with Tim when he indicates (AIUI) that the existing GH and GG services are somewhat integral.  How can we bridge this gap?  I don't believe this is a completely unsolvable problem.  Ian / Mike - over to you!

alexis
Re: [vertx:6072] Discussion: The future of the Vert.x project Tim Fox 1/15/13 7:44 AM
I'd just like to say, that everyone from RHT that I have talked to have been very careful not to direct any recommendation that I make to the community.
--
 
 

Re: [vertx:6074] Discussion: The future of the Vert.x project Jim Jagielski 1/15/13 7:59 AM
Umm, methinks you are being overly-sensitive. *I* did not say it (driving decision); others are. This should have been quite obvious when I admitted that the idea was bogus.

Hopefully I do not have to state the same thing again in yet another way for you to understand. *lol*!
Re: [vertx:6055] Re: Discussion: The future of the Vert.x project Wayne Beaton 1/15/13 8:11 AM
Community development and growing diversity within a project are very important at Eclipse. You'll notice that most of our development process is derived from the open source rules of engagement: transparency, openness, and meritocracy. I wrote about our take on this in my blog a few months ago [1].


On 01/15/2013 05:03 AM, Tim Fox wrote:
I'm not really sure how these things work, but I guess that the main piece of work involved in being accepted (or not) by a foundation is for the IP of the project to be reviewed, i.e. check all the contributions (?)

I wonder if the different foundations could give a (very) rough estimate of how long the acceptance process would take? Are we talking a few months or a few months here?


Project creation at Eclipse starts with a proposal. A proposal details information about the project, including a description and scope. Getting the scope right is pretty important as it provides a framework for the project. Proposals also describe the existing code base, provide a list of developers, identify the project leads, etc. It can take a couple of days to get the proposal just right (I provide assistance).

Once the proposal has been prepared, we post it for community review for a minimum of two weeks. During that two weeks, members of the Eclipse community will ask questions about the proposal, ask to be added as "interested parties", and generally provide input. Some members of the community may step forward to volunteer to join the project. Whether or not you choose to add a volunteer as a project committer is up to you (this almost never happens as it is generally the case that most project proposers have already included everybody with the necessary skills and background).

During these two weeks, I help the project identify two mentors from our Architecture Council (AC). The AC mentors are required to provide assistance with the Eclipse Development Process for new projects. They don't participate in the project directly, and--despite the name--don't push architectural decisions on a project. AC mentors don't interfere with actual development. They answer questions and generally pay attention to the project to make sure that they don't get hung up on process.

As an aside: the processes aren't particularly onerous. Within the framework of the open source rules of engagement, we always strive to do the Right Thing. If you're not sure, ask.

The proposal period can run longer than two weeks. It's really up to the project to decide when they're ready to create.

The minimum-of-two-weeks proposal period ends with a creation review. A creation review runs for a full week. It's like a notice to the community that we're serious and ready to go. Kind of a "get you last comments/concerns in now" sort of deal. After a week of creation review, we declare success and start provisioning.

Provisioning of project resources (website, source repositories, downloads directories, mailing lists, forums, etc.) takes  couple of days.

While resources are being provisioned, we also provision developers (committers). This involves some paperwork as we need to ensure that committers are, for example, participating with the permission of their employers. Both VMWare and Red Hat have organization paperwork in place, so getting their employees started will happen pretty quickly.

Once we have provisioned resources and developers, we do an IP review of the project's code. The initial contribution to the project must be reviewed by our IP team before it can be committed and pushed. The initial review is generally complete within a couple of days using something that we call Parallel IP. The initial review is pretty high level: the IP team checks for general license compatibility of the contribution and then does a much more detailed IP review on the code. If they find problematic code, they'll bring it to your attention. In some cases, projects are required to remove code (e.g. if the provenance cannot be determined).

Bottom line: you can be off to the races in about four weeks.

Note that the scope, structure, and other aspects of a project can be changed easily. Most changes do require community review.

HTH,

Wayne

[1] http://waynebeaton.wordpress.com/2012/01/13/open-source-rules-of-engagement/
--
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse Projects
EclipseCon
          2013
Re: [vertx:6082] Re: Discussion: The future of the Vert.x project Tim Fox 1/15/13 8:24 AM
Thanks Wayne,

A couple more questions sprung to mind:

1. Does eclipse ever try to influence technical direction of projects? E.g. "We'd really like it if you used OSGI more...", or stuff like that.
2. Would vert.x go into incubation first? If so, how long does incubation typically take?
--
 
 

Re: [vertx:6082] Discussion: The future of the Vert.x project Mark Little 1/15/13 8:26 AM
Jim, I can't really speak to whether other people believe this decision is being driven by JBoss unless they want to raise them to me directly, and certainly references like that by you are just stoking the conspiracy theories. I certainly won't react through a proxy to them either. However, your email continues to show a misunderstanding "unwise to disregard potential foundations simply because JBoss lacks experience with them" of what I had wrote concerning these other foundations which I don't think anyone else, particularly Tim, took from what I said. And if you re-read the email, you'll see that I went to great lengths to stress that this was my opinion and not some official opinion on behalf of Red Hat! So let's stick to the facts and take any further to-and-fro off list. You know how to contact me if you want to do that, but further conversation on this list and thread is not advancing the topic.

Thanks for your understanding!

Mark.


--
 
 

Re: [vertx:6055] Discussion: The future of the Vert.x project Paula Hunter 1/15/13 8:32 AM
Understood about the concern of "newness" Mark, but that is exactly why we have cultivated the most experienced board members, lawyers, mentors, and staff to form our organization (including reps from other .orgs).   While we are new relative to Apache and Eclipse, we certainly are leveraging best practices within the OSS world and the non-profit sector.


On Tuesday, January 15, 2013 8:56:59 AM UTC-5, Mark Little wrote:
Re: [vertx:6084] Re: Discussion: The future of the Vert.x project Wayne Beaton 1/15/13 8:54 AM


On 01/15/2013 11:24 AM, Tim Fox wrote:
Thanks Wayne,

A couple more questions sprung to mind:

1. Does eclipse ever try to influence technical direction of projects? E.g. "We'd really like it if you used OSGI more...", or stuff like that.
No. That's the community's job. :-)

2. Would vert.x go into incubation first? If so, how long does incubation typically take?

Yes. How long depends on the project. For mature projects joining Eclipse, the incubation process is pretty short. I recommend that mature projects do an incubation release as soon as they get their code in, builds running, etc. (on the order of six to eight weeks after creation) to get a feel for the processes and then graduate out of incubation with their next release six to eight weeks later. How long this actually takes depends on the complexity of the IP due diligence, and your motivation. Whether you do zero, one, two, or more incubation releases is really up to you.

The WindowBuilder project went from incubation to graduation release in couple of months, for example. That was a huge, mature code base.

Unfortunately, "typical" is hard to define. We have proposals that have been in the "community review" state for months waiting for the proposers to decide that it's time to create. We have projects that have been in incubation for a couple of years that ask me to let them stay "just a bit longer" when I press them for graduation plans.

It takes all kinds :-)

BTW, I am the Director of Open Source Projects at the Eclipse Foundation. My role is to help make projects and committers successful.

Wayne


--
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse Projects
EclipseCon
          2013
Re: [vertx:6080] Re: Discussion: The future of the Vert.x project Wayne Beaton 1/15/13 9:04 AM
On 01/15/2013 10:41 AM, Alexis Richardson wrote:
 
OK, so I agree with Tim when he indicates (AIUI) that the existing GH and GG services are somewhat integral.  How can we bridge this gap?  I don't believe this is a completely unsolvable problem.  Ian / Mike - over to you!

An Eclipse project generally has an eclipse.org "dev list" that's used for developer (i.e. committer) communication and then other forums (including eclipse.org and external resources) for community interaction. The benefit of using the eclipse.org resource is that we have control over it and aren't dependent on an external entity's continue benevolence. This is an important consideration when you look at things like very long term support.

That said, a lot of our projects use communication resources that are not within our management. IRC is heavily used. A lot of the Eclipse community gathers around Stack Overflow. Communicating in Google Groups is fine. The one problematic thing with "outside" communication is that you have to be extra careful about accepting intellectual property as participating individuals may not have agreed to the terms of use.

Ultimately a successful open source project needs to communicate with their community and the community has a big say in where that communication occurs.

We have a well defined process for working with outside services like GitHub. The eclipse.org-based repository has to be the "central" repository, but the repo can be cloned anywhere. As I've stated previously, we GitHub and Google Source currently mirror our repositories automatically. Others are free to do this as well. You are also free to mirror/clone your repository in other places.

Contributions (e.g. GitHub pull requests) need to be taken through our IP process. It's not particularly hard, it just means that we can't generally accept pull requests as-is; we need to be able to reasonably assert the identity of the contributor and have an explicit declaration about the terms of the contribution (i.e. that they authored 100% of the content, have permission to make the contribution, do so under compatible licensing terms). Some modification of the commit record is generally required.

Mike mentioned Gerrit. Gerrit is available for use by Eclipse projects who want it. It's one  of our first class services. With Gerrit, anybody can push a commit where it can be reviewed and processed by the project committers. Gerrit makes it very easy to get the IP flows right, and is pretty compelling piece of our evolving CI story. We have a few projects doing CI today with Gerrit: when somebody pushes a commit to Gerrit, it kicks off the build including that contribution. The build reports back with a vote on whether or not to accept the contribution (i.e. a committer will already know if the contribution compiles/tests before they even look at it).

HTH,


Wayne

--
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse Projects
EclipseCon
          2013
Re: [vertx:6087] Discussion: The future of the Vert.x project Mark Little 1/15/13 9:11 AM
Understood and it's good to hear. And at some point if these new foundations are to be successful people need to give them a try.

Mark.


--
 
 

Re: [vertx:6082] Discussion: The future of the Vert.x project Jim Jagielski 1/15/13 9:13 AM
Mark, agreed. My goal is to make sure that people see that this is a community decision. Your statement "I don't think anyone in JBoss has sufficient experience to say whether they would or wouldn't be appropriate." taken by itself, could have been misinterpreted, and with the amount of FUD going around regarding this process, I wanted to make sure that people knew it wasn't further "proof" of some conspiracy. If you are not aware of those claims, consider yourself lucky! But that doesn't mean that they are not happening, nor that the "best" way to address them is to ignore them. But the best way to destroy such "theories" is expose them to the light and it's clear that neither JBoss nor RHT is trying to "drive" anything. We are all here giving advice, and since no one here knows all things about all foundations, whatever ignorance I may have about Eclipse, for example, is filled by those who do know; same with the ASF; same with Outercurve and other potential foundations.

I think that mentioning that *does* advance the topic, and that's sticking to the facts. So I will continue to provide whatever insight I can.
Re: [vertx:6091] Discussion: The future of the Vert.x project Tim Fox 1/15/13 9:34 AM
On 15/01/13 17:13, Jim Jagielski wrote:
Mark, agreed. My goal is to make sure that people see that this is a community decision. Your statement "I don't think anyone in JBoss has sufficient experience to say whether they would or wouldn't be appropriate." taken by itself, could have been misinterpreted, and with the amount of FUD going around regarding this process, I wanted to make sure that people knew it wasn't further "proof" of some conspiracy. If you are not aware of those claims, consider yourself lucky!
I guess I'm lucky too, since I haven't heard any FUD about this process yet :)

--
 
 

Re: [vertx:6062] Re: Discussion: The future of the Vert.x project Ian Skerrett 1/15/13 9:40 AM


On Tuesday, January 15, 2013 9:38:45 AM UTC-5, Ian Skerrett wrote:


So, initially, given your comments on Eclipse, I would like to understand how far we can push the envelope with the use of the existing GH and Google accounts in an Eclipse context.

Aiui, with Eclipse, you can use the github project as a mirror to the main git repo which is hosted by eclipse, but wouldn't be able to use the github issue tracker, and wouldn't be able to use the google group as this would all have to move to an eclipse hosted solution.

This is correct.

FWIW, I work at the Eclipse Foundation.

Just to be clear, I misspoke about your use of Google Groups at Eclipse.  Wayne's response is more accurate. 

 
Re: [vertx:6080] Re: Discussion: The future of the Vert.x project Alexis Richardson 1/15/13 1:51 PM
Wayne

--
Contributions (e.g. GitHub pull requests) need to be taken through our IP process. It's not particularly hard, it just means that we can't generally accept pull requests as-is; we need to be able to reasonably assert the identity of the contributor and have an explicit declaration about the terms of the contribution (i.e. that they authored 100% of the content, have permission to make the contribution, do so under compatible licensing terms). Some modification of the commit record is generally required.
--

Doesn't that just mean that GH pull requests are fine provided that (a) the contributor has signed an explicit declaration at least once, and (b) there is an auditable commit trail into eclipse.org...?

alexis
Re: [vertx:6080] Re: Discussion: The future of the Vert.x project Bradley M. Kuhn 1/15/13 2:06 PM
I must admit some surprise that folks categorized some orgs (e.g., SPI,
Conservancy) as "new".  Conservancy was founded in early 2006, and thus is
only two years younger than Eclipse (so it's new*er*, but not by much at
all).  SPI was founded in 1997, and is thus three years older than ASF.

Meanwhile, I think that you'll find the leadership of both SPI and
Conservancy include key people who have been involved in Free Software
non-profit work for decades.  Indeed, the ideas behind Conservancy's service
plan are based (in part) on the observations and experiences of Conservancy's
Board of Directors ( http://sfconservancy.org/about/board/ ) over their long
careers at many different Open Source and Free Software non-profit
organizations.

I also noted that some have said in this thread that there hasn't been an
opportunity to interact with orgs like Conservancy.  I'm a bit surprised to
see that as well, since (for example) Git has been a heavy part of this
discussion, and the Git project has been a member project of Conservancy for
many years now, and Conservancy has been a part of maintaining the Git
Project's relationship with GitHub.

I do encourage folks to talk to leaders of existing Conservancy projects (
http://sfconservancy.org/members/current/ ) to ask for more details of what
it's like being a member of Conservancy.  Many Conservancy projects, for
example, have leaders who work at Red Hat.
--
Bradley M. Kuhn, Executive Director, Software Freedom Conservancy
Re: [vertx:6080] Re: Discussion: The future of the Vert.x project Jim Jagielski 1/15/13 3:59 PM
I don't envy the virt.x community... talk about a tough decision and a plethora of options! :)
Re: [vertx:6080] Re: Discussion: The future of the Vert.x project Paula Hunter 1/15/13 6:15 PM
Jim, could not agree more.

@Tim, et all.   A number of us will be in London at the end of the month for Redmonk's "Monkigras" http://monkigras.com/

Perhaps a good time for a face to face with a very diverse an experienced crowd?
Re: [vertx:6080] Re: Discussion: The future of the Vert.x project Paula Hunter 1/15/13 6:17 PM


On Tuesday, January 15, 2013 9:15:39 PM UTC-5, Paula Hunter wrote:
Jim, could not agree more.

@Tim, et all.   A number of us will be in London at the end of the month for Redmonk's "Monkigras" http://monkigras.com/

Perhaps a good time for a face to face with a very diverse and experienced crowd?
Re: [vertx:6104] Re: Discussion: The future of the Vert.x project Pid 1/16/13 12:23 AM


On 16 Jan 2013, at 02:15, Paula Hunter <hunter...@gmail.com> wrote:

Jim, could not agree more.

@Tim, et all.   A number of us will be in London at the end of the month for Redmonk's "Monkigras" http://monkigras.com/

Perhaps a good time for a face to face with a very diverse an experienced crowd?

I will also be at Monkigras.


p

--
 
 
Re: [vertx:6099] Re: Discussion: The future of the Vert.x project Mark Little 1/16/13 2:33 AM
Let me clarify that at least when I said "new" I was referring to these organisations and their appeal to what might loosely be called "middleware" and java-related projects. Certainly in my opinion vert.x falls into one or both of these categories and whilst SPI (http://www.spi-inc.org/projects/) and Conservancy (http://sfconservancy.org/members/current/) have some projects that might also be considered in one or both, the numbers of them are dwarfed by those in ASF (http://projects.apache.org/indexes/alpha.html) and Eclipse (http://www.eclipse.org/projects/listofprojects.php).

Mark.

 
On 15 Jan 2013, at 22:06, Bradley M. Kuhn wrote:

I must admit some surprise that folks categorized some orgs (e.g., SPI,
Conservancy) as "new".  Conservancy was founded in early 2006, and thus is
only two years younger than Eclipse (so it's new*er*, but not by much at
all).  SPI was founded in 1997, and is thus three years older than ASF.

Re: Discussion: The future of the Vert.x project Tim Fox 1/16/13 3:23 AM
After much thought I'd like to give my personal recommendation to the community.

As explained in other posts, I think a neutral foundation is the way to go.

As I see it, the main question here is do we need a "full-service" foundation, or will one that provides mainly IP management be sufficient? I know I've oscillated a bit on this point as more information has become available, but my opinion now it's probably best for the project to go for the "full-service".

As Kohsuke pointed out, if we want a truly neutral project the natural conclusion of that is for all the project services to be neutral as well (repo, tracker, hosting etc). I'm sure we _could_ figure out a way to host them ourselves that doesn't have any bias to any particular organisation or individual, but frankly it's a headache. I also think that some kind of project governance that can help prevent committers or project leads going rogue is probably a good idea.

For me, that means we're left with ASF and Eclipse. I've stated on other posts that I am not a huge fan of the ASF voting process, especially the veto, and the weaker notion of project leadership. I also think Eclipse is perhaps a little more "business friendly" and that's going to be an important thing for Vert.x as we progress if we want to get a foothold in large enterprises.

Therefore my recommendation to the community is that the project is proposed for inclusion in the Eclipse Foundation.

On Thursday, 10 January 2013 09:58:38 UTC, Tim Fox wrote:
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.

Re: Discussion: The future of the Vert.x project Mike Milinkovich 1/16/13 5:28 AM
Tim,

Thank you for you very much for recommending the Eclipse Foundation and our community. We will do our best to support you and the vert.x community.
Community: Please make any objections known! Tim Fox 1/16/13 5:43 AM
Community,

I think the next step is to ask you whether you agree with my recommendation or not.

As I mentioned previously, it's hard to do a fair poll on this, so I suggest we do what I suggested in a previous post, and if you really DON'T think that going to Eclipse is a good idea, then please speak up.

If the overwhelming opinion of the community is it's a bad thing, then we should think again.

To be clear, I'm looking for feedback from the community - that does not include people who joined this group _after_ the current situation became public, nor who are representatives from foundations.

I'll keep this question open for a few days so everyone has a chance to comment.

Thanks!
--
 
 

Re: Discussion: The future of the Vert.x project Jim Jagielski 1/16/13 6:20 AM
Yes, if those are issues/conditions (the veto, which must be technical in nature and justified, no "true" lead, voting for consensus, etc) then the ASF is for SURE not a right fit. The ASF isn't for everyone nor for every project (nor do we claim to be). 


On Wednesday, January 16, 2013 6:23:44 AM UTC-5, Tim Fox wrote:
Re: [vertx:6099] Re: Discussion: The future of the Vert.x project Wayne Beaton 1/16/13 6:47 AM
Theoretically, a GitHub pull request could be pulled into a GitHub mirror of an eclipse.org Git repository and then pushed into the eclipse.org Git repository.

The Eclipse IP process would have to be followed. So, if the contributor has an eclipse.org account, the contribution is < 250 lines of code, and the contributor is able to make the claim that they wrote 100% of the code, have the necessary rights to contribute to the project, and do so under the project license, it would be okay.

There is one technical wrinkle: we have a Git hook that only accepts commits that have the "Commit" field set to the credentials of a known eclipse.org committer (we require that the "Author" field contain credentials for the actual author).

Did I mention Gerrit? :-)

Wayne
--
 
 

--
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse Projects
EclipseCon
          2013
Re: [vertx:6099] Re: Discussion: The future of the Vert.x project Alexis Richardson 1/16/13 6:53 AM
OK so I think that means the Github and Google Groups could *both* have a useful role in the Eclipse case, provided that folk want that.

You did mention Gerrit but I was not sure if you meant it would directly apply in automating an auditable pull trail.  Also, I don't know if the community wants to use Gerrit per se. 

alexis
Re: [vertx:6111] Community: Please make any objections known! Pid 1/16/13 6:59 AM
On 16/01/2013 13:43, Tim Fox wrote:
> Community,
>
> I think the next step is to ask you whether you agree with my
> recommendation or not.
>
> As I mentioned previously, it's hard to do a fair poll on this, so I
> suggest we do what I suggested in a previous post, and if you really
> DON'T think that going to Eclipse is a good idea, then please speak up.
>
> If the overwhelming opinion of the community is it's a bad thing, then
> we should think again.
>
> To be clear, I'm looking for feedback from the community - that does not
> include people who joined this group _after_ the current situation
> became public, nor who are representatives from foundations.
>
> I'll keep this question open for a few days so everyone has a chance to
> comment.

I'm a +1 for the record.


p
> --
>  
>  


--

[key:62590808]
Re: Discussion: The future of the Vert.x project Alexis Richardson 1/16/13 10:02 AM
Tim,

Thank-you very much for making a clear recommendation.

I am watching the group keenly for comment!

alexis
Re: [vertx:6118] Community: Please make any objections known! diega 1/16/13 12:17 PM
Hi all,
from the occasional contributor point of view, I think losing github
is really a great loss. I read in the other thread some workflow which
could make github's PR mergeable but I'm afraid that it could add some
disturbing extra steps. What I think is a problem is to lose something
as valuable as the following scenario:
- use vert.x
- found some little thing to contribute
- fork
- pull request
- discuss *in* the PR (github inline comments are awesome)
- got it merged by someone with the proper rights
- feel happy to help your friendly project
- move on

I believe you that dealing with IP is a PITA but I'm not quite sure
that making life complicated for occasional contributors is the way to
go.

My 2 pesos.
> --
>
>



--
diego
Re: [vertx:6118] Community: Please make any objections known! Max Rydahl Andersen 1/16/13 12:52 PM
To be fair eclipse.org does not mean you *lose* github, it means you *gain* a IP clean project :)

requirement for contributions is that a bugzilla issue is opened with a reference back to the github issue related to it.

All the technical discussion on the PR and code comments can still take place in github afaics and have seen in various projects.

The use of gerrit would makes this process even easier btw.

/max
Re: [vertx:6111] Community: Please make any objections known! Mark Little 1/16/13 1:25 PM

For the record, Red Hat is happy to support vert.x in whatever you and the community decide and Eclipse is fine with us.

--
 
 
Re: [vertx:6111] Community: Please make any objections known! bytor99999 1/16/13 2:19 PM
I am also +1 to Eclipse.org

But a -1 to Eclipse IDE. ;) 

Sorry, I am a big IntelliJ fan myself (Sorry Max, JBoss IDE is still great though) I would also like to apologize to those on the forum. I always have to put some joke to lighten things up.

Mark
Re: [vertx:6132] Community: Please make any objections known! Wayne Beaton 1/16/13 2:25 PM
There is no requirement that vert.x developers use an Eclipse-based IDE.

It makes me sad that you don't want to :-(

Any and all feedback on features and improvements that might win you over are appreciated (bug reports are the best way to do this).

Wayne
--
 
 

--
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse Projects
EclipseCon
          2013
Re: [vertx:6132] Community: Please make any objections known! bytor99999 1/16/13 2:52 PM
Sorry. I should keep my jokes/comments out of posts. This thread is about the future of vert.x and don't want my post to detract from that. Wayne, you can ping me on Google+ if you want to discuss.

Mark
Re: [vertx:6136] Community: Please make any objections known! Stéphane Maldini 1/16/13 3:14 PM
well, +1 for the project future sake. I'm not that enthusiast but whatever, I just hope that issue will be solved asap. 


--
 
 



--
Stéphane
--

Re: [vertx:6111] Community: Please make any objections known! Ian Skerrett 1/16/13 3:42 PM


On Wednesday, January 16, 2013 5:19:10 PM UTC-5, bytor99999 wrote:
I am also +1 to Eclipse.org

But a -1 to Eclipse IDE. ;) 

Sorry, I am a big IntelliJ fan myself (Sorry Max, JBoss IDE is still great though) I would also like to apologize to those on the forum. I always have to put some joke to lighten things up.

+1 for having more IntelliJ users in the Eclipse community.
Re: [vertx:6111] Community: Please make any objections known! Alex Tkachman 1/17/13 1:03 PM

Tim,

I dont have strong reasons but my heart belongs to apache and hate to eclipse.

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

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

On Jan 16, 2013 2:43 PM, "Tim Fox" <timv...@gmail.com> wrote:
--
 
 
Re: [vertx:6111] Community: Please make any objections known! Bruce Snyder 1/17/13 4:52 PM
+1 for moving the code to a neutral foundation for IP management. 

-1 to losing the agility provided by Github and pull requests. 

I'm told directly by people I know who work on projects at the Eclipse Foundation that the use of Gerrit for contributions is nothing short of a giant pain in the ass (not my words). Not only does it require a much greater amount of effort on the part of the committer(s) to incorporate contributions, but it also erects a pretty large barrier to contributors. 'If you want to encourage contributions by non-committers, this is a big issue,' said one person. 

Also, if you want to add any dependencies to your project that are not already in existence at Eclipse (this includes a minor update from, say, JUnit 4.4 to JUnit 4.5), those dependencies must be taken through the Eclipse IP review process which is very time consuming, very arduous and puts on hold anything that makes use of that dependency. This can take anywhere from a few days to literally months to complete. 

Just for the record, I have no vested interest in vert.x other than my own personal interest, so I felt it was only fair that the comments from these direct experiences be known. These comments come straight from folks who have been involved in the sausage making behind the scenes at The Eclipse Foundation, they are not embellished by me at all. 

Overall, I want to thank Tim for opening up this process and allowing the community to participate. I hope my comments are helpful. 

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
Re: [vertx:6168] Community: Please make any objections known! Tim Fox 1/18/13 12:16 AM
Hi Bruce,

I totally understand your concerns, and it's something I have looked into myself. I chatted with a few different people who have experience of working on Eclipse projects and the general concensus was, yes, there is more process than (say) github, but it's not _too_ bad. Of course, ymmv, I guess.
--
 
 

Re: [vertx:6111] Community: Please make any objections known! Brian Lalor 1/18/13 5:30 AM
On Jan 16, 2013, at 8:43 AM, Tim Fox <timv...@gmail.com> wrote:

I think the next step is to ask you whether you agree with my recommendation or not.

I agree with the Eclipse direction.  Some things are sure to be odious, but overall I think we'll benefit from being neutrally hosted and probably have some things to gain from the project- and release-management side of things.
Re: [vertx:6168] Community: Please make any objections known! Max Rydahl Andersen 1/18/13 5:39 AM
At least from a contributor side I believe it can be reduced to open bugzilla with link to github + state "I contribute this".
Of course if the contributor does not have an eclipse account that will be a bit tedious, but only the first time....but if IP cleanliness is important
then not sure how to make this simpler than this ?

On the issue of dependencies I think this really depend on what set of dependencies vert.x think it will need to get cleared ?
As I understood from Tim, vert.x core intention is to keep the dependencies small and its only for addons/modules there could be external "alien" dependencies - but those non-IP cleared community contributed extensions could still live on github *outside* of eclipse.org and thus only put the essentials into eclipse.org repositories and process.

In any case I recommend trying to get a list of the wanted dependencies listed and try and see how big a problem it is upfront and consider what would potentially happen shortterm could make it clear if there actually are issues before declaring it a blocking problem.

/max
Re: [vertx:6168] Community: Please make any objections known! Jim Jagielski 1/18/13 5:54 AM
Here's a thought... have some sort of agreement w/ Eclipse that you can "try 'em out" for 6months or so and if the fit isn't good, you can move to another foundation with a lot less overhead (like OuterCurve) and Eclipse agrees to xfer IP and brand to that foundation.
Re: [vertx:6184] Community: Please make any objections known! Tim Yates 1/18/13 6:01 AM
I like this idea if it's the way things are going?

So vert.x could have 2 places to lookup modules.  A core internal repo containing IP cleared core-vert.x developer maintained modules, and an external repo for plugins and mods written by those outside of the core team?

Tim

On 18 January 2013 13:39, Max Rydahl Andersen <max.an...@gmail.com> wrote:
As I understood from Tim, vert.x core intention is to keep the dependencies small and its only for addons/modules there could be external "alien" dependencies - but those non-IP cleared community contributed extensions could still live on github *outside* of eclipse.org and thus only put the essentials into eclipse.org repositories and process.


Re: [vertx:6184] Community: Please make any objections known! Mike Milinkovich 1/18/13 6:10 AM
On Friday, January 18, 2013 9:01:10 AM UTC-5, Tim Yates wrote:
I like this idea if it's the way things are going?

So vert.x could have 2 places to lookup modules.  A core internal repo containing IP cleared core-vert.x developer maintained modules, and an external repo for plugins and mods written by those outside of the core team?

Tim,

This is pretty much how all of Eclipse works today. Our projects create platforms that the community and ecosystem then extend. The best example I can point to is the Eclipse marketplace, which has about a thousand plug-ins listed[1]. Marketplace is not really a "repo" though. We think of it more as a catalogue. It's a central listing that points to the repos of many projects, communities and companies.

I could certainly imagine a similar scenario for the vert.x community.

Re: [vertx:6168] Community: Please make any objections known! Alexis Richardson 1/18/13 6:29 AM
I'd be surprised if Eclipse would commit to that upfront.  And, I am not sure what is gained for the community, because this increases uncertainty.  Speaking for VMware, it does not make us feel comfortable making the effort to cleanly transfer everything to one place without certainty that it has a future there.

alexis
Re: [vertx:6111] Community: Please make any objections known! J Arthorn 1/18/13 6:53 AM
On Thursday, January 17, 2013 7:52:36 PM UTC-5, Bruce Snyder wrote:
I'm told directly by people I know who work on projects at the Eclipse Foundation that the use of Gerrit for contributions is nothing short of a giant pain in the ass (not my words). Not only does it require a much greater amount of effort on the part of the committer(s) to incorporate contributions, but it also erects a pretty large barrier to contributors. 'If you want to encourage contributions by non-committers, this is a big issue,' said one person. 

It's true that none of the contribution workflows at Eclipse can be reduced to a single click like you can get in GitHub. To me the overhead is still very small compared to the work involved for the contributor to come up with an interesting fix/enhancement, and the work to review/test the contribution. To be clear there are two available contributor workflows today at Eclipse:

1) Contributor opens a github pull request, and an Eclipse bugzilla pointing to it. Committer fetches the contributor's github clone, merges/cherry-picks the change, tests, etc, pushes the change, and closes the pull request. Same work for the contributor as a basic pull request, but a bit more work for committer. The current requirement to open a bugzilla is being reconsidered and will hopefully be removed in favour of kernel.org style signed-off-by header.

2) Contributor pushes contribution to gerrit at eclipse.org. Committer can accept the change directly in gerrit with a couple of clicks if they want, or trigger automatic tests, do more review, etc. Same work for committer as a basic pull request, but a bit more work for contributor.

I tend to use option 1), but if you take advantage of some of the other gerrit features like triggering automatic tests, line by line code reviews, etc, it can be a great tool. Some people love it, some are indifferent. Nobody's forcing you to use it (well, it's up to the project lead, so PL can force you to use it if they choose).
 

Also, if you want to add any dependencies to your project that are not already in existence at Eclipse (this includes a minor update from, say, JUnit 4.4 to JUnit 4.5), those dependencies must be taken through the Eclipse IP review process which is very time consuming, very arduous and puts on hold anything that makes use of that dependency. This can take anywhere from a few days to literally months to complete. 

This is part truth but part exaggeration. New versions of previously approved libraries can be checked in immediately, review happens in parallel and never impacts the project schedule from what I've seen. However if you have a new library you want to consume, and that library has no provenance records, it can in the worst case take months to track down all the authors and get the records in place. If your project is ok with shipping code of unknown authorship you will find this process frustrating.

John
Re: [vertx:6247] Community: Please make any objections known! Max Rydahl Andersen 1/18/13 7:01 AM
Thanks John - exactly what I tried to express too. 

/max (sent from my phone)

--
 
 
Re: [vertx:6189] Community: Please make any objections known! Tim Fox 1/18/13 7:20 AM
Hi Mike,

In Vert.x 2.0 the module repo will probably be a Maven repo. Would Eclipse be able to host one internally for IP checked modules that we create ourselves?

Then we could have another one hosted outside the Eclipse infrastructure for community contributed modules as Tim Y has mentioned.

--
 
 

Re: [vertx:6196] Community: Please make any objections known! Cédric Champeau 1/18/13 7:22 AM
Le 18/01/2013 15:53, John Arthorne a écrit :
On Thursday, January 17, 2013 7:52:36 PM UTC-5, Bruce Snyder wrote:
I'm told directly by people I know who work on projects at the Eclipse Foundation that the use of Gerrit for contributions is nothing short of a giant pain in the ass (not my words). Not only does it require a much greater amount of effort on the part of the committer(s) to incorporate contributions, but it also erects a pretty large barrier to contributors. 'If you want to encourage contributions by non-committers, this is a big issue,' said one person. 

It's true that none of the contribution workflows at Eclipse can be reduced to a single click like you can get in GitHub. To me the overhead is still very small compared to the work involved for the contributor to come up with an interesting fix/enhancement, and the work to review/test the contribution. To be clear there are two available contributor workflows today at Eclipse:

1) Contributor opens a github pull request, and an Eclipse bugzilla pointing to it. Committer fetches the contributor's github clone, merges/cherry-picks the change, tests, etc, pushes the change, and closes the pull request. Same work for the contributor as a basic pull request, but a bit more work for committer. The current requirement to open a bugzilla is being reconsidered and will hopefully be removed in favour of kernel.org style signed-off-by header.

+1. Though Groovy sources are hosted to GitHub, I use the same workflow to merge pull requests. I don't like the idea of a single-click merge because you don't test what you merge. Often, you even want to merge the PR onto multiple branches, so eventually you will have to pull the main github repo, then cherry-pick the changes to apply to several branches. If you need to do this once, then do it always :) Also we ask contributors to link PR to jira issues if possible (which is easy if the contributor creates a branch which name is the ticket number).

-- 
Cédric Champeau
SpringSource - A Division Of VMware
http://www.springsource.com/
http://twitter.com/CedricChampeau
Re: [vertx:6200] Community: Please make any objections known! Tim Fox 1/18/13 7:25 AM
On 18/01/13 15:22, Cédric Champeau wrote:
Le 18/01/2013 15:53, John Arthorne a écrit :
On Thursday, January 17, 2013 7:52:36 PM UTC-5, Bruce Snyder wrote:
I'm told directly by people I know who work on projects at the Eclipse Foundation that the use of Gerrit for contributions is nothing short of a giant pain in the ass (not my words). Not only does it require a much greater amount of effort on the part of the committer(s) to incorporate contributions, but it also erects a pretty large barrier to contributors. 'If you want to encourage contributions by non-committers, this is a big issue,' said one person. 

It's true that none of the contribution workflows at Eclipse can be reduced to a single click like you can get in GitHub. To me the overhead is still very small compared to the work involved for the contributor to come up with an interesting fix/enhancement, and the work to review/test the contribution. To be clear there are two available contributor workflows today at Eclipse:

1) Contributor opens a github pull request, and an Eclipse bugzilla pointing to it. Committer fetches the contributor's github clone, merges/cherry-picks the change, tests, etc, pushes the change, and closes the pull request. Same work for the contributor as a basic pull request, but a bit more work for committer. The current requirement to open a bugzilla is being reconsidered and will hopefully be removed in favour of kernel.org style signed-off-by header.

+1. Though Groovy sources are hosted to GitHub, I use the same workflow to merge pull requests. I don't like the idea of a single-click merge because you don't test what you merge.

Indeed. For all but the most trivial PRs these days I manually pull the PR into a test_merge branch, test it, and if ok, merge test_merge into master (or wherever). The github single click merge is actually quite a flawed idea IMHO.

Often, you even want to merge the PR onto multiple branches, so eventually you will have to pull the main github repo, then cherry-pick the changes to apply to several branches. If you need to do this once, then do it always :) Also we ask contributors to link PR to jira issues if possible (which is easy if the contributor creates a branch which name is the ticket number).

-- 
Cédric Champeau
SpringSource - A Division Of VMware
http://www.springsource.com/
http://twitter.com/CedricChampeau
--
 
 

Re: [vertx:6199] Community: Please make any objections known! Wayne Beaton 1/18/13 7:40 AM
On 01/18/2013 10:20 AM, Tim Fox wrote:

Hi Mike,

In Vert.x 2.0 the module repo will probably be a Maven repo. Would Eclipse be able to host one internally for IP checked modules that we create ourselves?

The short answer is yes.

The longer and more involved answer is that we are working on growing Maven story, but we're not quite there yet. What we're trying to build is a central Maven repository for Eclipse projects (e.g. maven.eclipse.org) based on open source Nexus. We intend to build this into our common build infrastructure (CBI) story so that it will be easy for projects to publish any artefacts they choose. This repository will also be home to IP-cleared third-party artefacts provided by our Orbit project.

Our work on this to date (in conjunction with some very Maven-savvy individuals) has helped us to understand how we don't want to do it :-)

The good news is that we're still at a point where we welcome your participation to make sure that we get it right. We'll pull all the Maven heads together at EclipseCon this year to work out our plan.

In the meantime, some Eclipse projects provide their own Maven repositories.

HTH,

Wayne

--
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse Projects
EclipseCon
          2013
Re: [vertx:6203] Community: Please make any objections known! Tim Fox 1/18/13 8:57 AM
Thanks Wayne,

Perhaps you can help me with another question.

I think I've got a fairly good idea of the IP check procedure for all the code in the project itself, but I also believe you check IP for any third party libraries we depend on.

I wonder if you could tell me a bit about what that procedure involves? Do you just check that the license for that library is compatible and the library is distributable? Or is there some other deeper check made through the source code in those libraries?

--
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse Projects
EclipseCon
            2013
--
 
 

Re: [vertx:6208] Community: Please make any objections known! Wayne Beaton 1/18/13 9:22 AM
On 01/18/2013 11:57 AM, Tim Fox wrote:
On 18/01/13 15:40, Wayne Beaton wrote:
On 01/18/2013 10:20 AM, Tim Fox wrote:

Hi Mike,

In Vert.x 2.0 the module repo will probably be a Maven repo. Would Eclipse be able to host one internally for IP checked modules that we create ourselves?

The short answer is yes.

The longer and more involved answer is that we are working on growing Maven story, but we're not quite there yet. What we're trying to build is a central Maven repository for Eclipse projects (e.g. maven.eclipse.org) based on open source Nexus. We intend to build this into our common build infrastructure (CBI) story so that it will be easy for projects to publish any artefacts they choose. This repository will also be home to IP-cleared third-party artefacts provided by our Orbit project.

Our work on this to date (in conjunction with some very Maven-savvy individuals) has helped us to understand how we don't want to do it :-)

The good news is that we're still at a point where we welcome your participation to make sure that we get it right. We'll pull all the Maven heads together at EclipseCon this year to work out our plan.

In the meantime, some Eclipse projects provide their own Maven repositories.

HTH,

Wayne

Thanks Wayne,

Perhaps you can help me with another question.

I think I've got a fairly good idea of the IP check procedure for all the code in the project itself, but I also believe you check IP for any third party libraries we depend on.
We do. Anything that is distributed from eclipse.org has to go through our IP due diligence process. This includes third-party libraries.

I wonder if you could tell me a bit about what that procedure involves? Do you just check that the license for that library is compatible and the library is distributable? Or is there some other deeper check made through the source code in those libraries?
License check is the first part. If a license checks out, a project will be given provisional approval to use the third-party code while a more detailed scan occurs.

The detailed scan is pretty exhaustive. They track down the provenance of the third-party code, directly contacting the developers when necessary. The IP team uses tools to help scan the full source for issues (i.e. did somebody copy and paste code from an incompatible license, or copy and paste without attribution, or ...). Issues need to be adequately explained/resolved before full approval is given.

The upside is that we have a great deal of confidence in the IP cleared third-party libraries.

The big upside is that this exercise--which really needs to be done if you're serious about IP management--is not the responsibility of developers who hate doing this sort of thing.

The downside is that this due diligence process can be time consuming. How much time depends on factors like the record keeping ethic of the projects involved, availability of source, responsiveness of the developers, etc.

Another big upside is that we've already reviewed a large number of libraries. Chances are that we've already done the work for at least some of the third-party code used by vert.x

HTH,

Wayne

--
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse Projects
EclipseCon
          2013
Re: [vertx:6111] Community: Please make any objections known! Chris Aniszczyk 1/18/13 10:21 AM
On Friday, January 18, 2013 8:53:34 AM UTC-6, John Arthorne wrote:
On Thursday, January 17, 2013 7:52:36 PM UTC-5, Bruce Snyder wrote:
I'm told directly by people I know who work on projects at the Eclipse Foundation that the use of Gerrit for contributions is nothing short of a giant pain in the ass (not my words). Not only does it require a much greater amount of effort on the part of the committer(s) to incorporate contributions, but it also erects a pretty large barrier to contributors. 'If you want to encourage contributions by non-committers, this is a big issue,' said one person. 

It's true that none of the contribution workflows at Eclipse can be reduced to a single click like you can get in GitHub. To me the overhead is still very small compared to the work involved for the contributor to come up with an interesting fix/enhancement, and the work to review/test the contribution. To be clear there are two available contributor workflows today at Eclipse:

1) Contributor opens a github pull request, and an Eclipse bugzilla pointing to it. Committer fetches the contributor's github clone, merges/cherry-picks the change, tests, etc, pushes the change, and closes the pull request. Same work for the contributor as a basic pull request, but a bit more work for committer. The current requirement to open a bugzilla is being reconsidered and will hopefully be removed in favour of kernel.org style signed-off-by header.

2) Contributor pushes contribution to gerrit at eclipse.org. Committer can accept the change directly in gerrit with a couple of clicks if they want, or trigger automatic tests, do more review, etc. Same work for committer as a basic pull request, but a bit more work for contributor.

I tend to use option 1), but if you take advantage of some of the other gerrit features like triggering automatic tests, line by line code reviews, etc, it can be a great tool. Some people love it, some are indifferent. Nobody's forcing you to use it (well, it's up to the project lead, so PL can force you to use it if they choose).

To expand on #1, I just did a quick query via the github archive on pull request stats for Eclipse: we had 231 last year.

Some projects are using it but we haven't done much advertising it as a pathway for contributions (I could imagine having CONTRIBUTING.MD files in each Eclipse repo as a start with more information: https://github.com/blog/1184-contributing-guidelines). The key point here is that we're working on it and making progress. Personally, it's the next thing on my list as a committer representative at the Eclipse Foundation to work on, I'd like to see us integrate better into GitHub and have a few ideas on making that happen.

At the end, you have the choice as a project in how you want to work.
 

Also, if you want to add any dependencies to your project that are not already in existence at Eclipse (this includes a minor update from, say, JUnit 4.4 to JUnit 4.5), those dependencies must be taken through the Eclipse IP review process which is very time consuming, very arduous and puts on hold anything that makes use of that dependency. This can take anywhere from a few days to literally months to complete. 

This is part truth but part exaggeration. New versions of previously approved libraries can be checked in immediately, review happens in parallel and never impacts the project schedule from what I've seen. However if you have a new library you want to consume, and that library has no provenance records, it can in the worst case take months to track down all the authors and get the records in place. If your project is ok with shipping code of unknown authorship you will find this process frustrating.

I agree with John here with the exaggeration bit. On top of that... the Eclipse IP team has always screen a ton of libraries which are available so probably most of vert.x dependencies are covered.
Re: [vertx:6212] Community: Please make any objections known! Guillaume Laforge 1/18/13 11:15 AM
Hi Chris,

On Fri, Jan 18, 2013 at 7:21 PM, Chris Aniszczyk <canis...@gmail.com> wrote:
[...]
I agree with John here with the exaggeration bit. On top of that... the Eclipse IP team has always screen a ton of libraries which are available so probably most of vert.x dependencies are covered.

For example, have you got Groovy covered? 
I don't think it is. 


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

Re: [vertx:6212] Community: Please make any objections known! Tim Fox 1/18/13 12:21 PM
Chris,

is there a public list of 3rd party libs and versions which have passed through the IP process?
--
 
 

Re: Community: Please make any objections known! Tim Fox 1/22/13 3:03 AM
This question has been open for several days now, and we haven't seen a significant number of objections, so I assume we now have implicit approval by the community for a move to Eclipse foundation.

I think the next step would be for VMware to confirm this is acceptable, and get the ball rolling with the Eclipse folks. VMware.. over to you :)

I will of course be available for any assistance as and when this is required.
Re: Community: Please make any objections known! Alexis Richardson 1/22/13 3:07 AM
Tim, all,

This is acceptable to VMware.  Thank-you Tim, and everyone, for moving this along so well.

As a next step, I suggest a new thread be created "Moving to Eclipse" - I think Mike should do this.  Concurrently our lawyers can speak with Eclipse's legal team about the formal process.

alexis
Re: [vertx:6270] Re: Community: Please make any objections known! Alex Tkachman 1/22/13 3:38 AM
Great to see it resolved


--
 
 



--
Best regards,
Alex

Best way to call / chat with me
http://lucy.me/alex
unk...@googlegroups.com 1/28/13 12:29 PM <This message has been deleted.>
unk...@googlegroups.com 1/28/13 2:00 PM <This message has been deleted.>
Re: [vertx:6444] Discussion: The future of the Vert.x project Pid 1/28/13 3:03 PM


On 28 Jan 2013, at 20:29, Carlo Kokoth <carlo....@gmail.com> wrote:

Another dose of FUD from Laforge, corporate lackey extraordinaire, strangler of Groovy, man of big words and small coding skills.

If only there was a way to beam you somewhere far away, Mr. Laforge.

Comments like this are inappropriate on this mailing list. Please do not repeat them.


p



On Thursday, January 10, 2013 3:31:27 PM UTC+1, Guillaume Laforge wrote:
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

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group, send email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
More topics »