Relationship between Kobo and ODK

[Adi Eyal]

Hi All

Forgive me if this is mentioned somewhere but I couldn't find it. What
is the relationship between Kobo and ODK? Clearly Kobo is based off
the ODK code-base but since both projects are opensource, is there any
specific reason for the fork? Both projects seem to be general purpose
so I would be interested in understand how to decide when to use which
application.

Thanks
Adi

[Neil Hendrick]

Hi Adi, thanks for your message.

KoBo Collect is based on ODK Collect, but we have modified the
JavaRosa library to allow for the use of itemsets /cascading
selections. It's a very useful function that ODK Collect doesn't
support at this time.

Itemsets require some fairly complex design in the XML form, so we
have automated that for you in the KoBoForm Builder, which is a really
easy and graphical environment for building survey forms. It's not
based on ODK Build, but on PurC Forms, and KoBoForm is highly evolved
from that to be easy to use and have a comprehensive GUI. No
programming skills are required.

Also there are other KoBo tools that work together. KoBoSync is a
standalone option for synchronization, which we use in the field
instead of ODK Aggregate. (There are ways to configure Aggregate to
work offline, but KoBoSync is dead simple and very reliable). KoBoMap
is under development for public use, we use it right now to display
our geotagged survey data in chloropleth maps. They are great
infographics for displaying information.

Like ODK, we're open source and free to use, so I would love to see
you join the growing team of KoBoNauts. If you need any pointers,
please let me know, and if you would like to share what kind of
project or research you are working on, Team KoBo is always very
interested in hearing from users. Your question is a good one, and I
will use it to add something to the FAQ for others.

thanks,
☞§※☼✈☂☻
~Neil

[Eric Ma]

Hi Neil,

Thanks for your explanation. I would like to reach out to all KoBo/ODK
users. My project team is working on a pilot project with two
professors in New York and Abu Dhabi. Students will use Kobo/ODK to
collect geo-referenced data and create geospatial models for GIS
analysis in both campuses.

My team has been testing KoBoForm Builder, KoBo Collect, and ODK
Aggregate with various GIS platforms. KoBoForm Builder and KoBoCollect
have performed reasonably well with a few small issues. We will test
KoBoSync in coming weeks. If there are any particular issues, please
post them in this discussion group.

It is my hope that insights generated in this group will illuminate
more possibilities for collaboration among all KoBo/ODK users.

Thank you
Eric

On Oct 21, 8:55 am, Neil Hendrick <neil.hendr...@kobotoolbox.org>
wrote:

[Adi Eyal]

Hi Neil

Thanks for your response. I guess my question was more around
organisation. Kobo is clearly a really good ecosystem but I wanted to
get a feeling for what criteria I should use to choose between ODK and
Kobo? How close are the ODK Collect and Kobo Collect code bases? Do
you share bug fixes between projects? What was the reason for the
fork? Was it ideological or is Kobo solving a different problem to
ODK?

Thanks again
Adi

> --
> You received this message because you are subscribed to the Google Groups "Kobo Users" group.
> To post to this group, send email to kobo-...@googlegroups.com.
> To unsubscribe from this group, send email to kobo-users+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/kobo-users?hl=en.
>
>

[Neil Hendrick]

Hi Adi, 

thanks for the clarification. 

Specifically, KoBo supports cascading selections / itemsets and ODK does not. 

KoBo has a formbuilder that supports cascading selections, and ODK doesn't

KoBo's formbuilder also has  an easy GUI for adding skip logic and validation to survey questions. 

We absolutely share with ODK, all our improvements are submitted back to ODK or Javarosa, wherever they were made. I suspect that eventually the ODK Collect client will also adopt our javarosa changes and start supporting itemsets/cascading, but I don't know when, or if they will do the same thing with ODK Build for supporting itemsets. I suspect that ODK Build will continue to improve and they will eventually have a better way of writing skip logic and validation. Right now, you sort of have to code it by hand and paste it into the interface. 

Whenever ODK comes out with a new version, I upgrade KoBo from their code, so we try to stay in pace with them, and they often solve problems that we really need but don't have the resources to work on. 

My advice to you is that you should choose KoBo, it has everything ODK has and more, because it is largely ODK with some special functions added on. Eventually, ODK will add something cool that KoBo doesn't have, but since we are an ODK fork, I will just incorporate it into KoBo. Beyond that, the KoBoForm Builder is hands down the best Xform creation tool out there. 

You may want to use ODK Aggregate instead of KoBoSync, depending on your project needs. I think that's cool, we use Aggregate sometimes for our own work, but when we are in the field with little access to the internet, KoBoSync is simple, easy, and reliable. 

Hope that helps, If there is anything else I can do to help you, please feel free to email me again. 

☞§※☼✈☂☻

~Neil

[Adi Eyal]

Great - thanks.

That's really the reply I was looking for. 

Adi