Quantcast

Moving Groovy to a Foundation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
199 messages Options
1234 ... 20
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Moving Groovy to a Foundation

Cédric Champeau

Dear community,

Dear foundation representatives,


We all love Groovy and it is important for us to secure its future. You all have been recently warned that Pivotal, the company which sponsors 3 full time developers on Groovy, is going to stop that sponsorship by the end of March.


We also learnt that Codehaus is going to shut down, even if the date isn’t clear yet, but we need to move off the Codehaus infrastructure quickly. Codehaus is also important in Groovy history because Groovy was developed with the Codehaus Manifesto as the governance model.


There are discussions ongoing to find fundings for Groovy, especially finding companies willing to hire the core team, but whenever we find a new sponsor for our jobs or not, Groovy is going to move to a foundation. This is very important for the future of the language and the team is convinced that it has to be done as soon as possible, that is to say before end of March.


We have investigated several options and after a first review we are asking you to help us choose between 3 remaining candidates (in no particular order), because it has to be a decision driven by the community:



There are advantages and drawbacks for all of them. Some of the drawbacks of Apache and Eclipse are so important that it require us to “negotiate” with them, so let us summarize what is important, for us:


  • License should remain Apache License, version 2.0

  • Governance model. Apache and Eclipse come with their own governance model that we need to conform to. It may go as far as how and where deliverables are deployed. SFConservancy will let us define our own governance model.

  • Infrastructure: Apache and Eclipse come with their own infrastructure, that we can use and don’t have to maintain. It includes source repositories, website hosting, mailing lists, bug tracker,… SFConservancy doesn’t provide one but in turn will let us use the tools we want as long as we can pay the bills.

  • Funding: after the call for sponsorship, we received several offers from companies willing to donate to the project. It is still insufficient for us to be able to pay a full time developer, but it is still large enough to consider a foundation that will let us use those funds, for example to pay expenses to conferences, host the hardware infrastructure (for example for SFConservancy), marketing...

  • Sources need to be hosted on Git, and preferably we want to be able to continue working with GitHub, which has dramatically improved the number of contributions we got from the community

  • History. Eclipse for example will require us to fully reset project history. In fact, it requires us to do 2 things:

    • upgrade Antlr to version 4 (which is planned for Groovy 3 but still requires a lot of work)

    • abandon old versions of Groovy. It is in our opinion a very problematic problem because it means that we do not support old versions of Groovy anymore. No more maintenance of 2.x branches, not speaking about 1.8 and older. For a language, we consider this a very big issue. We need to be able to continue development of older versions.

  • Binary compatibility: While it is possible to change the Maven coordinates (group id/artifact id) of Groovy, it is totally impossible to break binary compatibility by changing the package names for example. There’s just too much code in the wild using Groovy everywhere. So we need to be able to stick with groovy.lang and org.codehaus.groovy.

  • Tooling. We spent a lot of time narrowing our build and release infrastructure. Releasing a new version of Groovy is more or less a click on a button that will build everything on TeamCity, deploy artifacts on Bintray, then synchronize on Maven Central and eventually publish to GVM. It is very nice if we can stick with that process as the primary process, and if necessary backup on the foundation infrastructure. We also use JIRA for bug tracking and it is an important thing for us to be able to use it as the primary bug report system (even if we know we have to migrate ASAP out of Codehaus)


SFConservancy has various advantages:


  • the governance model can be adapted (and made clearer) from the Codehaus Manifesto

  • focus is on individuals using our software rather than process and legal but still provides legal support

  • It acts as a fiscal sponsor and is able to accept funds dedicated to the project, allowing us to have, basically, a bank account for companies willing to donate to the Groovy project. It also supports tax-deductible donations which is more interesting for donators.

  • It will let us support older versions of Groovy as well as continue working with the tools we are used to


The main drawback of SFConservancy is money. Since it doesn’t provide any kind of infrastructure, we need to build it by our own. It’s not very hard but it will cost some time and money.


Eclipse and Apache offer a clearer governance approach, a brand many recognize, but also have some of the drawbacks we’ve mentioned already above. Our contacts at both Eclipse and Apache have been very interesting too, as their are some options around those drawbacks.


So to be clear, we’re not ruling out any of the options. We can accommodate some drawbacks, but not too many of them. We want to make the best decision and that’s why we are asking you, our users, our community, what you think and also invite representatives from those foundations to give their advices. We would like to thank those who already asked some of our questions privately, but now is time for an open discussion!


In any case, we have to move fast, but we do not decide everything by ourselves: applying doesn’t mean being accepted. Thanks for your thoughts and help!

-- 
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Moving Groovy to a Foundation

David M. Karr

You should spend some time assigning weights to each of your requirements and clearly noting how each of these choices meet (or don’t meet) those requirements.  You’ve listed your requirements, but only described how some of the choices meet those requirements.  Obviously, some of those “requirements” will be driven by the negation of some of the limitations of each of these choices.  Those particular requirements will likely drive your eventual choice.

 

