In reply to this post by Keith Suderman 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 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) 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. abandon old versions of Groovy. It is in our opinion aproblem 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 groovy.lang and org.codehaus.groovy. : 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 withand 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.

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.