Relationship between Kobo and ODK

Adi_Eyal · October 21, 2011, 7:12am

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_Hendrick1 · October 21, 2011, 12:55pm

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,
☞§※☼:airplane:
~Neil

···

On Oct 21, 3:12 am, Adi Eyal <a....@burgercom.co.za> wrote:

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

Eric_Ma · October 21, 2011, 5:45pm

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.h...@kobotoolbox.org> wrote:

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,
☞§※☼:airplane:
~Neil

On Oct 21, 3:12 am, Adi Eyal <a....@burgercom.co.za> wrote:

> 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

Adi_Eyal · October 24, 2011, 9:04am

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

···

On 21 October 2011 14:55, Neil Hendrick <neil.h...@kobotoolbox.org> wrote:

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,
☞§※☼:airplane:
~Neil

On Oct 21, 3:12 am, Adi Eyal <a....@burgercom.co.za> wrote:

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

--
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 · October 24, 2011, 3:06pm

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.

☞§※☼:airplane:

~Neil

···

On Mon, Oct 24, 2011 at 5:04 AM, Adi Eyal a...@burgercom.co.za wrote:

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

On 21 October 2011 14:55, Neil Hendrick neil.h...@kobotoolbox.org wrote:

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,

☞§※☼:airplane:

~Neil

On Oct 21, 3:12 am, Adi Eyal a....@burgercom.co.za wrote:

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

–

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.

–

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.

Adi_Eyal · October 24, 2011, 4:07pm

Great - thanks.

That’s really the reply I was looking for.

Adi

···

On 24 October 2011 17:06, Neil Hendrick mojo...@gmail.com wrote:

Hi Adi,
thanks for the clarification.