Anyone reading what you’ve written here could easily conclude that the limitations of the Eclipse Foundation choice are too onerous, at least given the implicit weights you’ve given here.

 

From: Cédric Champeau [mailto:[hidden email]]
Sent: Wednesday, February 11, 2015 8:29 AM
To: [hidden email]
Subject: [groovy-user] Moving Groovy to a Foundation

 

Dear community,

Dear foundation representatives,

 

We all love Groovy and it is important for us to secure its future. You all have been recently warned that Pivotal, the company which sponsors 3 full time developers on Groovy, is going to stop that sponsorship by the end of March.

 

We also learnt that Codehaus is going to shut down, even if the date isn’t clear yet, but we need to move off the Codehaus infrastructure quickly. Codehaus is also important in Groovy history because Groovy was developed with the Codehaus Manifesto as the governance model.

 

There are discussions ongoing to find fundings for Groovy, especially finding companies willing to hire the core team, but whenever we find a new sponsor for our jobs or not, Groovy is going to move to a foundation. This is very important for the future of the language and the team is convinced that it has to be done as soon as possible, that is to say before end of March.

 

We have investigated several options and after a first review we are asking you to help us choose between 3 remaining candidates (in no particular order), because it has to be a decision driven by the community:

 

·      The Apache Software Foundation, home of Apache HTTP server, Lucene, Spark and lots of famous OSS projects

·      The Eclipse Foundation, home of Eclipse, vert.x, AspectJ and a lot of tooling related OSS projects

·      The Software Freedom Conservancy, home of Git, Mercurial, PyPy and many other OSS projects

 

There are advantages and drawbacks for all of them. Some of the drawbacks of Apache and Eclipse are so important that it require us to “negotiate” with them, so let us summarize what is important, for us:

 

·      License should remain Apache License, version 2.0

·      Governance model. Apache and Eclipse come with their own governance model that we need to conform to. It may go as far as how and where deliverables are deployed. SFConservancy will let us define our own governance model.

·      Infrastructure: Apache and Eclipse come with their own infrastructure, that we can use and don’t have to maintain. It includes source repositories, website hosting, mailing lists, bug tracker,… SFConservancy doesn’t provide one but in turn will let us use the tools we want as long as we can pay the bills.

·      Funding: after the call for sponsorship, we received several offers from companies willing to donate to the project. It is still insufficient for us to be able to pay a full time developer, but it is still large enough to consider a foundation that will let us use those funds, for example to pay expenses to conferences, host the hardware infrastructure (for example for SFConservancy), marketing...

·      Sources need to be hosted on Git, and preferably we want to be able to continue working with GitHub, which has dramatically improved the number of contributions we got from the community

·      History. Eclipse for example will require us to fully reset project history. In fact, it requires us to do 2 things:

·      upgrade Antlr to version 4 (which is planned for Groovy 3 but still requires a lot of work)

·      abandon old versions of Groovy. It is in our opinion a very problematic problem because it means that we do not support old versions of Groovy anymore. No more maintenance of 2.x branches, not speaking about 1.8 and older. For a language, we consider this a very big issue. We need to be able to continue development of older versions.

·      Binary compatibility: While it is possible to change the Maven coordinates (group id/artifact id) of Groovy, it is totally impossible to break binary compatibility by changing the package names for example. There’s just too much code in the wild using Groovy everywhere. So we need to be able to stick with groovy.lang and org.codehaus.groovy.

·      Tooling. We spent a lot of time narrowing our build and release infrastructure. Releasing a new version of Groovy is more or less a click on a button that will build everything on TeamCity, deploy artifacts on Bintray, then synchronize on Maven Central and eventually publish to GVM. It is very nice if we can stick with that process as the primary process, and if necessary backup on the foundation infrastructure. We also use JIRA for bug tracking and it is an important thing for us to be able to use it as the primary bug report system (even if we know we have to migrate ASAP out of Codehaus)

 

SFConservancy has various advantages:

 

·      the governance model can be adapted (and made clearer) from the Codehaus Manifesto

·      focus is on individuals using our software rather than process and legal but still provides legal support

·      It acts as a fiscal sponsor and is able to accept funds dedicated to the project, allowing us to have, basically, a bank account for companies willing to donate to the Groovy project. It also supports tax-deductible donations which is more interesting for donators.

·      It will let us support older versions of Groovy as well as continue working with the tools we are used to

 

The main drawback of SFConservancy is money. Since it doesn’t provide any kind of infrastructure, we need to build it by our own. It’s not very hard but it will cost some time and money.

 

Eclipse and Apache offer a clearer governance approach, a brand many recognize, but also have some of the drawbacks we’ve mentioned already above. Our contacts at both Eclipse and Apache have been very interesting too, as their are some options around those drawbacks.

 

So to be clear, we’re not ruling out any of the options. We can accommodate some drawbacks, but not too many of them. We want to make the best decision and that’s why we are asking you, our users, our community, what you think and also invite representatives from those foundations to give their advices. We would like to thank those who already asked some of our questions privately, but now is time for an open discussion!

 

