| <?php require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php"); $App = new App(); $Nav = new Nav(); $Menu = new Menu(); include($App->getProjectCommon()); # All on the same line to unclutter the user's desktop' |
| |
| |
| # |
| # Begin: page-specific settings. Change these. |
| $pageTitle = "Eclipse and Social Coding FAQ"; |
| $pageKeywords = "github, bitbucket, development, git, eclipse, social coding"; |
| $pageAuthor = "Mike Milinkovich"; |
| |
| # Add page-specific Nav bars here |
| # Format is Link text, link URL (can be http://www.someothersite.com/), target (_self, _blank), level (1, 2 or 3) |
| # $Nav->addNavSeparator("My Page Links", "downloads.php"); |
| # $Nav->addCustomNav("My Link", "mypage.php", "_self", 1); |
| # $Nav->addCustomNav("Google", "http://www.google.com/", "_blank", 1); |
| |
| # End: page-specific settings |
| # |
| |
| # Paste your HTML content between the EOHTML markers! |
| $html = <<<EOHTML |
| |
| <div id="midcolumn"> |
| <h1>$pageTitle</h1> |
| <p>Last updated June 20, 2013</p> |
| |
| <h3>Table of Contents</h3> |
| <ol> |
| <li><a href="#what">What is the Eclipse Foundation doing?</a></li> |
| <li><a href="#why">Why is the Eclipse Foundation doing this?</a></li> |
| <li><a href="#whygood">Why would making use of this program be good for my project?</a></li> |
| <li><a href="#really">If their day-to-day development is hosted someplace else, are these <i>really</i> Eclipse projects?</a></li> |
| <li><a href="#independent">Does this affect the independence of the Eclipse Foundation? |
| <li><a href="#which">Which third-party forges are you going to support? |
| <li><a href="#future">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?</a></li> |
| <li><a href="#limitations">Any limitations I should know about?</a></li> |
| <li><a href="#plugins">Does this only apply to projects written in Java or using the Eclipse plug-in model?</a></li> |
| <li><a href="#issues">Where will issues be tracked?</a></li> |
| <li><a href="#wikis">What about the other community-facing services such as mailing lists, wikis, etc.?</a></li> |
| <li><a href="#existing">When can my existing Eclipse Foundation project move to github?</a></li> |
| <li><a href="#move">I’m working on an existing Eclipse project. Does this mean I have to move?</a></li> |
| <li><a href="#contact">This is cool! Who can I talk to about bringing my project to the Eclipse community? </a></li> |
| </ol> |
| |
| <h3>FAQ</h3> |
| <ol> |
| <li><a name="what">What is the Eclipse Foundation doing?</a><br/><br/> |
| |
| 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.<br/><br/> |
| |
| 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.<br/><br/> |
| |
| 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. <br/></li> |
| |
| <li><a name="why">Why is the Eclipse Foundation doing this?</a><br/><br/> |
| |
| 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.<br/><br/>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.<br/></li> |
| |
| <li><a name="whygood">Why would making use of this program be good for my project?</a><br/><br/> |
| |
| It is definitely <i>not</i> 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.<br/><br/> |
| |
| 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. <br/><br/> |
| |
| 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.<br/></li> |
| |
| <li><a name="really">If their day-to-day development is hosted someplace else, are these <i>really</i> Eclipse projects?</a><br/><br/> |
| |
| Yes. Here are a few things to keep in mind:<br/> |
| |
| <ol> |
| <li>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.</li> |
| <li>The project’s trademark would be owned by the Eclipse Foundation.</li> |
| <li>The project would be required to maintain its metadata, and manage its committer roles via the Eclipse Project Management Infrastructure.</li> |
| <li>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.</li> |
| <li>The project can participate in the annual simultaneous release if they wish.</li> |
| <li>The project would be required to use the Eclipse Foundation signing service to digitally sign their releases as coming from the |
| Eclipse Foundation.</li><li>The project would be required to maintain downloads from the Eclipse servers and mirrors.</li> |
| </ol> |
| |
| <li><a name="independent">Does this affect the independence of the Eclipse Foundation?</a><br/><br/> |
| |
| 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.<br/><br/> |
| |
| 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.<br/></li> |
| |
| <li><a name="which">Which third-party forges are you going to support?</a><br/><br/> |
| |
| 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:<br/> |
| <ol> |
| <li>Has to support git. We rely on the distributed nature of git.</li> |
| <li>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.</li> |
| <li>Has to be a successful, well-known place for hosting open source projects as a general service.</li> |
| <li>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.</li> |
| </ol> |
| |
| <li><a name="future">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?</a><br/><br/> |
| |
| The biggest topics to take care of are licensing and careful tracking of your intellectual property provenance.<br/><br/> |
| |
| 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 |
| <a class="c10" href="http://www.eclipse.org/legal/eplfaq.php#3RDPARTY">EPL FAQ</a>.<br/><br/> |
| |
| 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.</li><br/> |
| |
| <li><a name="limitations">Any limitations I should know about?</a><br/><br/> |
| |
| There are likely lots, but here are a couple that you should know about.<br/> |
| |
| <ol> |
| <li>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(<a href="documents/edl-v10.php">EDL</a>). We are willing to consider other permissive licenses on a case-by-case basis.</li> |
| <li>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.</li> |
| </ol> |
| |
| <li><a name="plugins">Does this only apply to projects written in Java or using the Eclipse plug-in model?</a><br/><br/> |
| |
| 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.</li><br/> |
| |
| <li><a name="issues">Where will issues be tracked?</a><br/><br/> |
| |
| At least for the time being, all Eclipse projects must use our instance of Bugzilla for tracking bugs and other issues.</li><br/> |
| |
| <li><a name="wikis">What about the other community-facing services such as mailing lists, wikis, etc.?</a><br/><br/> |
| |
| To be honest, this is still a work in progress. Here is where we are at the moment:<br/> |
| |
| <ol> |
| <li>As mentioned above, every Eclipse project will have to use our Bugzilla for bug and issue tracking.</li> |
| <li>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.</li> |
| <li>We’re still discussing what to do with wikis. </li> |
| </ol><br/> |
| |
| <li><a name="existing">When can my existing Eclipse Foundation project move to github?</a><br/><br/> |
| |
| 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.<br/></li> |
| |
| <li><a name="move">I’m working on an existing Eclipse project. Does this mean I have to move?</a><br/><br/> |
| |
| 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.<br/></li> |
| |
| <li><a name="contact">This is cool! Who can I talk to about bringing my project to the Eclipse community?</a><br/><br/> |
| |
| Please contact <a class="c10" href="mailto:emo@eclipse.org">emo@eclipse.org</a>. </li> |
| |
| </ol><br/> |
| |
| </div> |
| |
| |
| EOHTML; |
| |
| # Generate the web page |
| $App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html); |
| ?> |