Concept Note E - Existing for-Profit Company

CONCEPT E - Existing for-Profit Company

This topic is for discussing people's thoughts on Concept F. 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 brief note involves entrusting full control of the ODK IP and management of the code base to a single company name, domain name, etc. This would be an existing company centered around providing services around ODK, and it would still be able to offer such services (e.g. Aggregate hosting services, consultancy, survey design). The PMC, with strong input from the greater ODK community (e.g. convening attendees, existing companies, users, practitioners), would decide which company would take responsibility for ODK.


Control over the ODK IP (name, domain name, etc.) and project codebase repository (e.g. GitHub ownership) would pass to an existing for-profit ODK services-based company. All decisions on ODK would be left up to the company, such as how to seek and incorporate input, manage the community, incorporate pull requests, etc. There would be no limitations placed on what the company could or could not do with the IP and code (including taking it private, which could lead to forks from the latest revision).


Organizational control is completely up to the chosen company, including how to seek and incorporate feedback from the community.


As above, the company would set the technical roadmap, and decide all aspects - how regularly it is updated, whether it is publicly shared, and how community input is incorporated. So although they would be wise to seek input from the overall community (end users, fellow ODK verticals, funding agencies), control boils down to that company and its decision-making structure. It is also ultimately up to the company to return its own modifications back to the code base, incorporate other developers’ changes, etc. If it refuses to do this, nothing prevents the community (or multiple sub-communities) from forking back to the open state of the source code at the time control was given to the company.


The company would continue to make money through its existing business model, which presumably includes offering ODK-based services, such as hosted Aggregate instances, consulting with on-the- ground users/implementers, etc. It could also seek contracts with organizations willing to fund ODK feature development.


The hope is expanded ODK community input, as with other Notes such as A, but decisions on whether and how to seek and incorporate feedback from the entire ODK community would be up to the company. As a for-profit company, the needs of its willing-to-pay users will weigh heavily in determining decisions on ODK (e.g. features). However, the company may be disincentivized from seeking or weighing as heavily, non-paying ODK users and other-companies-users’ input. As above, it would ultimately be up to company to determine how to seek input, manage the community, incorporate pull requests, etc.

It seems like this could create winners and losers and might not be great for the long term health of the community. ODK is a pretty forked project already and one of my hopes of the transition is to enhance the inclusion.

1 Like

Kate makes a good point. I would hope that a company under this scenario could first provide some plans for how they would manage ODK.

There are plenty of good examples of open source projects being "sponsored" by for-profit organizations, though, (and still collaborating with other companies on that project) so this would not necessarily be (a) impossible or (b) a "death sentence" for other companies in the ecosystem.

Agreed that there are plenty of projects sponsored by for-profit organizations. In the case of ODK, I worry what happens if there is a sole company that is involved and that company fails?

It seems to me that a safer approach is not to tie the project directly to one company, but rather establish governance that allows organizations (not just companies) in general to move the project forward by participating in the community and gaining influence over time.

I imagine that many projects similarly situated worry about this somewhat. Ultimately if the host org were to fail, and if the project is licensed properly, the code could be picked up by another org (formal or informal, for-profit or non-profit) and would could continue. Of course, that assumes those orgs or individuals are around and want to continue carrying the work forward.

1 Like