In any case, we have to move fast, but we do not decide everything by ourselves: applying doesn’t mean being accepted. Thanks for your thoughts and help!

-- 
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog
 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Moving Groovy to a Foundation

Cédric Champeau
On 11/02/2015 17:47, KARR, DAVID wrote:

You should spend some time assigning weights to each of your requirements and clearly noting how each of these choices meet (or don’t meet) those requirements.

We have such a grid internally. Now weighting is not enough. It also depends on what the team (for development) and the community is ready to accept.

Anyone reading what you’ve written here could easily conclude that the limitations of the Eclipse Foundation choice are too onerous, at least given the implicit weights you’ve given here.

Eclipse is not ruled out, nor is Apache or Conservancy. It will depend on what each can offer and what we, as a community, are ready to accept. I have my opinion for example, but it is not shared by all the team. So we will try to make the best choice out of the discussions here.

 

From: Cédric Champeau [[hidden email]]
Sent: Wednesday, February 11, 2015 8:29 AM
To: [hidden email]
Subject: [groovy-user] Moving Groovy to a Foundation

 

Dear community,

Dear foundation representatives,

 

We all love Groovy and it is important for us to secure its future. You all have been recently warned that Pivotal, the company which sponsors 3 full time developers on Groovy, is going to stop that sponsorship by the end of March.

 

We also learnt that Codehaus is going to shut down, even if the date isn’t clear yet, but we need to move off the Codehaus infrastructure quickly. Codehaus is also important in Groovy history because Groovy was developed with the Codehaus Manifesto as the governance model.

 

There are discussions ongoing to find fundings for Groovy, especially finding companies willing to hire the core team, but whenever we find a new sponsor for our jobs or not, Groovy is going to move to a foundation. This is very important for the future of the language and the team is convinced that it has to be done as soon as possible, that is to say before end of March.

 

We have investigated several options and after a first review we are asking you to help us choose between 3 remaining candidates (in no particular order), because it has to be a decision driven by the community:

 

·      The Apache Software Foundation, home of Apache HTTP server, Lucene, Spark and lots of famous OSS projects

·      The Eclipse Foundation, home of Eclipse, vert.x, AspectJ and a lot of tooling related OSS projects

·      The Software Freedom Conservancy, home of Git, Mercurial, PyPy and many other OSS projects

 

There are advantages and drawbacks for all of them. Some of the drawbacks of Apache and Eclipse are so important that it require us to “negotiate” with them, so let us summarize what is important, for us:

 

·      License should remain Apache License, version 2.0

·      Governance model. Apache and Eclipse come with their own governance model that we need to conform to. It may go as far as how and where deliverables are deployed. SFConservancy will let us define our own governance model.

·      Infrastructure: Apache and Eclipse come with their own infrastructure, that we can use and don’t have to maintain. It includes source repositories, website hosting, mailing lists, bug tracker,… SFConservancy doesn’t provide one but in turn will let us use the tools we want as long as we can pay the bills.

·      Funding: after the call for sponsorship, we received several offers from companies willing to donate to the project. It is still insufficient for us to be able to pay a full time developer, but it is still large enough to consider a foundation that will let us use those funds, for example to pay expenses to conferences, host the hardware infrastructure (for example for SFConservancy), marketing...

·      Sources need to be hosted on Git, and preferably we want to be able to continue working with GitHub, which has dramatically improved the number of contributions we got from the community

·      History. Eclipse for example will require us to fully reset project history. In fact, it requires us to do 2 things:

·      upgrade Antlr to version 4 (which is planned for Groovy 3 but still requires a lot of work)

·      abandon old versions of Groovy. It is in our opinion a very problematic problem because it means that we do not support old versions of Groovy anymore. No more maintenance of 2.x branches, not speaking about 1.8 and older. For a language, we consider this a very big issue. We need to be able to continue development of older versions.

·      Binary compatibility: While it is possible to change the Maven coordinates (group id/artifact id) of Groovy, it is totally impossible to break binary compatibility by changing the package names for example. There’s just too much code in the wild using Groovy everywhere. So we need to be able to stick with groovy.lang and org.codehaus.groovy.

·      Tooling. We spent a lot of time narrowing our build and release infrastructure. Releasing a new version of Groovy is more or less a click on a button that will build everything on TeamCity, deploy artifacts on Bintray, then synchronize on Maven Central and eventually publish to GVM. It is very nice if we can stick with that process as the primary process, and if necessary backup on the foundation infrastructure. We also use JIRA for bug tracking and it is an important thing for us to be able to use it as the primary bug report system (even if we know we have to migrate ASAP out of Codehaus)

 

SFConservancy has various advantages:

 

·      the governance model can be adapted (and made clearer) from the Codehaus Manifesto

·      focus is on individuals using our software rather than process and legal but still provides legal support

