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:
In reply to this post by Winnebeck, Jason
On Wed, Feb 11, 2015 at 7:39 PM, Winnebeck, Jason <[hidden email]> wrote:
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.
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 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:
SFConservancy has various advantages:
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
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!
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:
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:
In reply to this post by Vladimír Oraný-2
2015-02-12 9:03 GMT+01:00 Vladimír Oraný <[hidden email]>:
In one word: securing the project.
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.
I am very happy that we have a static site, but there's more than just pages: redirects, documentation for old versions, downloads, ...
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.
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).
And what if Google decides to shutdown groups? It's not as if they weren't used to shutdown projects people use :)
Setting up the infrastructure is probably no big deal. Maintaining it is another.
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]>:
On Thu, Feb 12, 2015 at 9:24 AM, Cédric Champeau <[hidden email]> wrote:
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.
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:
To unsubscribe from this list, please visit:
|Free forum by Nabble||Edit this page|