Incubation FAQ
This is an informal FAQ mostly drawn from conversations on the committee email list where we help projects through the OSGeo incubation process.
About Incubation
- What software projects are currently part of the foundation?
- The complete list of projects is shown on the OSGeo Home page. On its formation, the GDAL/OGR, GeoTools, GRASS, Mapbender, MapBuilder, MapGuide Open Source, MapServer and OSSIM projects declared their support, and joined as initial projects. Additional projects have been added through an incubation process.
- What does a project need to do to join?
- The Incubation_Committee is responsible for helping new projects join the foundation; they are responsible
- Detailed rules for new projects to join the foundation have not yet been determined. Some tentative ideas on the Proposed Project Submission Process have been written up and are being refined prior to approval.
- So when can my project join?
- We anticipate it will be several months for the initial projects to complete the incubation phase, and for the foundation to be ready to consider additional projects.
- Do foundation projects need to sign over copyright to the foundation?
- No. Copyright to individual contributions in foundation projects is expected to remain with the original developer. The foundation will obtain rights to contributed project code by way of a contributor license agreement from the developer.
- Do project developers need to sign a legal agreement?
- Yes. The foundation is expecting to require project committers (and, in some situations, their employers) to sign a contributor agreement that ensures they are submitting code to their foundation project legally. The details of this agreement are still being worked out.
- Do foundation projects need to turn over project control to the foundation?
- No. The foundation is not interested in controlling foundation projects. However, foundation projects are expected to follow some foundation rules, mostly around the need to ensure that project code is not legally encumbered (i.e., not stolen, or improperly contributed), and that appropriate controls are in place to ensure code is properly contributed. Some additional expectations may exist around projects operating in an open and accountable fashion, handling foundation provided-funding appropriately and not taking actions that will cause legal problems or negative goodwill for the foundation. The foundation also encourages, but does not require, projects to support foundation goals, such as implementing standards-based interoperability.
- Can my project operate as a benevolent dictatorship?
- Detailed requirements for project administration have not yet been worked out, but it is anticipated that rules somewhat related to those for Apache will be followed. Projects should have a Project Steering Committee responsible for technical decisions and these committees should operate openly and with a consensus based approach. A benevolent dictatorship is not likely to be considered suitably open and consensus based.
- Do I have to use mandated source control / web system / bug system / mailing list from the foundation?
- No. Projects joining the foundation can continue to use their traditional source control system, web site system, bug tracker and mailing list software. However, the foundation does offer these infrastructural components, and encourages their use to provide a more consistent way for users and developers to interact with the different foundation projects.
- What is the role of CollabNet in the foundation?
- CollabNet has been contracted on behalf of the foundation to provide infrastructural support and manpower to facilitate building the foundation and its community. They have professional experience to offer at both a technical and social level in building similar open source efforts.
- Does the foundation mandate a particular license for software?
- The foundation only accepts projects that use OSI-certified licenses for their software, and requires that projects stick to OSI-certified licenses. This includes common licenses such as MIT/X, BSD, GPL, and LGPL. The foundation encourages library projects to use the LGPL or a more permissive license (such as MIT/X or BSD) rather than the GPL so that the libraries can be reused by non-GPL projects, but does not require it. The foundation also discourages a proliferation of new and incompatible licenses.
- Does the foundation mandate a particular license for content other than software, such as geodata, educational materials, documentation, etc.?
- The foundation accepts non-software projects that use Creative Commons or similar licenses for their public geodata, educational material, or promotional material. The foundation also discourages a proliferation of new and incompatible licenses.
Q: What is incubation
Incubation in a process used to add projects to the Open Source Geospaital foundation. It is design as a quick safety check prior to a project being recognised as part of the foundation.
For more details see the main web page: http://www.osgeo.org/incubator
Q: Why have a mentor
The Incubation Committee committee asks for a mentor to assist each project through incubation for a number of reasons.
A: Outreach
We are making available a member of the committee on your developer email list as an out reach effort to your community. It is often easier to have discussions (on open source basics, or incubation checks) on the project email where everyone is comfortable
A: Privacy
Not all questions are suitable for public discussion. The incubation process can touch on a few subjects that should be handled with care (such as code ownership, code distribution, license questions and so forth). Having a mentor to talk (and arrange suitable help) can be very useful to collection the required information to continue.
Projects
Q: What about long term viability?
A: The incubation process really wants to check that a project is not going to suddenly disappear:
- That a project has a high bus number and will not suddenly end if a central key developer leaves or is no longer available
- That a project draws on several organisations (and thus sources of funding) for its health and well being
Q: What about existing projects
A: Existing projects answer to the board
Incubation is a dynamic process reflecting the needs of the foundation today. The incubation process and checklists are updated to reflect these changes and are adjusted as the foundation priorities change.
Existing projects are not expected revisit the incubation process they are answerable directly to the board via a "project officer". If the board requires any additional information or policy change suitable arrangements can be made.
Open Source Basics
Q: Open Source License?
A: Recognised by Open Source Initiative
It is not enough to give the source code away for free - projects are expected to be open source in license.
For the purposes of incubation that amounts to the projects being distributed under a license recognised here:
Q: Attribution and Agreement
A: Who wrote it and did they agree to let you distribute it
On the face of it this is a real easy check to understand - but a very hard one to get correct. Projects receive input in large part through contributors and committers; supplemented by patches submitted via issue trackers.
Some projects allow contributors to keep their own (c) and simply ask that all contributions be provided under a common license. Other projects ask that copyright be assigned to a common organisation this allows the project to change license in the future if needed.
Common mistakes: - It is common for projects to get in trouble with individuals contributing fixes; while working as an employee. In these cases the employees often owns the contribution and a separate code contribution agreement must be filled in by the employer. - It is common from working code to be picked up from one project and used to fix an issue in another. Care must be taken to ensure the licenses compatible or suitable arrangements have been made.
Examples:
- PostGIS contributions are made under a common license with no copyright assignment
- GeoTools contributions are made after a developer has signed a code contribution to the OSGeo Foundation
- GeoServer contributions are assigned to the Open Planning Project
- GeoTools has a standing arrangement with GeoServer allowing code to be contributed; in each case an email request is made and formally responded to prior to a fix being back ported to GeoTools. This is a case of a procedure being established allowing the license of the code to be changed from GPL to LGPL.
This is often checked against file headers and verified using version control history, issue tracker history and any written records such as code contribution agreements.
Open Development
Perhaps the most important indicattor of long term viability is how well a project practices open development.
We are really looking for two things: - evidence that the procedures are in place allowing the project to be run by several organisations as a collaboration - ensuring new groups can take part
While this is sometimes considered a tall order we do ask that projects write down how they are functioning - even if it is inconvenient for others. OSSIM often had key decisions made over breakfast in a monthly face to face meeting. The direction for GeoNetwork was often set by key stakeholders meeting face to face each year. In both these cases taking part is open to new members.
Checks
Q: Why check Email List Activity
Q: Confirm open communication
Mentors sign up to the developer and email lists to look for a healthy interaction between developers and users. We are especially looking for evidence of collaboration between organisations.
Q: Confirm open decision making
A key component of open development is ensuring that the project procedures are applicable to all groups taking part in the project. This is often really illustrated around accepting new contributors, planning future development and making new releases.
Note: - We do expect gaps (and understanding) around the careful balance between meeting paying customers expectations while still maintaining open communication with the community. As such we are used to see pending work proposed (and checked with the community) and then withdrawn if the appropriate funding was not obtained.
Q: What to look for in headers
A: That they exist and that the correctly attribute the code and establish the project is allowed to distribute
Headers are your life lifeline if any legal questions are asked around your project, it is one of the