·      It acts as a fiscal sponsor and is able to accept funds dedicated to the project, allowing us to have, basically, a bank account for companies willing to donate to the Groovy project. It also supports tax-deductible donations which is more interesting for donators.

·      It will let us support older versions of Groovy as well as continue working with the tools we are used to

 

The main drawback of SFConservancy is money. Since it doesn’t provide any kind of infrastructure, we need to build it by our own. It’s not very hard but it will cost some time and money.

 

Eclipse and Apache offer a clearer governance approach, a brand many recognize, but also have some of the drawbacks we’ve mentioned already above. Our contacts at both Eclipse and Apache have been very interesting too, as their are some options around those drawbacks.

 

So to be clear, we’re not ruling out any of the options. We can accommodate some drawbacks, but not too many of them. We want to make the best decision and that’s why we are asking you, our users, our community, what you think and also invite representatives from those foundations to give their advices. We would like to thank those who already asked some of our questions privately, but now is time for an open discussion!

 

In any case, we have to move fast, but we do not decide everything by ourselves: applying doesn’t mean being accepted. Thanks for your thoughts and help!

-- 
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog
 


-- 
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Moving Groovy to a Foundation

Suderman Keith-3
In reply to this post by Cédric Champeau
I would suggest that Eclipse's requirement to reset the project history and abandon old versions of Groovy make it a complete non-starter.  Support for old versions is something that should be an absolute requirement.  If the Eclipse Foundation can not waive that requirement then they are not a good home for Groovy.

Keith

On Feb 11, 2015, at 11:29 AM, Cédric Champeau <[hidden email]> wrote:

Dear community,
Dear foundation representatives,

We all love Groovy and it is important for us to secure its future. You all have been recently warned that Pivotal, the company which sponsors 3 full time developers on Groovy, is going to stop that sponsorship by the end of March.

We also learnt that Codehaus is going to shut down, even if the date isn’t clear yet, but we need to move off the Codehaus infrastructure quickly. Codehaus is also important in Groovy history because Groovy was developed with the Codehaus Manifesto as the governance model.

There are discussions ongoing to find fundings for Groovy, especially finding companies willing to hire the core team, but whenever we find a new sponsor for our jobs or not, Groovy is going to move to a foundation. This is very important for the future of the language and the team is convinced that it has to be done as soon as possible, that is to say before end of March.

We have investigated several options and after a first review we are asking you to help us choose between 3 remaining candidates (in no particular order), because it has to be a decision driven by the community:


There are advantages and drawbacks for all of them. Some of the drawbacks of Apache and Eclipse are so important that it require us to “negotiate” with them, so let us summarize what is important, for us:

  • License should remain Apache License, version 2.0
  • Governance model. Apache and Eclipse come with their own governance model that we need to conform to. It may go as far as how and where deliverables are deployed. SFConservancy will let us define our own governance model.
  • Infrastructure: Apache and Eclipse come with their own infrastructure, that we can use and don’t have to maintain. It includes source repositories, website hosting, mailing lists, bug tracker,… SFConservancy doesn’t provide one but in turn will let us use the tools we want as long as we can pay the bills.
  • Funding: after the call for sponsorship, we received several offers from companies willing to donate to the project. It is still insufficient for us to be able to pay a full time developer, but it is still large enough to consider a foundation that will let us use those funds, for example to pay expenses to conferences, host the hardware infrastructure (for example for SFConservancy), marketing...
  • Sources need to be hosted on Git, and preferably we want to be able to continue working with GitHub, which has dramatically improved the number of contributions we got from the community
  • History. Eclipse for example will require us to fully reset project history. In fact, it requires us to do 2 things:
    • upgrade Antlr to version 4 (which is planned for Groovy 3 but still requires a lot of work)
    • abandon old versions of Groovy. It is in our opinion a very problematic problem because it means that we do not support old versions of Groovy anymore. No more maintenance of 2.x branches, not speaking about 1.8 and older. For a language, we consider this a very big issue. We need to be able to continue development of older versions.
  • Binary compatibility: While it is possible to change the Maven coordinates (group id/artifact id) of Groovy, it is totally impossible to break binary compatibility by changing the package names for example. There’s just too much code in the wild using Groovy everywhere. So we need to be able to stick with groovy.lang and org.codehaus.groovy.
  • Tooling. We spent a lot of time narrowing our build and release infrastructure. Releasing a new version of Groovy is more or less a click on a button that will build everything on TeamCity, deploy artifacts on Bintray, then synchronize on Maven Central and eventually publish to GVM. It is very nice if we can stick with that process as the primary process, and if necessary backup on the foundation infrastructure. We also use JIRA for bug tracking and it is an important thing for us to be able to use it as the primary bug report system (even if we know we have to migrate ASAP out of Codehaus)

SFConservancy has various advantages:

  • the governance model can be adapted (and made clearer) from the Codehaus Manifesto
  • focus is on individuals using our software rather than process and legal but still provides legal support
  • It acts as a fiscal sponsor and is able to accept funds dedicated to the project, allowing us to have, basically, a bank account for companies willing to donate to the Groovy project. It also supports tax-deductible donations which is more interesting for donators.
  • It will let us support older versions of Groovy as well as continue working with the tools we are used to

