Brent Atkinson TSC Application - 2017-11-27

Brent Atkinson (@Batkinson)

Medical Care Development International

What contributions (e.g., issue triage, tech support, documentation, bug fixes) have you made to the ODK community?
Fixed multiple defects and some feature work in Collect and Briefcase, some issue triage and support via community channels.

How do you believe your contributions have benefited ODK?
External app support in Collect become more generally useful (can internationalize external app labels from the form, for example), Briefcase contributions made large-scale data collection feasible and found and fixed defects in fundamental Briefcase functionality maintaining its core purpose (backup of forms and their submissions are portable).

What do you believe the top priorities for ODK are?
Offline, server-less, fault-tolerant, technically accessible, technically sound

How will you help the ODK community accomplish those priorities?
I have worked in environments that have required these traits and leveraged them successfully in ways where few other tools could have been (easily) used. I believe I can be a strong advocate for maintaining traits that may not be viewed as important outside many developing-world countries.

How many hours a week can you commit to participating on the TSC?
It would depend on timing of activities, but around 4-8 hours weekly.

What other mobile data collection projects, social good projects, or open source projects are you involved with?
I contribute to a number of projects, but predominantly I work on a campaign information management tool (called CIMS) for significant malaria control efforts and eventually mass vaccination and elimination efforts on Bioko island, Equatorial Guinea.

Please share any links to public resources (e.g., resume, blog, Github) that help support your application.

Hi @Batkinson! Thanks for applying for the TSC and extra thanks for the thoughtful PRs you've sent in over the last year.

You've worked on Open X Data, an open source data collection project that had a great run, but eventually had to shut down. What, if any, are the lessons learned that you'd bring to your role on the TSC?

On a more technical note, Briefcase was built to provide backups/portability and decryption of forms, but a server like Aggregate could probably do that work and we'd have one less tool to maintain. I'm curious if you agree, and if you do, what would your approach be to get from where we are today to that ideal?


I learned a lot working with the OpenXData project(s). Most of the big
lessons were non-technical. Here's a quick list off the top of my head:

  • There is little point to strong technical leadership without strong
    project management
    • Making good decisions can sometimes be difficult, but waiting to
      make everyone happy makes them impossible
    • Be realistic, and honest about your status - for example, seeking
      outside help and not telling the rest of the group you think you're in
      trouble -> mega problems
    • Make your goals painfully clear (and concise), publicly refer to
      them, sanity check them, and mercilessly change them to ensure the vision
      and effort are well-aligned (for member and for others stopping by - they
      may choose to help based on it)
  • How you build the community around the project matters and a community
    that lasts makes the rules for membership clear, consistent and aligns them
    to the desired outcomes.
    • Meritocracy is about earning it, and that means everyone
    • People quickly figure out what the real community rules - so be
      aware of the informal rules you establish - the official rules
      have to mean
      something or you should ditch them
  • Don't waste time catering to forks, make the mainline fast and
    consistent direction
    • Velocity on core technology pulls contributors and contributions
      into the fold
    • Catering to forks de-prioritizes consensus-building over
    • It's tempting to take something that's shiny, but discipline around
      introduction of contributions (and members for that matter) is a
      good policy
  • Funding warps good communities fast if you're not careful
    • Funded projects put pressure on community-driven work
    • Funding should never be used as a good reason for moving
      faster/further than otherwise - it should still fit easily within
      well-established community guidelines
    • Being a member of a funded project should not allow members more
      access based solely on that fact - vet them against the same
      rules everyone
      else would be
    • Acting otherwise only sends mixed messages and sets up incentives
      (and disincentives) that don't support disciplined decision making (and
      contribution, etc)
    • Developers that are already full-privileged members have to be
      careful to "put on their community hats" even if it means their funded
      project has to wait
    • Because of the above, you need to introduce people you trust to
      have this type of discipline (and make it clear what it's important)

As for the more technical question aobut moving Briefcase's functionality
into Aggregate:

  • Briefcase is far simpler than Aggregate, something I believe people
    underestimate when it comes to value (deployment is nearly a non-issue)
  • Its power is that simplicity - forms and form instances, that's it -
    no database (aside from instance tracking, which is really residual data),
    no web server required, no internet required (maybe LAN though)
  • Aggregate in contrast, is a lumbering beast whose technology was once
    trendy and well-supported but it didn't age well (GWT, AppEngine)
  • Aggregate is riddled with complex run-on code, and the decision to use
    AppEngine for its primary deployment limits its sanity (storage
    limitations, invisible but drastic influence on what would be idiomatic
    code otherwise)

If I were to move forward with either of these tools, I would probably
start closer to Briefcase's model of things than Aggregate's. I would
consider storing the forms and form instances as unstructured documents. I
would not attempt to deconstruct the forms into relational tables, but may
provide abilities to generate fast views on them. I would try to maximize
flexibility by allowing interpreting different, but overlapping form
schemas (in other words take advantage of XML and JSON-type ad-hoc schemas
rather than relational-like structural rules). I would probably try to turn
Aggregate more into an extremely light-weight API and less a web
application. I would favor OAuth rather than HTTP Digest. I would also
probably design the internals of Aggregate to be usable outside of an
HTTP-context, regardless. If Aggregate was designed more this way, I
believe I would support something like getting rid of briefcase. The
encryption/export piece doesn't seem like core technology to me, it seems
like a yet another (albeit important) bulk-oriented API client function.
Based on existing protocols, I expect encryption may require revisiting an
improving existing protocols to allows for more powerful usage scenarios.