Moving Groovy to a Foundation

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

Re: Moving Groovy to a Foundation

Robert Oschwald
Grails also moved to GG.

Sent while mobile.

> Am 12.02.2015 um 11:36 schrieb Dinko Srkoč <[hidden email]>:
>
>> 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
>
>

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

Matthias F. Brandstetter
True. But it is also true that Google more than once has shut down one of their free services, even though many thousands have used it (see their Reader for example). But on the other hand, Google surely is one of the more reliable service providers out there ...

Just my 2 cents though :-)


On 12 February 2015 at 11:48, Robert Oschwald <[hidden email]> wrote:
Grails also moved to GG.

Sent while mobile.

> Am 12.02.2015 um 11:36 schrieb Dinko Srkoč <[hidden email]>:
>
>> 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
>
>

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

    http://xircles.codehaus.org/manage_email





--
Matthias F. Brandstetter
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

Jochen Theodorou
In reply to this post by Cédric Champeau
to add on what Cedric said

Am 11.02.2015 17:29, schrieb Cédric Champeau:
[...]
>   * The Apache Software Foundation <http://www.apache.org>, home of
>     Apache HTTP server, Lucene, Spark and lots of famous OSS projects
>   * The Eclipse Foundation <https://eclipse.org>, home of Eclipse,
>     vert.x, AspectJ and a lot of tooling related OSS projects
>   * The Software Freedom Conservancy <http://sfconservancy.org>, home of
>     Git, Mercurial, PyPy and many other OSS projects

I must say I was a long time not happy with the idea moving there. In my
opinion a ASF project works long term only with a company backing the
developers. ASF itself does not provide anything to help with that,
meaning the developers either have to be part of the companies behind
it, or finance themselves using an outside organization. I perceive this
as a disconnection and was not happy with it. But if you think about it,
the same probably counts for the Eclipse Foundation as well. The model
that was suggested by the eclipse foundation will require a minimal
money flow as well.

In both cases Groovy would become a top level project, but at least in
the case of Apache we have to go through the incubation process, even if
we can do a fast tracked one here. Moving to Apache requires us using
primarily using their bugtracker, repository and mailing lists for legal
reasons. If we for example decide now to move to google groups to have a
solution for the time being, then we would have to move the mailing
lists again later on if we go to apache. At least on apache we can
import our existing jira and keep the bug tracker history

The package naming is a problem. groovy.lang can stay in both cases, but
they have their branding and that requires to change from org.codehaus
to eclipse or apache. Also this point is difficult to negotiate, since
it is part of... well corporate identity is the wrong name for it I
would say, but it goes in the same direction. Of course we would have
benefits from the branding, but it comes not for free.

I was always for eclipse in the past, mainly because the most apache
stuff, that is not driven by companies, looks quite dusted to me. But
requiring a history wipe at eclipse... that's a nogo for me.

If org.codehaus package name change, removing old versions and history
wipe is a nogo, then the Software Freedom Conservancy is the only option
left. Unless I missed something important and those points suddenly can
be negotiated in our favor.

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

jimjag
In reply to this post by Emmanuel Lecharny
Just to be even more clear, the reason behind the requirement that the ASF repo be the canonical/reference repo is due to the legal ramifications of doing an actual release. Recall that it is when a release is actually done, and distributed, is when the developer opens themselves to potential litigation, and it's when having the legal protection of a foundation is the most important. For the protection to exist, exacting IP provenance is required, and that is only possible when the repo itself is under the full control of the foundation, and not an external 3rd party.
Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

jn0rthr
In reply to this post by Jochen Theodorou
did not twig that there would be a package name change from org.codehaus :-P


On 12/02/15 13:13, Jochen Theodorou wrote:

> to add on what Cedric said
>
> Am 11.02.2015 17:29, schrieb Cédric Champeau:
> [...]
>>   * The Apache Software Foundation <http://www.apache.org>, home of
>>     Apache HTTP server, Lucene, Spark and lots of famous OSS projects
>>   * The Eclipse Foundation <https://eclipse.org>, home of Eclipse,
>>     vert.x, AspectJ and a lot of tooling related OSS projects
>>   * The Software Freedom Conservancy <http://sfconservancy.org>, home of
>>     Git, Mercurial, PyPy and many other OSS projects
>
> I must say I was a long time not happy with the idea moving there. In
> my opinion a ASF project works long term only with a company backing
> the developers. ASF itself does not provide anything to help with
> that, meaning the developers either have to be part of the companies
> behind it, or finance themselves using an outside organization. I
> perceive this as a disconnection and was not happy with it. But if you
> think about it, the same probably counts for the Eclipse Foundation as
> well. The model that was suggested by the eclipse foundation will
> require a minimal money flow as well.
>
> In both cases Groovy would become a top level project, but at least in
> the case of Apache we have to go through the incubation process, even
> if we can do a fast tracked one here. Moving to Apache requires us
> using primarily using their bugtracker, repository and mailing lists
> for legal reasons. If we for example decide now to move to google
> groups to have a solution for the time being, then we would have to
> move the mailing lists again later on if we go to apache. At least on
> apache we can import our existing jira and keep the bug tracker history
>
> The package naming is a problem. groovy.lang can stay in both cases,
> but they have their branding and that requires to change from
> org.codehaus to eclipse or apache. Also this point is difficult to
> negotiate, since it is part of... well corporate identity is the wrong
> name for it I would say, but it goes in the same direction. Of course
> we would have benefits from the branding, but it comes not for free.
>
> I was always for eclipse in the past, mainly because the most apache
> stuff, that is not driven by companies, looks quite dusted to me. But
> requiring a history wipe at eclipse... that's a nogo for me.
>
> If org.codehaus package name change, removing old versions and history
> wipe is a nogo, then the Software Freedom Conservancy is the only
> option left. Unless I missed something important and those points
> suddenly can be negotiated in our favor.
>
> bye blackdrag
>


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