The main drawback of SFConservancy is money. Since it doesn’t provide any kind of infrastructure, we need to build it by our own. It’s not very hard but it will cost some time and money.

Eclipse and Apache offer a clearer governance approach, a brand many recognize, but also have some of the drawbacks we’ve mentioned already above. Our contacts at both Eclipse and Apache have been very interesting too, as their are some options around those drawbacks.

So to be clear, we’re not ruling out any of the options. We can accommodate some drawbacks, but not too many of them. We want to make the best decision and that’s why we are asking you, our users, our community, what you think and also invite representatives from those foundations to give their advices. We would like to thank those who already asked some of our questions privately, but now is time for an open discussion!

In any case, we have to move fast, but we do not decide everything by ourselves: applying doesn’t mean being accepted. Thanks for your thoughts and help!
-- 
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog


------------------------------
Research Associate
Department of Computer Science
Vassar College
Poughkeepsie, NY


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Moving Groovy to a Foundation

Emmanuel Lecharny
In reply to this post by Cédric Champeau
One important thing : The ASF provides a legal umbrella. That means each
individual is protected and cannot be sued intuitu personae. Not
necessarily a bad thing, those days. I'm quite sure the Eclipse
foundation offers such a protection too.

Emmanuel Lécharny

On Wed, Feb 11, 2015 at 5:29 PM, Cédric Champeau <[hidden email]> wrote:

Dear community,

Dear foundation representatives,


We all love Groovy and it is important for us to secure its future. You all have been recently warned that Pivotal, the company which sponsors 3 full time developers on Groovy, is going to stop that sponsorship by the end of March.


We also learnt that Codehaus is going to shut down, even if the date isn’t clear yet, but we need to move off the Codehaus infrastructure quickly. Codehaus is also important in Groovy history because Groovy was developed with the Codehaus Manifesto as the governance model.


There are discussions ongoing to find fundings for Groovy, especially finding companies willing to hire the core team, but whenever we find a new sponsor for our jobs or not, Groovy is going to move to a foundation. This is very important for the future of the language and the team is convinced that it has to be done as soon as possible, that is to say before end of March.


We have investigated several options and after a first review we are asking you to help us choose between 3 remaining candidates (in no particular order), because it has to be a decision driven by the community:



There are advantages and drawbacks for all of them. Some of the drawbacks of Apache and Eclipse are so important that it require us to “negotiate” with them, so let us summarize what is important, for us:


  • License should remain Apache License, version 2.0

  • Governance model. Apache and Eclipse come with their own governance model that we need to conform to. It may go as far as how and where deliverables are deployed. SFConservancy will let us define our own governance model.

  • Infrastructure: Apache and Eclipse come with their own infrastructure, that we can use and don’t have to maintain. It includes source repositories, website hosting, mailing lists, bug tracker,… SFConservancy doesn’t provide one but in turn will let us use the tools we want as long as we can pay the bills.

  • Funding: after the call for sponsorship, we received several offers from companies willing to donate to the project. It is still insufficient for us to be able to pay a full time developer, but it is still large enough to consider a foundation that will let us use those funds, for example to pay expenses to conferences, host the hardware infrastructure (for example for SFConservancy), marketing...

  • Sources need to be hosted on Git, and preferably we want to be able to continue working with GitHub, which has dramatically improved the number of contributions we got from the community

  • History. Eclipse for example will require us to fully reset project history. In fact, it requires us to do 2 things:

    • upgrade Antlr to version 4 (which is planned for Groovy 3 but still requires a lot of work)

    • abandon old versions of Groovy. It is in our opinion a very problematic problem because it means that we do not support old versions of Groovy anymore. No more maintenance of 2.x branches, not speaking about 1.8 and older. For a language, we consider this a very big issue. We need to be able to continue development of older versions.

  • Binary compatibility: While it is possible to change the Maven coordinates (group id/artifact id) of Groovy, it is totally impossible to break binary compatibility by changing the package names for example. There’s just too much code in the wild using Groovy everywhere. So we need to be able to stick with groovy.lang and org.codehaus.groovy.

  • Tooling. We spent a lot of time narrowing our build and release infrastructure. Releasing a new version of Groovy is more or less a click on a button that will build everything on TeamCity, deploy artifacts on Bintray, then synchronize on Maven Central and eventually publish to GVM. It is very nice if we can stick with that process as the primary process, and if necessary backup on the foundation infrastructure. We also use JIRA for bug tracking and it is an important thing for us to be able to use it as the primary bug report system (even if we know we have to migrate ASAP out of Codehaus)


