How can we contribute developing new features?

Hi ODK community! Here my short introduction: my name is Nicolas, I'm an information systems engineer from Argentina, and currently working for a company based in Buenos Aires. We are in the process of adopting a new Web GIS platform + data collection app. It means ODK is a BIG candidate for us, if we can find out how to handle some features which are not currently part of ODK.

Our short list of features we would need:

  • Centralized group based security: we should be able to manage access to different features and forms in Collect from a server side (Aggregate?), opposed to current behaviour of Collect where you can manage access with a local password in every device.
  • Multi tenancy: we should be able to manage multiple "organizations" or tenants from Aggregate/Collect, so different organizations can work isolated (from the user's point of view), without having separated installations.

Having said this, we would like to contribute designing/developing those features, and making them part of ODK. Now the questions are: how can we do that? what is the process for approving a new feature? and for design and development? Is it possible to contribute in that way, without forking ODK?
I'm pretty sure many of my questions are already answered somewhere, unfortunately I couldn't find the right place.

Hope you can give me some advice!



Hi Nicolopez,

we Appreciate that you are here with us,

in fact if you want to share discuss for new feature you can discuss your feature here

thank you for sharing us your interest of ODK

Best Regards

Hi Nader, thanks for your welcome.
Before discussing new features in detail, I think it's worth understanding how the approval of new features works, who makes the decision, how can we contribute (time, money?), timing, etc.
Before requesting anything, I'd like to be sure how to do it in the proper way and with the right expectations.



Hi Nicolas,

in fact we discuss features publicly so every one get help.

If you run into any problems, then post those problems in the Support. If you want to hire someone to do work for you, then post your offer in the Marketplace

Best Regards

@nicolopez Thank you for asking these great questions! And because they are great questions, I wanted to take time to give you a detailed answer.

ODK transition status

ODK is going through a transition where the project is moving out of University of Washington and standing on its own as community-owned open-source project.

The transition was announced a year ago in the future of Open Data Kit blog post and the most current update of status is in ODK Convening summary. The takeaway is that for ODK 1 (Collect/Build/Aggregate/Briefcase/JavaRosa), UW's support ends in September 2017.

Nafundi, a company I run, is committed to facilitating community building, software development, documentation, and support for ODK 1 over the next 2-3 years. Our goal is to put the structures in place so others can step into the various leadership roles.

Current and future governance

The governance for ODK is here. The summary is that we are a meritocratic community that's led by a project management committee. That committee is myself, Waylon Brunette, Richard Anderson, and Carl Hartung.

This governance will likely change in the next few months as the project moves to a pair of Technical Steering Committees (one for ODK 1, one for ODK 2) that's overseen by a Transition Board. We recently had a thread and survey about this new governance structure.

How to contribute today

As far as what you can do to contribute to designing and developing these features, here is the practical guide.

  1. File a detailed feature request in the forum. We'll discuss it within the community to see if we can get rough consensus (or no major objections).

    • If it's a feature that doesn't disrupt current users and you are willing to send in a PR, it's very likely it'll get merged.
    • If you can't send in a PR, then no guarantees on a timeline.
  2. Once the feature gets to a series of tasks we can close, we move to GitHub and file them as issues in the appropriate repos. If we need to talk real-time, we use Slack.

    • Each repo has a contributing guide that describes our expectations.
    • Once we get a pull request, it's generally reviewed by a contributor and merged.
    • We try to ship monthly releases and can sometimes ship earlier if it helps a contributor.
  3. As of today, most of the active code contributors are affiliated with Nafundi. This is something we want to change because it's not healthy for the project's long-term future. To diversify the contributor base we are:

    • Listing ODK on all manner of open-source sites to get new contributors.
    • Recruiting a diverse technical steering committee. The ongoing monthly dev calls are a good way to join in.
    • Doing most things out in the open so we can build out the contributor community.
    • Starting a technical road mapping process really soon.

A caveat about Aggregate

Your feature requests touch Aggregate. That's important to note because Aggregate just recently transitioned from UW to the community. We are still working to make it easy to build and contribute to Aggregate and here is the thread that discusses that transition.

That thread also discusses one of features you requested: multi-tenancy (and so does this group specific permissions in Aggregate thread). The other feature of being able to push configuration to the device is also known to me and there have been a few forays in this direction (e.g., load settings from json and configure settings from QR code and push notifications).

All this to say, before we can take on specific features, we get Aggregate easily buildable and hooked up to continuous integration. We need help with this effort and until it happens, we can't really take on PRs.


2 posts were split to a new topic: Sharing updates on transition status

@yanokwa thanks a lot for your message, it shed light for a new joiner to the project like me and the organization I belong to. For sure it's a great basis for internal discussion with my colleagues about our participation.
In addition, I fully agree with @LN that your message is valuable information that can be reused.