Concept Note D - Hybrid – Establish New Nonprofit Partnering with Small Consortium of ODK-related Companies to Maintain and Further Develop ODK

CONCEPT D – Hybrid – Establish New Nonprofit Partnering with Small Consortium of ODK-related Companies to Maintain and Further Develop ODK

This topic is for discussing people's thoughts on Concept Note D. 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 concept note envisions establishment of a new ODK-specific nonprofit, similar to that of Note B but differing in that it would be smaller in size and the bulk of development is done not by nonprofit staff but by a consortium of ODK-related companies working with the foundation. The foundation would be heavily guided by this consortium of companies via membership on the board.


As with Note B, this concept would establish a new 501(c)3 nonprofit to own ODK IP and oversee the project; similarly, it could get a fiscal sponsor as an intermediate transition step. The nonprofit would have a Board of Directors and officers responsible for legal and fiscal authority and which would provide high level direction (similar to top-level role of current ODK PMC), and work to sustain the organization and the ODK project. Technical Steering Committees (TSC) would also be established for each ODK component. Unlike Note B, the board may have a large fraction of paid-for positions, for example similar to the “platinum” level memberships of the Symphony Software Foundation. Also the foundation would be smaller and have less paid development staff; the bulk of development would be handled through external partners (likely represented on the board via these paid memberships. Foundation staff (more on the order of 5 or so) would be responsible for foundation management, fundraising, community management, and technical steering. This could also include possible paid staff for ODK maintenance, but this and ODK feature development are more likely to be performed by consortium partners. Technical Steering Committees (TSCs) would be established for each of the ODK projects (e.g. Aggregate, JavaRosa, ODK 2.0, Collect, etc.).

Essentially, the foundation would provide a mechanism for a consortium of invested companies providing ODK services (and possibly features) to come to a consensus-based agreement on the priority of common maintenance and new feature goals, as well as determine what companies and/or developers will then work on their implementation.


The new ODK Foundation will have a Board of Directors which also elects officers (Chairperson and/or President, Secretary, Treasurer). Unlike B.2, the board would not be self-perpetuating; rather a large number of seats would be determined by paid annual sponsorship (limit 1 sponsored board seat per individual company/institution). Board seats could come and go as companies pay or fail to renew their sponsorship, respectively. The board would be responsible for legal and fiscal authority and also serve as the overall project management committee for ODK, with final authority over all ODK decisions. Non- fiscally sponsored board seats could be determined by a variety of techniques, including nomination by the fiscally-sponsored board members or directly by some definition of voting members of the greater ODK community (example contributors, donors, users, etc.). Individual ODK Project TSCs would be populated by key contributors, determined by current PMC and community input. With the foundation itself having a small staff these TSCs would primarily consist of non-foundation contributors.


Each ODK Project’s TSC would be responsible for proposing periodically updated (e.g. once per year) roadmaps for their projects, based on input from the Board and the community. The board would have final approval over the TSCs; they could provide feedback and a request for modification by the TSCs, or ultimately overrule the TSCs (with obvious ramifications). In this model the consortium companies have more potential say in this through their paid representation on the board. This could also increase the level of influence that these companies’ (paid) users have in the overall ODK Roadmap, due to the consortium’s incentive to be responsive to them. It could also however potentially decrease the say that free independent users of ODK have (to the extent that their interests might diverge from users of for- fee services).


As the foundation is smaller in size than Note B, and would also have paid board seats, it would need less direct funding, and thus would seek funding from a (possible subset) of the options listed in B.4, including grants, pay-for-feature development, and individual donations. Fundraising needs could depend on the annual board membership fee price and the number of participating companies; conversely the annual membership fee might change depending on the level of fundraising success.

As stated above, one funding source would be paid sponsorship, which also would allowing direct naming of a Board Member (limited to 1 per company). This would be an annual sponsorship fee TBD based on input from the board and interested companies. The fees could alternatively be structured as a percentage of ODK-related revenue or a flat fee / user of each company (with some minimum yearly).

The purpose of fees and other fundraising would be to support foundation staff, engage in fundraising, and possibly for ODK maintenance (either via foundation staff developer or contracted back to one or more of the consortium members), as well as external feature development (this could be bid for by foundation consortium members or assigned via consensus).


As with previous notes, the foundation and TSCs should seek regular feedback and input from the greater ODK community. TSCs should be regularly published, features can be voted on etc. As noted above in D.3 there would be clearly more direct input from companies willing to pay for foundation support and the accompanying board seat, and thus their paying user base might have more secondary input than perhaps in other models.

Would this need to be a 501c6 instead of a 501c3?

Personally I don't particularly like this format since it is "pay to play". We would need to trust companies would do what is in best interest of the community. I could see getting into situations with some firms where even if they were well meaning investors wouldn't necessarily allow them to "do the right thing".

What path would new people or orgs get in? Could there be a meritocratic component?

I agree that a trade association such as a United States 501(c)(6) might be the path here instead of a public charity. (Caveat: I am not a legal or tax expert!)

That said, many open source projects are managed through such a trade organization, such as the Linux Foundation. While it is true in that example that member organizations pay to be part of the project's governance board, technical decisions are generally left to a "more meritocratic" technical committee that is generally made up of individuals nominated to the role for their track records, contribution, technical knowledge, etc. In other words, the "pay to play" seats are only responsible the project's direction, and less about how it gets there.

This topic reminds me of a very good talk by Danese Cooper at OSCON a couple years ago. In the talk, she reminds us that "sweat equity" should be able to get someone access to any layer of decision making within a project:

Would this be similar as an earlier attempted OpenRosa consortium? If so, it would be interesting to hear what the lessons learned were.

The OpenRosa consortium wasn't a formal structure. It was mostly a mailing list with people who had a shared vision and a little bit of budget. Things did get done, but at the end of the day, those things got to a good enough stage and people sort of wandered off. I'm not sure a more formal structure would have changed the outcome.

Speaking of OpenRosa, here is a report from the 2009 meeting written by @neal_lesh. I don't think a 2010 meeting ever happened...

FWIW, the OpenROSA group did in fact meet in 2010, in parallel with the OpenMRS Implementers Meeting in South Africa. @yanokwa was actually there. :wink: (I've slept since then, too!)