SFConservancy has various advantages:


  • the governance model can be adapted (and made clearer) from the Codehaus Manifesto

  • focus is on individuals using our software rather than process and legal but still provides legal support

  • It acts as a fiscal sponsor and is able to accept funds dedicated to the project, allowing us to have, basically, a bank account for companies willing to donate to the Groovy project. It also supports tax-deductible donations which is more interesting for donators.

  • It will let us support older versions of Groovy as well as continue working with the tools we are used to


The main drawback of SFConservancy is money. Since it doesn’t provide any kind of infrastructure, we need to build it by our own. It’s not very hard but it will cost some time and money.


Eclipse and Apache offer a clearer governance approach, a brand many recognize, but also have some of the drawbacks we’ve mentioned already above. Our contacts at both Eclipse and Apache have been very interesting too, as their are some options around those drawbacks.


So to be clear, we’re not ruling out any of the options. We can accommodate some drawbacks, but not too many of them. We want to make the best decision and that’s why we are asking you, our users, our community, what you think and also invite representatives from those foundations to give their advices. We would like to thank those who already asked some of our questions privately, but now is time for an open discussion!


In any case, we have to move fast, but we do not decide everything by ourselves: applying doesn’t mean being accepted. Thanks for your thoughts and help!

-- 
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog




--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Moving Groovy to a Foundation

Marc Paquette
In reply to this post by Cédric Champeau
Hello, 

I prefer the Software Freedom Conservancy for the following reasons (in no particular order) :

* I see no problems with current governance on Groovy : it successfully delivered many quality releases, sound evolution of the language with pragmatic backward compatibility, open to discussion and to outside contributions.  This spirit must continue and from what I understand, the Software Freedom Conservancy would be the best for that.

* I truly admire the "eat-your-own-dog-food" principle and having to somehow pay for your own infrastructure is a powerful validator for this approach : using a certain number of groovy based technologies in the delivery toolchain, website presence, documentation, etc, has to be efficient or else valuable money that could go in the language would be wasted.  Also, it promotes innovation because the community is the ultimate judge on the value of some new piece of infrastructure, not on how it fits in a legacy, pre-existing, shared with other (possibly) disparate communities infrastructure stack.

* Git and github are awsome for collaboration.  History happened, it is part of the ecosystem, not an accident : resetting revision history on entering an umbrella organization is nonsensical to me.  Having groovy sources, with full history, in git seems trivial with the Software Freedom Conservancy.

So, my Canadian vote goes to the Software Freedom Conservancy !

A big thanks to core members of the groovy language, to Pivotal for their sponsorship and to the community for making this a joy to use and participate in.

-- 
Marc Paquette


Le 2015-02-11 à 11:29, Cédric Champeau <[hidden email]> a écrit :

We have investigated several options and after a first review we are asking you to help us choose between 3 remaining candidates (in no particular order), because it has to be a decision driven by the community:


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Moving Groovy to a Foundation

kyleboon
In reply to this post by Cédric Champeau
I think that removing history and not supporting old releases is too big of a price to pay, so for those reasons I would lean against the Eclipse Foundation.  

I do think that Apache and Eclipse provide a lot of valuable resources otherwise though.

I'm curious if any of the *other* JVM languages are a part of the Eclipse Foundation or Apache and what their experience has been if so.

Kyle
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Moving Groovy to a Foundation

Pid ster
In reply to this post by Suderman Keith-3




On 11 Feb 2015, at 18:28, Keith Suderman <[hidden email]> wrote:

I would suggest that Eclipse's requirement to reset the project history and abandon old versions of Groovy make it a complete non-starter.  Support for old versions is something that should be an absolute requirement.  If the Eclipse Foundation can not waive that requirement then they are not a good home for Groovy.

I'm sure there's a trade off - this thread will probably lead to elaboration on the details.



Keith

On Feb 11, 2015, at 11:29 AM, Cédric Champeau <[hidden email]> wrote:

Dear community,
Dear foundation representatives,

We all love Groovy and it is important for us to secure its future. You all have been recently warned that Pivotal, the company which sponsors 3 full time developers on Groovy, is going to stop that sponsorship by the end of March.

We also learnt that Codehaus is going to shut down, even if the date isn’t clear yet, but we need to move off the Codehaus infrastructure quickly. Codehaus is also important in Groovy history because Groovy was developed with the Codehaus Manifesto as the governance model.

There are discussions ongoing to find fundings for Groovy, especially finding companies willing to hire the core team, but whenever we find a new sponsor for our jobs or not, Groovy is going to move to a foundation. This is very important for the future of the language and the team is convinced that it has to be done as soon as possible, that is to say before end of March.

We have investigated several options and after a first review we are asking you to help us choose between 3 remaining candidates (in no particular order), because it has to be a decision driven by the community:


