CONCEPT A – Join an Existing Foundation
This topic is for discussing people's thoughts on Concept Note A. For more information or to take the online survey, please refer to general Exploratory Concept Notes topic.
The source PDF for this note can be found here.
A. OVERVIEW
In this lightweight option, ODK would transition to management under an existing software foundation, such as the Software Freedom Conservancy or the Apache Software Foundation. Within the foundation, the ODK project would be governed by a meritocracy led by key developers making up a Technical Steering Committee (TSC). Under such an approach, the funding needs for the ongoing organization would be minimal, as ODK developers would not be compensated by the foundation and thus need to earn a living from other jobs (likely/ideally ODK-related service companies). This model would not provide for any direct funding for ODK maintenance/feature development.
A.1. STRUCTURE
ODK would transition to a project held under the auspices of an existing software foundation. Various foundations are possible homes; two that probably would work particularly well with ODK’s Apache License and existing commercial ecosystem are the Software Freedom Conservancy or Apache Software Foundation. As an example, the details of transitioning to ASF control are described here, and include: finding an ASF Champion; being proposed and accepted as an ASF incubator project; being assigned sponsors to help with the transition; and if successful eventually graduating to a new top-level Apache project.
The software foundation would handle all non-ODK development/maintenance/documentation activities, like fundraising (they handle donations which can be earmarked for ODK), legal (limited liability protection), bank account management, putting assets under control of the not-for-profit (this is optional, but can include trademarks, copyrights, control of the opendatakit.org domain), nonprofit/charity tax-compliance, etc. It may also provide additional services, like technical infrastructure (web hosting, issue tracking systems, forums, etc.).
A.2. GOVERNANCE
The ODK project would be directly governed by a meritocracy led by key developers making up aTSC. Designated leader(s) of the TSC would represent the ODK Project to the software foundation’s leadership. Many TSC structures are possible; for purposes of this concept note the TSC would follow the existing Project Management Committee (PMC) of the current ODK governance structure (based on the OSS Meritocratic Governance Model template). This overall structure defines roles for users, contributors, committers, and finally the PMC, which is the ultimate decision-making authority. The PMC uses a simple self-perpetuation committee model, where its membership is updated via simple majority vote of existing PMC members. It is very likely that the current PMC membership would be updated as a result of the transition and with input from the community and feedback at the convening.
A byproduct of joining an existing foundation is that this option does not require establishing a nonprofit Board of Directors, since it would already be in place. Depending on the relative size of the chosen foundation, its projects, and its governance rules, it may or may not be possible to make a case for ODK representation on its Board or top-level leadership structure.
A.3. TECHNICAL ROADMAP
The technical roadmap for ODK would be set by the TSC, and updated at regular intervals (e.g. once or twice per year). However, to ensure the success of the project, the TSC would not determine the roadmap in a vacuum, but would seek and incorporate from the greater ODK ecosystem in developing the roadmap. As such, the TSC may post draft roadmaps and/or possible features and activities for community feedback (e.g. online voting). The roadmap will also be publicly shared to allow for better planning amongst the ODK user base.
A.4. FUNDING
As there will be minimal funding needs (website hosting, IP/trademark management) the project shall rely on simple donations for support (either direct from individuals or from organizations, possibly even simply provided by the parent foundation joined). Donations would be given to the existing top-level foundation and earmarked for the ODK project. The ODK TSC and foundation could also attempt to raise funds for specific feature development / services (like code maintenance, community support) and subcontract that work to a an external ODK services company, although with this concept note’s structure it is probably simplest for the TSC to play matchmaker, directing the funder to contract with the external company and including a requirement to contribute code changes back to the ODK project.
A significant change from the status quo is that because there is no core development support, ODK maintenance, support, and feature development that is currently being funded through UW will have to come from elsewhere in the community.
A.5. COMMUNITY FEEDBACK
Although the TSC sets the roadmap, as mentioned above it should actively seek advice via feedback from the users of the software and other interested parties (implementers and service providers not represented on the TSC, invested funders). Still, final roadmap decisions rest with the TSC.
This is not dissimilar from the current ODK approach, but (as with all Concept Notes) will seek to increase feedback from community of users and formalize the paths for bi-directional communication with them. This includes regular votes on possible features, roadmap directions, regular publication of roadmaps, submitting feature requests, etc. The TSC should also regularly participate via community infrastructure (mailing lists, forums, issue tracking management).
Will give some more comments a bit later on this weekend or next week!