Eclipse and Social Coding FAQ

Last updated June 20, 2013

Table of Contents

  1. What is the Eclipse Foundation doing?
  2. Why is the Eclipse Foundation doing this?
  3. Why would making use of this program be good for my project?
  4. If their day-to-day development is hosted someplace else, are these really Eclipse projects?
  5. Does this affect the independence of the Eclipse Foundation?
  6. Which third-party forges are you going to support?
  7. This sounds interesting, and it’s something I might want to do eventually. How can I make sure that my GitHub project could take advantage of this in the future?
  8. Any limitations I should know about?
  9. Does this only apply to projects written in Java or using the Eclipse plug-in model?
  10. Where will issues be tracked?
  11. What about the other community-facing services such as mailing lists, wikis, etc.?
  12. When can my existing Eclipse Foundation project move to github?
  13. I’m working on an existing Eclipse project. Does this mean I have to move?
  14. This is cool! Who can I talk to about bringing my project to the Eclipse community?

FAQ

  1. What is the Eclipse Foundation doing?

    The Eclipse Foundation is going to start allowing projects host their mainline development on third party forges such as GitHub, and Bitbucket. This means that an Eclipse project will be able to leverage many of the great development support tools provided by those vendors. The first project that we are going to work with on this is vert.x, which has been hosted on GitHub since its inception. Our intent is to start small, and continually improve this program and our support of it. The vert.x project has kindly agreed to be our guinea pig in this experiment.

    Projects which choose to take advantage of this will be hosting their mainline development remotely, but all of their code will be mirrored back to Eclipse’s git repositories. The full Eclipse development and IP processes will be applied to these projects. Project metadata, plans, committer records and votes will be maintained in the Eclipse project management infrastructure (PMI). Admin rights to the repos will be owned by the Eclipse Foundation webmaster team.

    Initially, most of this will be maintained manually, but over time we expect to automate a great deal of it. For example, initially checking that a pull request’s author has signed an Eclipse CLA will be done manually by the project committer accepting the contribution. Over time that will be automated using git commit hooks.
  2. Why is the Eclipse Foundation doing this?

    We want to bring the Eclipse way of vendor neutral, open, transparent, and meritocratic open source development to the third party forge sites loved by developers around the world.

    The key services that Eclipse provides are its vendor neutrality, its development process and its intellectual property management. We take a lot of pride in our well-supported development forge. But it is clear that many developers and projects are present on third party forge sites, and love the tools provided by those sites. We also want to continually make it easier for people to contribute to Eclipse projects, and the pull request has become the most popular way to do that.
  3. Why would making use of this program be good for my project?

    It is definitely not for all projects. Not every open source project is interested in adding the governance, development and IP processes inherent in being part of an open source foundation such as Eclipse.

    Third party forges are wonderful for developers building their code. But when an open source project becomes successful, other stakeholders start to take an interest in the project. Users and adopters - especially commercial ones - are very interested in matters such as governance, intellectual property management and independence of the projects that they run their businesses on, or embed in their products.

    This program is initially applicable to those projects which have started on third party forge sites, but now feel that it would be valuable to have vendor-neutral governance, transparent and meritocratic open source development process, and intellectual property management taken care. After we ramp up, it will also allow existing Eclipse projects to tap into the diversity and contribution flow of the millions of developers which frequent these popular sites.
  4. If their day-to-day development is hosted someplace else, are these really Eclipse projects?

    Yes. Here are a few things to keep in mind:
    1. The operations of the project would be under the auspices of an Eclipse Project Management Committee (PMC), and the full Eclipse Development Process would apply.
    2. The project’s trademark would be owned by the Eclipse Foundation.
    3. The project would be required to maintain its metadata, and manage its committer roles via the Eclipse Project Management Infrastructure.
    4. The project would be required to be in compliance with all of the intellectual property management policies of the Eclipse Foundation, including use of IPzilla to manage their IP.
    5. The project can participate in the annual simultaneous release if they wish.
    6. The project would be required to use the Eclipse Foundation signing service to digitally sign their releases as coming from the Eclipse Foundation.
    7. The project would be required to maintain downloads from the Eclipse servers and mirrors.
  5. Does this affect the independence of the Eclipse Foundation?

    What matters to us is that any particular third party forges vendor could disappear tomorrow, or change their policies regarding free repositories for open source prjects, and the Eclipse project will be easily able to pick up and carry on.

    This would basically not work if it wasn’t for the fact that the Eclipse community has almost entirely switched over to using the git distributed version control system. Because git is inherently distributed, we can easily maintain a complete record of all of the code of a project on Eclipse servers, even if the day-to-day development is hosted elsewhere. We will also be maintaining complete records of the IP contributions, dependencies, committer rolls, etc. in the standard Eclipse Foundation systems like the project management infrastructure (PMI) and IPzilla.
  6. Which third-party forges are you going to support?

    We’re starting with GitHub, and we’ve starting exploring possibilities with Bitbucket. But the general criteria that we’re looking at includes at least the following points:
    1. Has to support git. We rely on the distributed nature of git.
    2. Has to have the APIs we need. We need to be able to do things like have commit hooks which check for CLAs, and team APIs that allow us to administer the committer lists on a project repo.
    3. Has to be a successful, well-known place for hosting open source projects as a general service.
    4. Has to be worth doing. Building and supporting interfaces will require resources from the Eclipse Foundation, and there has to be enough projects who are interested in making that happen.
  7. This sounds interesting, and it’s something I might want to do eventually. How can I make sure that my GitHub project could take advantage of this in the future?

    The biggest topics to take care of are licensing and careful tracking of your intellectual property provenance.

    With regards to licensing, there are certain licenses which are acceptable to the Eclipse Foundation, and certain ones which are not. This applies to both your project’s code, and to the dependencies you rely upon. The short version is that the GPL and LGPL are out, and the EPL, BSD and Apache licenses are in. The longer version can be found in our EPL FAQ.

    With regards to provenance, it is critical that you put an OSI-approved license on your project, and that you ensure that all committers and contributors have explicitly and in writing indicated that they are providing their contributions under that license. You may want to use a Contributor License Agreement (CLA) to do that. If you want to have the freedom to re-license that project at some point in the future, you may want have that CLA provide you with sufficient rights to do so.

  8. Any limitations I should know about?

    There are likely lots, but here are a couple that you should know about.
    1. The Eclipse Foundation does not currently allow all that wide a range of licenses. The Eclipse Public License (EPL) is the default. With the approval of the Board, we have a number of projects which are dual-licensed under the EPL and the Apache License, and the EPL and the BSD(EDL). We are willing to consider other permissive licenses on a case-by-case basis.
    2. There are likely going to be some limitations on how your current repository’s history can be brought over to your new Eclipse project. We are working out exactly what those limitations are.
  9. Does this only apply to projects written in Java or using the Eclipse plug-in model?

    Nope. The Eclipse community is now technology agnostic. We have projects using JavaScript, Lua, C and other languages. What we require of projects at the Eclipse community are two things: (a) a commitment to follow our principles of openness, transparency, meritocracy and vendor neutrality, and (b) a willingness to follow our development and intellectual property processes.

  10. Where will issues be tracked?

    At least for the time being, all Eclipse projects must use our instance of Bugzilla for tracking bugs and other issues.

  11. What about the other community-facing services such as mailing lists, wikis, etc.?

    To be honest, this is still a work in progress. Here is where we are at the moment:
    1. As mentioned above, every Eclipse project will have to use our Bugzilla for bug and issue tracking.
    2. Mailing lists and forums are a bit complicated, as lots of people prefer using facilities like Google Groups and Stackoverflow. We are going to ask every project to have a dev list hosted at Eclipse, and to monitor the project forum on eclipse.org. But if they have other communication channels, that’s OK too. We want to encourage people to have discussions about Eclipse projects.
    3. We’re still discussing what to do with wikis.

  12. When can my existing Eclipse Foundation project move to github?

    Please be patient. We want to start small and gradually grow this. In particular, we need to implement a sufficient amount of automation to ensure that we are not overwhelmed by manually supporting these processes.
  13. I’m working on an existing Eclipse project. Does this mean I have to move?

    No! Eclipse projects can choose where they want to host their day-to-day development. Hosting at eclipse.org, and using the tools and infrastructure there is perfectly fine.
  14. This is cool! Who can I talk to about bringing my project to the Eclipse community?

    Please contact emo@eclipse.org.