There are advantages and drawbacks for all of them. Some of the drawbacks of Apache and Eclipse are so important that it require us to “negotiate” with them, so let us summarize what is important, for us:

  • License should remain Apache License, version 2.0
  • Governance model. Apache and Eclipse come with their own governance model that we need to conform to. It may go as far as how and where deliverables are deployed. SFConservancy will let us define our own governance model.
  • Infrastructure: Apache and Eclipse come with their own infrastructure, that we can use and don’t have to maintain. It includes source repositories, website hosting, mailing lists, bug tracker,… SFConservancy doesn’t provide one but in turn will let us use the tools we want as long as we can pay the bills.
  • Funding: after the call for sponsorship, we received several offers from companies willing to donate to the project. It is still insufficient for us to be able to pay a full time developer, but it is still large enough to consider a foundation that will let us use those funds, for example to pay expenses to conferences, host the hardware infrastructure (for example for SFConservancy), marketing...
  • Sources need to be hosted on Git, and preferably we want to be able to continue working with GitHub, which has dramatically improved the number of contributions we got from the community
  • History. Eclipse for example will require us to fully reset project history. In fact, it requires us to do 2 things:
    • upgrade Antlr to version 4 (which is planned for Groovy 3 but still requires a lot of work)
    • abandon old versions of Groovy. It is in our opinion a very problematic problem because it means that we do not support old versions of Groovy anymore. No more maintenance of 2.x branches, not speaking about 1.8 and older. For a language, we consider this a very big issue. We need to be able to continue development of older versions.
  • Binary compatibility: While it is possible to change the Maven coordinates (group id/artifact id) of Groovy, it is totally impossible to break binary compatibility by changing the package names for example. There’s just too much code in the wild using Groovy everywhere. So we need to be able to stick with groovy.lang and org.codehaus.groovy.
  • Tooling. We spent a lot of time narrowing our build and release infrastructure. Releasing a new version of Groovy is more or less a click on a button that will build everything on TeamCity, deploy artifacts on Bintray, then synchronize on Maven Central and eventually publish to GVM. It is very nice if we can stick with that process as the primary process, and if necessary backup on the foundation infrastructure. We also use JIRA for bug tracking and it is an important thing for us to be able to use it as the primary bug report system (even if we know we have to migrate ASAP out of Codehaus)

SFConservancy has various advantages:

  • the governance model can be adapted (and made clearer) from the Codehaus Manifesto
  • focus is on individuals using our software rather than process and legal but still provides legal support
  • It acts as a fiscal sponsor and is able to accept funds dedicated to the project, allowing us to have, basically, a bank account for companies willing to donate to the Groovy project. It also supports tax-deductible donations which is more interesting for donators.
  • It will let us support older versions of Groovy as well as continue working with the tools we are used to

The main drawback of SFConservancy is money. Since it doesn’t provide any kind of infrastructure, we need to build it by our own. It’s not very hard but it will cost some time and money.

Eclipse and Apache offer a clearer governance approach, a brand many recognize, but also have some of the drawbacks we’ve mentioned already above. Our contacts at both Eclipse and Apache have been very interesting too, as their are some options around those drawbacks.

So to be clear, we’re not ruling out any of the options. We can accommodate some drawbacks, but not too many of them. We want to make the best decision and that’s why we are asking you, our users, our community, what you think and also invite representatives from those foundations to give their advices. We would like to thank those who already asked some of our questions privately, but now is time for an open discussion!

In any case, we have to move fast, but we do not decide everything by ourselves: applying doesn’t mean being accepted. Thanks for your thoughts and help!
-- 
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog


------------------------------
Research Associate
Department of Computer Science
Vassar College
Poughkeepsie, NY


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Moving Groovy to a Foundation

Winnebeck, Jason
In reply to this post by Suderman Keith-3

Are we missing some part of the rationale here – that is, is there a bigger consequence missing for the move to a foundation? I don’t understand why Eclipse (or anyone) would want to drop history, which is important for copyright attribution, mandate technical dependencies (ANTLR 4) or for that matter, how can it make sense to prohibit a project from maintaining old versions?

 

Otherwise, the argument boils down to “SFC gives us freedom but we have to set up our own infrastructure” – and the answer to that is one the community probably can’t answer – if you going to get enough time and money to dedicate to infrastructure then obviously from the viewpoint we’ve been presented here SFC is the best choice. Apache and Eclipse only make sense if the benefit of a pre-existing infrastructure lets you do more with Groovy, and out of those two, from your points alone, it sounds that Eclipse’s requirements are too onerous to accept.

 

Jason

 

From: Keith Suderman [mailto:[hidden email]]
Sent: Wednesday, February 11, 2015 12:56 PM
To: [hidden email]
Subject: Re: [groovy-user] Moving Groovy to a Foundation

 

I would suggest that Eclipse's requirement to reset the project history and abandon old versions of Groovy make it a complete non-starter.  Support for old versions is something that should be an absolute requirement.  If the Eclipse Foundation can not waive that requirement then they are not a good home for Groovy.

 

Keith

 

On Feb 11, 2015, at 11:29 AM, Cédric Champeau <[hidden email]> wrote:



Dear community,

Dear foundation representatives,

 

We all love Groovy and it is important for us to secure its future. You all have been recently warned that Pivotal, the company which sponsors 3 full time developers on Groovy, is going to stop that sponsorship by the end of March.

 

