Gareth S. Bestor TSC Application - 2019-01-10

Community
1

Name
Dr. Gareth S. Bestor (@Xiphware)

Organization
Master Business Systems, Xiphware

What contributions (e.g., issue triage, tech support, documentation, bug fixes) have you made to the ODK community?
I've been involved in the ODK community for approximately two years, initially on Slack and now the ODK Discourse Forum, the later of which I have been a moderator for the past 6 months. I frequently respond to Support questions from the wider community, and recently I submitted PRs to expand the functionality of javaRosa/Collect. I have also been using and providing some testing and feedback on the new ODK Central, particularly around its REST APIs.

How do you believe your contributions have benefited ODK?
As a result of trying to implement XForms (on a non-Android platform), I gained some insight into the inner workings of XForms/XPath which I've been able to share with the ODK form-building community, as well as contribute to technical discussions around ODK spec issues. From my own work on implementing and designing an iOS XForms client, I've been able to provide some, hopefully useful, UI design thoughts and feedback for ODK Collect GUI improvements.

What do you believe the top priorities for ODK are?
I believe the so-called "ODK Spec" is a critical facet of the ODK ecosystem, as it pervades virtually all the tools and enables the compatibility of reusing forms across ODK's various tools. This Spec also dictates the compatibility of and interoperability of third-party tools, which I think are crucial to ODK's long-term viability and increased adoption. I also believe the increased modularization of ODK tools will ultimately be very beneficial, and that Central is a great step in this direction (away from the more monolithic Aggregate).

How will you help the ODK community accomplish those priorities?
As a consequence I am keen to see and help the increased formalization of the ODK Spec and how it - and related APIs such OpenRosa, Collect REST, etc - can be clearly defined and documented. Such formalization should help foster the development of an broader ecosystem of interoperable 'ODK Compatibleā„¢' tools (and not necessarily rely on the small team of ODK developers to write them).

How many hours a week can you commit to participating on the TSC?
1-2 hours (in addition to current participation on Slack and ODK Forum moderator)

What other mobile data collection projects, social good projects, or open source projects are you involved with?
I was a Senior Software Engineer in the IBM Linux Technology Center for many years, writing open source Linux systems management tools for CIM (Common Information Model) and Linux virtualization management (Xen, KVM); most of this code continues to ship in Linux distros. Presently I'm the Senior Software Architect at Master Business Systems for GoMobile - an XForms-based mobile forms solution for iOS, Android and Windows.

Please share any links to public resources (e.g., resume, blog, Github) that help support your application.
xiphware.com, stackoverflow.com/users/3936065/tiritea, http://www.gomobile.co.nz

1 Like
2

Did you mean 'Central' rather than 'Collect' in question 3?

3

Does this have a web site or Github repo or some place we can see more about it?

@Xiphware

4

Opps. Yes, "Central" (typo) :blush: [although Collect has always been a step in the right direction too IMHO :slight_smile: ]

5

It looks like full URL link didnt get pasted correctly: http://www.gomobile.co.nz/
There is a promo video on the home page that gives a bit of an overview of the iOS app UI.

1 Like
6

Thanks @Xiphware for the demo video. Very slick! It makes me want to inspect something! :smiley:

So GoMobile is rather different than a typical Open Data Kit use case or user community. It seems to be targeted at inspection workers in developed economies (perhaps New Zealand?) Do I have that right? Whereas Open Data Kit's area of focus is "resource-constrained environments".

I appreciate your interest in the various ODK-related specifications, which have proved a valuable conduit for collaboration and integration with other tools also geared at resource constrained environments (e.g. ELMO/NEMO, Enketo). However, I am wondering if you can comment on your intentions regarding the specs given that your main experience with them has not been in a resource-constrained environment. In other words, how can you use the experiences that you have had to serve Open Data Kit's mission in an appropriate way?

7

Cheers. :blush: Thankfully, Master Business Systems has talented media artists/web designers. I can write clever code, but I suck at marketing it :smile:

Yes, it is fair to say GoMobile is a quite different looking, schedule-based mobile forms app, with a quite different user-base than most ODK deployments. Presently our target is the regulatory space of local councils; eg inspecting restaurants, funeral parlours, public toilets. But the core of the product is still basically just a user downloading XForms, filling them in thru a form UI, and submitting XML results (with attachments) to a backend DB service, just like ODK. Indeed, it is this common core framework - XForms, javaRosa, XPath calculations, etc - that lead me to ODK in the first place.

Although ODK's specific focus may be resource-constrained environments, it is a testament to how robust the ODK toolset (and XForms) is that it is being adopted by a diversity of users for a wide range of purposes, as illustrated by the user stories posted to the Community Forum. In addition to NGO/humanitarian deployments, we have people using Collect to perform building inspections, count bats, monitor turtle nests, track business assets, etc. I believe the draw of using ODK for these other purposes is less ODK's ability to run on cheap, resource-constrainted Android devices, but because functionally it is the best, readily available and well-supported tool that simply gets the job done! So I dont view a focus on minimizing resource requirements necessarily precludes a focus on increasing functionality and general-purpose applicability, especially as mobile devices increase in power/decrease in cost over time. To remain relevant as a preferred general-purpose mobile forms platform, ODK needs to continue to evolve functionally to meet both needs and increasing mobile expectations.

It is also a reality that, although some of our customers can go out and buy a new 11" iPad Pro to run GoMobile, our product must still operate gracefully within greater resource constrants than our users have become used to: multicore desktops with 4K displays sitting on a Gigabit LAN with virtually unlimited NAS. Whereas everything an inspector needs for a day's field work must to be loaded onto a - relatively-speaking - small, under-powered device, and remain fully capable with or without a network connection. So we have real storage and connectivity constraints for which we must likewise make intelligent tradeoffs. Further, especially due to having the same limited screen real estate to work with, we face almost identical UI decisions around how best to present information to non-technical users and acquire data efficiently with a minimal amount of physical interaction. These are common challenges mobile, offline-capable products share, so I believe the experience of implementing the core functionality of a standards-based, mobile inspection tool, like GoMobile, is quite relevant to ODK, even though cosmetically they may look quite different and target different users.

How the ODK Spec is central to this is that it provides the best way to collectively build up an ecosystem of standards-based (and preferably open-source) interoperable tools that we can all leverage for our individual application; eg GoMobile uses both pyxform, Kobo and Enketo, and may well use Central too in some flavors. So my intention wrt the Spec is simply to have it most clearly (and unambiguously) define behavior and functionality that we can all benefit from, and allow other to contribute their own compatible tools back.

Oh, if you ever find you have a overwhelming desire to inspect a toilet, please just let me know and I'll schedule you something (in GoMobile) - I already have a form ready for you. :wink:

1 Like
8

I enjoy reading your high quality answers and appreciate the time you take to provide a lot of detail.

In addition to having an ODK Spec, are there other strategies you envision for encouraging the growth of a broader ecosystem of interoperable tools?

9

To be honest, I view the 'ODK Spec' - whatever that really is... - as quite pivotal to the establishment and growth of a healthy ecosystem [that, and echoing @yanokwa, doing everything we can to support folks participating and contributing back to ODK]. But we can do more by providing better facilities for external (and internal!) tools being able to check this Spec for conformance and interoperability. A tool like Validate goes a long way to help check that a form is (or should be) compatible with the likes of ODK Collect, but it is imperfect and there is room for improvement. And Validate only examines the nature of the XML XForm itself; in terms of checking the interoperability of a new tool for such operations as downloading forms and submitting results, presently ODK only has some scattered API documentation (eg openRosa API, Central REST API) which is sometimes incomplete and often quite cryptic. So in my own experience, I found being able to actually drive my own tools against other operational ODK components as more critical. Things like https://opendatakit.appspot.com (Aggregate) and https://odk.antinod.es (Central) have been hugely beneficial to me in the development of 'ODK Compatibleā„¢' tooling.

So in addition to more clearly and unambiguously defining the 'ODK Spec' itself, I think there is room for ODK to better provide easily accessible, fully API functional, so-called 'standard implementations' for all the components in an ODK stack, with which others - like myself - can readily test their tools against for conformance. I don't think these standard implementations are so much lacking, rather at present they can be tricky to get up and running on your own - ODK providing these as a service can only better foster the growth of an interoperable tool ecosystem.

1 Like