So in the spirit of openness, here’s my take from the ODK convening so far. (After more internal discussion and planning, Dobility will put out more polished and thought-out statements in the coming months…)
Under Nafundi’s leadership, the ODK community is growing rapidly and moving fast. Much good can come from that, and we wish the community well. Here at Dobility/SurveyCTO, we’ve always aspired to contribute more and collaborate more deeply with the community, and it would very much seem that now is the time. But looks can be deceiving. Given the current direction of the community, we believe that there’s actually shrinking scope for us to collaborate effectively -- and so we’re now planning to chart a different course.
Much comes down to the mission of the core ODK platform. It’s undoubtedly a laudable goal to serve a growing range of direct, end-user needs with a platform that’s not only open-source but “free” in a more complete sense of the word: free from the need to have a high degree of technical skill (or a big budget for hiring consultants), free from the need to spend lots of staff time wrestling with bugs or configuration issues (or again, a big budget for consultants), etc. I can certainly see why donors would sign up to fund such a goal. But I believe that it might be a bit over-ambitious -- which is saying a lot, given how idealistic and ambitious I personally tend to be!
Part of the issue is the community’s emerging approach to collaboration, which is captured well by Yaw’s description of “rowing committees” vs. “steering committees”. If every user-facing feature and UI choice is subject to a design-by-committee exercise driven by -- and potentially populated exclusively by -- developers… well, I don’t think that I’m alone in the world in suspecting that the best user experience might not result.
Another issue is just the amazing diversity in user types and needs in this space. Even if Nafundi could build the greatest open-source developer community ever seen, complete with the best UI and UX people in the world, could they address every need? One look at the breadth of today’s ODK ecosystem, and one would be tempted to conclude, “no, of course not.”
There is ample evidence that open-source communities most often thrive in satisfying developer-to-developer needs, and there are, in fact, a wide range of behind-the-scenes, core-infrastructure components in ODK. These include specifications, shared libraries, and even “reference implementations.” And while those reference implementations have been directly used by more-technical end-users, they’re more often used as a starting-point by a broader ecosystem of consultants, integrators, and service providers.
The ODK community might have embraced a model where the broader ecosystem (including so-called “forks” like SurveyCTO and others) take a lead role in delivering services directly to end-user project teams, tailoring, extending, and packaging the technology and supporting end-users with a variety of strategies. In this model, the community would exist as a vehicle to support collaboration on core infrastructure shared by many in the ecosystem. And there might have been built-in recognition that there were different funding models that work for serving end-user needs: some might charge one-off consulting fees for installation, configuration, and support, and some others might try less-one-off models where flat product or support fees are charged instead. Ideally, the ODK community as a whole wouldn’t take a strong stand on which way of funding end-user-facing services is inherently good or bad. (We at Dobility, of course, have a strong opinion on this!)
Now, of course, there will be those quick to point out that collaboration on core infrastructure is still very much possible, even within an ODK community that has broader ambitions to serve direct end-user needs. But the fact of the matter is that, so long as the implicit or explicit goal of the core community is to put forks and other large-scale service-providers who charge fees for their services out of business, there will be too much tension. There will always be conflict over where cooperation ends and competition begins. And, in practice, it would be too difficult for fee-charging providers who volunteer time to collaborate with the broader community to assure that their time wasn’t undermining their own ability to charge fees for their work. For those who charge hourly fees for one-off consulting, the situation is luckily far less complicated; but for those using different funding models and trying to realize economies of scale, it’s trickier by nature. (We’re likely to disagree here, and that’s okay.)
I use the past tense here because, while the ODK community can always revise its course, it seems clear that a major focus of the newly-revived community is better and more directly meeting end-user needs (as opposed to explicitly supporting or embracing a broad ecosystem of end-user-facing providers). And what a wonderful mission that is: great software free, meeting an ever-expanding array of needs in every corner of the world. It’s a compelling mission, and I can see why the community -- and its donors -- would be excited about it. Even though we’re unlikely to contribute or collaborate directly, we definitely wish the community well.
Meanwhile, we’re going to do our best to demonstrate the potential success of an alternative model. Fingers crossed that we don’t end up as a cautionary tale!
All the best,
Chris
P.S. I appreciate the opportunity to come and take part in the ODK convening here in Seattle. Many thanks to the Gates Foundation for making that possible, and to the community for always trying to find ways for rogue operators like Dobility to be included.