Moving Groovy to a Foundation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
199 messages Options
12345 ... 20
Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

Scott Hickey-2
Let me preface what I offer with I trust you three to make a good choice and you won't hear me complain, whatever you decide.

It's seems like you've already put this out there: It would be horrible to rename packages at this point. Some of my clients have built systems with Groovy for 10 years. It would be cruel to do something that disruptive to the ecosystem.

In general, I think it is really, really hard to build momentum and keep it going in an open source project. The longevity of both Groovy and Grails is extremely impressive. I think it is easy to take this for granted. In some ways, projects are more resilient than we might expect. But in other ways, they are more fragile than you'd think. Little changes, like learning a new version control system, new build system, new bug tracking system, etc... force people to change habits. It is amazing how disruptive it can be and how quickly some will stop participating. So, I would suggest that when considering the pros and cons of various options, don't underestimate the value of minimizing the visible changes to the way things are done today. Make it as easy as possible on yourselves and others to keep as much of the tooling and processes in place. There will enough other change to deal with as it is.

just my 2 cents...

On Wed, Feb 11, 2015 at 11:56 AM, 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.

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
|

Re: Moving Groovy to a Foundation

Emmanuel Lecharny
In reply to this post by Winnebeck, Jason


On Wed, Feb 11, 2015 at 7:39 PM, Winnebeck, Jason <[hidden email]> wrote:

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?


Legal aspects.For eclipse, which is backed by IBM, Oracle and many other big COs, it all boils down to avoid being sued. They are pretty paranoid about it.

Reply | Threaded
Open this post in threaded view
|

RE: Moving Groovy to a Foundation

