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
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