We also learnt that Codehaus is going to shut down, even if the date isn’t clear yet, but we need to move off the Codehaus infrastructure quickly. Codehaus is also important in Groovy history because Groovy was developed with the Codehaus Manifesto as the governance model.

 

There are discussions ongoing to find fundings for Groovy, especially finding companies willing to hire the core team, but whenever we find a new sponsor for our jobs or not, Groovy is going to move to a foundation. This is very important for the future of the language and the team is convinced that it has to be done as soon as possible, that is to say before end of March.

 

We have investigated several options and after a first review we are asking you to help us choose between 3 remaining candidates (in no particular order), because it has to be a decision driven by the community:

 

  • The Eclipse Foundation, home of Eclipse, vert.x, AspectJ and a lot of tooling related OSS projects

 

There are advantages and drawbacks for all of them. Some of the drawbacks of Apache and Eclipse are so important that it require us to “negotiate” with them, so let us summarize what is important, for us:

 

  • License should remain Apache License, version 2.0
  • Governance model. Apache and Eclipse come with their own governance model that we need to conform to. It may go as far as how and where deliverables are deployed. SFConservancy will let us define our own governance model.
  • Infrastructure: Apache and Eclipse come with their own infrastructure, that we can use and don’t have to maintain. It includes source repositories, website hosting, mailing lists, bug tracker,… SFConservancy doesn’t provide one but in turn will let us use the tools we want as long as we can pay the bills.
  • Funding: after the call for sponsorship, we received several offers from companies willing to donate to the project. It is still insufficient for us to be able to pay a full time developer, but it is still large enough to consider a foundation that will let us use those funds, for example to pay expenses to conferences, host the hardware infrastructure (for example for SFConservancy), marketing...
  • Sources need to be hosted on Git, and preferably we want to be able to continue working with GitHub, which has dramatically improved the number of contributions we got from the community
  • History. Eclipse for example will require us to fully reset project history. In fact, it requires us to do 2 things:
    • upgrade Antlr to version 4 (which is planned for Groovy 3 but still requires a lot of work)
    • abandon old versions of Groovy. It is in our opinion a very problematic problem because it means that we do not support old versions of Groovy anymore. No more maintenance of 2.x branches, not speaking about 1.8 and older. For a language, we consider this a very big issue. We need to be able to continue development of older versions.
  • Binary compatibility: While it is possible to change the Maven coordinates (group id/artifact id) of Groovy, it is totally impossible to break binary compatibility by changing the package names for example. There’s just too much code in the wild using Groovy everywhere. So we need to be able to stick with groovy.lang and org.codehaus.groovy.
  • Tooling. We spent a lot of time narrowing our build and release infrastructure. Releasing a new version of Groovy is more or less a click on a button that will build everything on TeamCity, deploy artifacts on Bintray, then synchronize on Maven Central and eventually publish to GVM. It is very nice if we can stick with that process as the primary process, and if necessary backup on the foundation infrastructure. We also use JIRA for bug tracking and it is an important thing for us to be able to use it as the primary bug report system (even if we know we have to migrate ASAP out of Codehaus)

 

SFConservancy has various advantages:

 

  • the governance model can be adapted (and made clearer) from the Codehaus Manifesto
  • focus is on individuals using our software rather than process and legal but still provides legal support
  • It acts as a fiscal sponsor and is able to accept funds dedicated to the project, allowing us to have, basically, a bank account for companies willing to donate to the Groovy project. It also supports tax-deductible donations which is more interesting for donators.
  • It will let us support older versions of Groovy as well as continue working with the tools we are used to

 

The main drawback of SFConservancy is money. Since it doesn’t provide any kind of infrastructure, we need to build it by our own. It’s not very hard but it will cost some time and money.

 

Eclipse and Apache offer a clearer governance approach, a brand many recognize, but also have some of the drawbacks we’ve mentioned already above. Our contacts at both Eclipse and Apache have been very interesting too, as their are some options around those drawbacks.

 

So to be clear, we’re not ruling out any of the options. We can accommodate some drawbacks, but not too many of them. We want to make the best decision and that’s why we are asking you, our users, our community, what you think and also invite representatives from those foundations to give their advices. We would like to thank those who already asked some of our questions privately, but now is time for an open discussion!

 

In any case, we have to move fast, but we do not decide everything by ourselves: applying doesn’t mean being accepted. Thanks for your thoughts and help!

-- 
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog
 

 

------------------------------

Research Associate
Department of Computer Science
Vassar College
Poughkeepsie, NY

 


This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Moving Groovy to a Foundation

chrismattmann
This post has NOT been accepted by the mailing list yet.
In reply to this post by kyleboon
I should also point you guys at the links to how to bring a project into the ASF:

http://incubator.apache.org/guides/proposal.html

I for one wearing my ASF board hat would welcome you guys to the foundation.

If you need help as an ASF mentor for the project let me know.

Cheers!
Chris
1234 ... 20
Loading...