CONCEPT B - New ODK Nonprofit with Paid Staff
This topic is for discussing people's thoughts on Concept Note B. 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.
This note proposes establishing a new nonprofit dedicated to maintaining and improving ODK, with on- staff paid developers, managers, etc. It would have Technical Steering Committees for each ODK project/component, allowing for direct input into ODK’s direction from industry, users, and funding agencies via an Advisory Committee, and would raise funds for feature development, maintenance, or even cleaning and contributing back a fork’s existing feature additions/customizations.
A new 501(c)3 nonprofit will be established to own ODK IP and oversee the project. Because getting non-profit certification can take some time (up to 12 months, possibly even longer), ODK could find a fiscal sponsor (this could be a software foundation as in Note A or some other sponsor) as an intermediate transition step. The nonprofit will have a Board of Directors responsible for legal and fiscal authority, which will provide high level direction and work to sustain the organization (similar to the top- level role of the current ODK PMC). This note also envisions establishment of an Advisory Committee to represent the overall interests of the entire ODK community (it should have representation including end-users, implementers, funders, and developers). Technical Steering Committees (TSCs) would be established for each of the ODK projects (e.g. Aggregate, JavaRosa, ODK 2.0, Collect, etc.).
There would be up to approximately 10 internal staff, consisting primarily of developers but also some staff serving in project management/administrative/community management/fundraising roles. Staff developers would work on both maintenance and feature development.
Oversight and ultimate authority is provided by a Board of Directors; the board elects officers (Chairperson and/or President, Secretary, Treasurer). For this note, the nonprofit would follow a self- perpetuating board model that sets the rules for electing directors, votes on replacement/removal, etc. (Alternatives are possible, of course, including direct election of board members by some definition of voting-level “community” members.) The board is responsible for high-level operations and directing the foundation towards ODK’s mission goals (e.g. sustainability, stability, openness). Individual ODK Project TSCs would be populated by key contributors, determined by current PMC and community input. These would consist of a mix of both ODK paid staff and outside contributors.
The Advisory Committee (AC) membership will be determined by the current PMC and the Board of Directors; members serve 1-year terms after which they can be reappointed or removed. Some seats on the AC could also be populated via other means, such as nomination/election of 1 or more AC members by the ODK community, and/or paid annual membership for automatic seats (restricted to no more than one member from the same company/organization).
B.3. TECHNICAL ROADMAP
Each ODK Project’s TSC is responsible for proposing periodically updated (e.g. once per year) roadmaps for their projects, based on input from community and the AC. The AC must then vote to approve the roadmaps; if it does not it sends feedback to TSC and the TSC modifies for re-consideration. Ideally this should be rare given the original input from the AC. If a consensus between a TSC and the AC cannot be reached on a roadmap, the Board of Directors steps in to give instruction or make a final decision (again ideally this should be exceedingly rare).
A high number of paid developers and operational staff requires a high level of funding commitment. Therefore, funding would be sought from multiple sources:
- Endowment (ideal but least likely)
- Government/NGO/other foundation grants (similar to what has sustained effort at UW thus far).
- Paid AC seats / Paid website placement for implementers (website placement comes with an AC seat). Prices TBD.
- Pay-for-feature development (or integration of existing forks’ features).
- Individual donations always welcome
Additionally, the foundation will need to seek start-up funding from existing organizations, foundations, etc. Depending on the success of the above, it may well need to grow slowly over time, with limited foundation-based development/maintenance activities to start.
In addition, if the above is not enough to cover the funding needs additional revenue models may need to be considered (which may create tension with existing ODK vertical companies providing them):
- Software as a Service (e.g. Aggregate cloud instances).
- Commercial licensing, for example through a small percentage fee based on commercial ODK companies’ users. This could also be “voluntary”, or required for deployments over size X, but it would at least result in the foundation providing an invoicing so it can be worked into other contracts, grants, etc.
- Consulting services (beyond pay-for-feature development): training, planning, survey development and management, infrastructure deployment.
B.5. COMMUNITY FEEDBACK
As with Note A, the foundation should regularly solicit feedback from the overall community (e.g. regular votes on possible features, roadmap directions, regular publication of roadmaps, submitting feature requests, etc.). In addition to those avenues, non-developer members of the community can also provide directly influencing feedback via election of AC member(s), who approve the TSCs’ Roadmaps. Similarly, NGOs and implementers / companies can provide directly-influencing feedback via (possibly paid) AC membership.