Ske ptic
In reply to this post by Cédric Champeau
Have you considered what the other projects at Codehaus are doing ? (I don't know if there is any other active project there).

Can you explain why moving to Eclipse would need to switch to ANTLR 4 ?


Date: Wed, 11 Feb 2015 17:29:04 +0100
From: [hidden email]
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:



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
|

RE: Moving Groovy to a Foundation

o0karen0o
This post has NOT been accepted by the mailing list yet.
In reply to this post by David M. Karr
Conservancy would be thrilled to get an application (you can also do this while you pursue other options in parallel). Infrastructure is dealt with differently in our different projects depending on their needs and resources, and we'd be happy to talk about it.  A lot of infrastructure issues are much less of an issue now than they used to be, this isn't usually an obstacle for our projects.

We're in #conservancy on freenode a lot of the time, so feel free to drop by and ask any questions you may have!
Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

Vladimír Oraný-2
In reply to this post by Ske ptic
I don't really follow the not-providing-infrastructure problem. Why should a successful open source project need any own/maintained infrastructure in 2015?

Why do you need another source repository? Will anyone kick you out of GitHub? Well you'll just create a fork under new organization ;-)
Isn't new Groovy website static site which can be hosted using GitHub Pages?
Will JetBrains stop providing you TeamCity when the Pivotal funding is over?
Do you really need JIRA? If so, why not take an advantage of Atlassian free open source license for cloud instances?
Mailing list? Nothing what Google Groups or STO can replace.

I wouldn't see the missing infrastructure of SFConservancy as that big drawback as it looks to you.




On Wed Feb 11 2015 at 20:29:05 Skeptic . <[hidden email]> wrote:
Have you considered what the other projects at Codehaus are doing ? (I don't know if there is any other active project there).

Can you explain why moving to Eclipse would need to switch to ANTLR 4 ?


Date: Wed, 11 Feb 2015 17:29:04 +0100
From: [hidden email]
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:



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
|

Re: Moving Groovy to a Foundation

Alessio Stalla
I was going to say the same thing as Vladimír :)

I read Cédric's first email like this: SFConservancy has almost no drawbacks, Eclipse has a lot of nasty ones impacting both governance and technology, Apache is not clear but it is said to be in the same league as Eclipse. Clearly given that information my opinion can only be favourable to SFConservancy.
However, since you're asking the community to make a decision, you should make sure that it is a sufficiently informed decision and provide all details about benefits and drawbacks of each proposed solution, even if the resulting document turns out long and boring.

On Thu, Feb 12, 2015 at 9:03 AM, Vladimír Oraný <[hidden email]> wrote:
I don't really follow the not-providing-infrastructure problem. Why should a successful open source project need any own/maintained infrastructure in 2015?

Why do you need another source repository? Will anyone kick you out of GitHub? Well you'll just create a fork under new organization ;-)
Isn't new Groovy website static site which can be hosted using GitHub Pages?
Will JetBrains stop providing you TeamCity when the Pivotal funding is over?
Do you really need JIRA? If so, why not take an advantage of Atlassian free open source license for cloud instances?
Mailing list? Nothing what Google Groups or STO can replace.

I wouldn't see the missing infrastructure of SFConservancy as that big drawback as it looks to you.




On Wed Feb 11 2015 at 20:29:05 Skeptic . <[hidden email]> wrote:
Have you considered what the other projects at Codehaus are doing ? (I don't know if there is any other active project there).

Can you explain why moving to Eclipse would need to switch to ANTLR 4 ?


Date: Wed, 11 Feb 2015 17:29:04 +0100
From: [hidden email]
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:



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
|

Re: Moving Groovy to a Foundation

Cédric Champeau
In reply to this post by Vladimír Oraný-2


2015-02-12 9:03 GMT+01:00 Vladimír Oraný <[hidden email]>:
I don't really follow the not-providing-infrastructure problem. Why should a successful open source project need any own/maintained infrastructure in 2015?

In one word: securing the project.
Why do you need another source repository? Will anyone kick you out of GitHub? Well you'll just create a fork under new organization ;-)

GitHub is a private company. They could shutdown, be attacked, ... and we wouldn't have a backup. For now we mirror all sources on Codehaus but it is going to shutdown.

Isn't new Groovy website static site which can be hosted using GitHub Pages?
I am very happy that we have a static site, but there's more than just pages: redirects, documentation for old versions, downloads, ...
Will JetBrains stop providing you TeamCity when the Pivotal funding is over?

It's not planned but in any case who will maintain the server? Who will have time to do the usual housekeeping? For now it was me, but if we don't find a company that will pay us full time to work on Groovy this is going to become complicated.
 
Do you really need JIRA? If so, why not take an advantage of Atlassian free open source license for cloud instances?
Yes, we can. But depending on the target foundation it may or may not be a problem. In any case that is our #1 plan for migrating the current server, even if we have no idea how to proceed without support from Codehaus (btw, what is happening at Codehaus also perfectly illustrates what can happen with a custom infrastructure).
 
Mailing list? Nothing what Google Groups or STO can replace.

And what if Google decides to shutdown groups? It's not as if they weren't used to shutdown projects people use :)
 
I wouldn't see the missing infrastructure of SFConservancy as that big drawback as it looks to you.

Setting up the infrastructure is probably no big deal. Maintaining it is another.



On Wed Feb 11 2015 at 20:29:05 Skeptic . <[hidden email]> wrote:
Have you considered what the other projects at Codehaus are doing ? (I don't know if there is any other active project there).

Can you explain why moving to Eclipse would need to switch to ANTLR 4 ?


Date: Wed, 11 Feb 2015 17:29:04 +0100
From: [hidden email]
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:



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
|

Re: Moving Groovy to a Foundation

Cédric Champeau
In reply to this post by Alessio Stalla
Regarding Eclipse we have ongoing discussions with regards to the full reset, apparently it could be possible not to do it, even though I fail to see how it would be possible without loosing the legal aspects that Eclipse ensures with a reset.

For Apache, main issues are how to collect donations/assets and reuse them, but it also seems that there are discussions around it, unclear too. And there's also the problem of whether sources/binaries need to be first on Apache then on GitHub/Bintray or if the opposite is possible (mirror on Apache). It sounds a bit complicated so far.

2015-02-12 9:12 GMT+01:00 Alessio Stalla <[hidden email]>:
I was going to say the same thing as Vladimír :)

I read Cédric's first email like this: SFConservancy has almost no drawbacks, Eclipse has a lot of nasty ones impacting both governance and technology, Apache is not clear but it is said to be in the same league as Eclipse. Clearly given that information my opinion can only be favourable to SFConservancy.
However, since you're asking the community to make a decision, you should make sure that it is a sufficiently informed decision and provide all details about benefits and drawbacks of each proposed solution, even if the resulting document turns out long and boring.

On Thu, Feb 12, 2015 at 9:03 AM, Vladimír Oraný <[hidden email]> wrote:
I don't really follow the not-providing-infrastructure problem. Why should a successful open source project need any own/maintained infrastructure in 2015?

Why do you need another source repository? Will anyone kick you out of GitHub? Well you'll just create a fork under new organization ;-)
Isn't new Groovy website static site which can be hosted using GitHub Pages?
Will JetBrains stop providing you TeamCity when the Pivotal funding is over?
Do you really need JIRA? If so, why not take an advantage of Atlassian free open source license for cloud instances?
Mailing list? Nothing what Google Groups or STO can replace.

I wouldn't see the missing infrastructure of SFConservancy as that big drawback as it looks to you.




On Wed Feb 11 2015 at 20:29:05 Skeptic . <[hidden email]> wrote:
Have you considered what the other projects at Codehaus are doing ? (I don't know if there is any other active project there).

Can you explain why moving to Eclipse would need to switch to ANTLR 4 ?


Date: Wed, 11 Feb 2015 17:29:04 +0100
From: [hidden email]
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:



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
|

Re: Moving Groovy to a Foundation

Emmanuel Lecharny


On Thu, Feb 12, 2015 at 9:24 AM, Cédric Champeau <[hidden email]> wrote:
And there's also the problem of whether sources/binaries need to be first on Apache then on GitHub/Bintray or if the opposite is possible (mirror on Apache). It sounds a bit complicated so far.

It's crystal clear, and simple : The ASF *has* to be the reference repository. The ASF delivers sources, nothing more. Whatever tool you are using is irrelevant. The idea is that anyone should be able to grab the sources from one place and be confident that those sources have been endorsed by The ASF as an official release.

That makes it quite easy when it comes to use a distributed source control system, as it's just a matter of having an up to date clone at The ASF.

The second important things is that, as The ASF offers a legal umbrella for people working on the project, it has to be sure all the changes comes from people allowed to push code to the ASF repo.


Keep in mind that The ASF is likely to exist long after Github has disapeared or been bought by - pick on in IBM/Oracle/M$... -. The very same for Atlasian, or any private company which may have a hidden agenda (or will have at any point in their future). Those are some of the reason foundation like Apache or Eclipse exist : to offer a neutral bed for you guys.


Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

Dinko Srkoč
In reply to this post by Cédric Champeau
On 12 February 2015 at 09:12, Cédric Champeau <[hidden email]> wrote:
> [...]
>> Mailing list? Nothing what Google Groups or STO can replace.
>>
> And what if Google decides to shutdown groups? It's not as if they weren't
> used to shutdown projects people use :)
>

For what it's worth, Scala moved their mailing lists to Google Groups
about four years ago:
http://www.scala-lang.org/old/node/8392.html

Cheers,
Dinko

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


12345 ... 20