It’s Groovy to join a Foundation

The contributors behind the awesome Groovy project are looking for a new home. It’s bad news that the project and some of its core contributors will no longer be sponsored (paid for) by Pivotal, but it’s great that the core contributors are organized and serious about moving their project to an existing Foundation.

As a long time Apache Member (among other things), I have a few suggestions for the Groovy community.

Joining a Foundation is Good

You’ve already taken the most important step: choosing to join an existing Foundation. Although each option comes with some compromises or tradeoffs, I assure you any would be far superior to forming your own new non-profit corporation to be your legal home. Forming a new corporation is a lot of work, requiring a different energy and skill set than most developers have; this would significantly diminish the time that your contributors could spend actually focusing on the code. All three of the proposed options – Apache, Eclipse, and the Conservancy – have long and successful histories of providing all the things a Foundation can provide for open source projects: legal support, infrastructure, community and governance models, and a stable and well-branded place to call home.

Yawn…those things don’t sound particularly exciting, do they? In general, those aspects aren’t very exciting for most developers. But having a legal and stable home is critical if you want to manage your own project’s future, and not have it dictated by a single for-profit company. Or worse, slowly lose your way due to lack of contributors, and eventually, lack of users.

Talk To People

Clearly the Groovy core contributors have already considered a lot of the potential issues related to joining a Foundation, and have agreed on some basic requirements (which look great!). However, your community’s current understanding of how the three Foundations work appears to be mainly based on the available documentation from the Foundations, and not necessarily first-hand experience.

By far the most useful advice I can give is to have enough of your core contributors talk directly to some representatives of each Foundation (as some of you have already been doing). It’s likely that a number of your initial concerns won’t be as hard to deal with as you think, especially if you are clear and open in your communications with Foundation representatives. Make sure you have enough clear and direct information from the Foundation representatives – and your core contributors have time to truly discuss the input together – before making your final decision.

Who owns the Groovy Trademark?

In your planning, be sure not to overlook this essential issue. Who owns the GROOVY trademark? While it may seem obvious to developers and contributors, it may not be clear to the lawyers and marketing VPs of various companies who might be interested in using Groovy or contributing to the project in the future. Is Pivotal (and/or Codehaus, depending on who hosted the past software releases) willing to sign the trademarks over to your new legal home (once you choose one)? While open source code is infinitely forkable, trademarks aren’t. For example, the Apache License may be permissive regarding use of an individual project’s code, but explicitly does not license the project’s trademark(s). Likewise, most of your users know the language as “Groovy.” If Pivotal decided to keep the trademark (which seems unlikely, thankfully), you’d still be perfectly welcome to fork the code, but under a new name. Not Groovy. The apparent notoriety of the recent io.js fork notwithstanding, getting new contributors to a newly branded project is hard.

Who is your core Decision Making Community / Governance?

It’s great that your core contributors are thinking this through, defining the mission of the project community, and weighing the options carefully. This is a time where you’ll need to start developing a more detailed governance model; particularly the required members of the top decision making body. When your project is living without the direct umbrella of a company, you’ll need to have a specific list of the individual people who make governance decisions.

There is a clear difference between the Apache/Eclipse governance models and the Conservancy governance model. Conservancy essentially serves as a legal place to hang your project, with a hands-off approach that allows each project to develop their own self-governance models. Apache and Eclipse have detailed policies mandating how major decisions are made within a project (for example, inviting new committers or making formal software releases). In their models, a Project Management Committee (PMC) made up of individuals casts binding votes according to standard voting rules. Most decisions are still made by consensus of PMC members – probably how Groovy already operates. The details of voting rules really only come into play when the project team can’t reach a happy consensus, or when making formal software releases (in the later case, having clear votes by the policy ensures that the release is an act of the project, not of just an individual).

In addition to the project governance policies, Apache and Eclipse have an overarching board of directors to provide oversight that the core rules really are being followed consistently for every software release.

One slight difference between the Eclipse and Apache governance models is the role of the project leaders. Apache PMC members each have one vote, and all members of the PMC are peers. Technical direction is purely project-driven at both Apache and Eclipse; the board and officers never interfere with technical decisions. At Eclipse, there is a “Project Lead” role for each project, and that individual has greater influence over decision making. There are also Eclipse-wide Planning and Architecture Councils, which work to establish policies and processes for all projects, and the schedule for the annual Eclipse release train.

Infrastructure, Sources, History, And Tooling

Each of these areas requires attention, and I have some initial thoughts:

  • Infrastructure: If you like Conservancy, could you find another company (such as OSUOSL?) to provide the physical hosting for you?
  • Sources: While Apache requires the canonical repo to be on ASF hardware (to ensure the project is master of it’s own fate), there are plenty of ways to mirror to github or elsewhere.
  • History: If you really like Eclipse, then even if you did have to reset history, couldn’t you find some way to host a static version of the previous history somewhere for reference?

These are certainly issues that take effort, but it’s more important to ensure that the core people actually driving your community can find a stable home Foundation to settle in for the future.

Funding

For those potentially losing their Pivotal jobs, this is a key question, and one that’s certainly not easy, either on a personal level, or on a project and community level. Be sure you’re all clear on how and why you’re making decisions related to funding. For the Groovy community, this transition is clearly much more than a group of dedicated people doing this as their paid job, who are hoping to find new jobs together; you have built a coherent community that must find a long-term home for your project.

For the overall project, this is an exciting opportunity. With a full community, including both individuals as well as companies (contributing through the actions of their employees), you can have a long-term independent project. Right now, managed within the Pivotal framework, Groovy is at the mercy of Pivotal’s internal business decisions. To succeed as an independent project, you need to have a foundation to own the brand and provide (at least minimal) governance, and you need to draw enough interest from software companies so that they’ll either contribute work, or be interested in hiring your contributors.

Here also your three Foundation choices are very different. Conservancy will provide you with a 501C3 fundraising structure through which you can raise money to pay your contributors to develop code, but there may be limits to how much active fundraising support they can realistically give to you. Eclipse, as a 501C6, has a more corporate-focused funding model. They also seem likely to have more staff to help connect the core project contributors to companies potentially interested in funding more development. Apache is a 501C3, but the governance does not allow direct funding of project development by for-profit companies. Work on Apache projects is either performed by independents, or by employees of various companies; projects that don’t attract any company-sponsored contributors tend to stagnate; however for projects that stay relevant, it results in longer lived and strongly independent projects.

Good luck!

Whichever Foundation you choose, I wish you the best of luck. Open source has come a long way in the past twenty years. Licenses are well understood, and business and individuals everywhere frequently rely on open source projects for everyday things. And now with the long-term success of Apache, Eclipse, Conservancy, and many other non-profit open source Foundations, we are starting to have a decent understanding of some of the great governance and project management models we’ve developed.

This post also appears on Medium. Thanks to @mmilinkov for minor updates re: Eclipse.

One thought on “It’s Groovy to join a Foundation

  1. Pingback: Groovy Latest: Double Release Drop and Foundation Deliberations | Voxxed

What do you think?