mmilinkov
In reply to this post by Cédric Champeau
Cédric,

It seems that you and the team have already decided on moving to the Software Conservancy. I do agree that it would make an excellent home for Groovy, and have nothing but good things to say about them, and the services they provide. Although I think that Eclipse would make an excellent home for Groovy, I don't see how it is in anyone's interest to get into a "sales job".

Good luck to you and the Groovy team. I wish you all the best in these difficult times.

P.S. As I told you in our previous private conversation we would have found a solution to the history issue.
Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

jimjag
In reply to this post by Jochen Theodorou
Jochen Theodorou wrote
to add on what Cedric said

I must say I was a long time not happy with the idea moving there. In my
opinion a ASF project works long term only with a company backing the
developers. ASF itself does not provide anything to help with that,
meaning the developers either have to be part of the companies behind
it, or finance themselves using an outside organization. I perceive this
as a disconnection and was not happy with it.
That's a shame because by building a larger, healthy community around a project is exactly the way to avoid the situation Groovy has found itself in. By depending on companies to fund a project, you will always run the risk, as it happened now, that their priorities will change. And by creating a community which is a level, even playing ground, more diverse corporate sponsorship will arise as well.

The ASF is built around creating a self-sustaining community, one that survives the ebb and flow of developers but also corporate whims.
Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

jimjag
In reply to this post by jn0rthr
What if someone else grabs codehaus.org at some point in time and *requires* you to change it? You have to bite the bullet at sometime and make the package name change... Might as well do it now.
Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

Steve Amerige
In reply to this post by Cédric Champeau
Hi all,

Just some "business acceptance" thoughts:
  • The license is extremely important.  Businesses need to be able to deliver to the field production code, appliances, VMs, containers, etc. that have not just Groovy code, but also Groovy compilers, etc. without this creating a requirement to open source anything or to otherwise be forced into positions that harm company offerings.  This concern should be addressed in an uncompromising manner as it underpins the acceptability of Groovy to the business community that would use Groovy.
  • Growth of Groovy is very important as well.  Groovy has to be able to grow in new, and perhaps unexpected ways.  Any foundation that would restrict Groovy's growth must be taken to be a negative.
  • Integration of Groovy with Java is important to allow companies to transition to, or include in part, Groovy code.  Any foundation that would restrict Groovy's integration with Java must be taken to be a negative.  Similarly, Groovy integration with critical verticals such as Grails needs to be upheld.
  • Authoritative voices are needed not just for the technical community, but also to serve marketing imperatives, lead conferences, and help encouraging third-party activities (companies providing vertical applications, paid-language support, etc.). We earnestly hope that our Groovy leaders can find funding for their continued roles as Groovy leaders providing essential public relations.  Any foundation that would help assist this happening must be taken to be a positive.
Other issues that have been raised are important as well (delivery methods, etc.), but I wanted to address some key concerns from the business community that we hope can be accommodated.

\Best regards,
Steve Amerige
Principal Software Developer, Fraud and Compliance Solutions Development
SAS Institute, 100 SAS Campus Dr, Room U3050, Cary, NC 27513-8617


In short, my biggest concerns

On 2/11/2015 11:29 AM, Cédric Champeau 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


Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

Alessio Stalla
In reply to this post by jimjag
Renaming packages is a completely breaking change. Both source *and* binary compatibility would be lost, third-party tools might stop working. I'd avoid that unless there were strong reasons not to.

If Pivotal hadn't funded Groovy till now, they would most probably be in a worse position. Less development would have been done. So "companies can shift priorities or disappear" is not a good reason not to be funded by a company. You should just have a reasonable plan in case the company goes bust or Donkey Kong Jr. buys it and decides to reinvent it as a major banana import dealer.

On Thu, Feb 12, 2015 at 2:30 PM, jimjag <[hidden email]> wrote:
What if someone else grabs codehaus.org at some point in time and *requires*
you to change it? You have to bite the bullet at sometime and make the
package name change... Might as well do it now.



--
View this message in context: http://groovy.329449.n5.nabble.com/Moving-Groovy-to-a-Foundation-tp5722483p5722529.html
Sent from the groovy - user mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email



123456 ... 20