A tiny treatise on software revenue streams
Let me quickly go through various options:
Capitalizing on IPRs by granting licences?
That’s soo nineties that I don’t want to go near that. In my subjective evaluation it’s a niche model right now, still working well for software that is both necessarily desktop based, niche software, and complex. The open source movement seems to have just not enough drive for these cases. An example would be integrated programming tools for niche languages – like RubyMine, which happens to be one of the two software packages I ever paid for. I don’t think ethnographic software is complex enough to make this model work for it.
The other case where the licencing model still works is producing darn cheap software and selling licences in high numbers – such as for “apps” – but that’s not for ethnographic software either since it’s a niche.
Capitalizing on software with the SaaS model
We intend to offer open ethnographer as a web-based service to clients anyway, so we fall into this category. It can work well both when the software is free (“open source”), partially open source (“open core”), or commercial (“closed source”). Drupal and WordPress are both examples where SaaS works well with open source: open source made them so popular that for example Drupal software agencies can make a decent living, and hosted WordPress is the revenue stream of Automattic, the company behind WordPress.
There’s one case though where an open source model does not harmonize well with a SaaS revenue stream (of getting paid for provisioning the specialized software hosting on a web platform): when there’s a strong incentive to duplicate the business model of the SaaS provider because it seems like “easy earned bucks”. That’s the case for marketplace software, our recent example: there are very very few and only low-quality marketplace platforms available as free software, very different from the situation with webshop software (I know from an analysis to find a base software for Epelia). It is my understanding that we don’t have this problem with provoking copycats: open online ethnography is a niche market, and even within this niche, every consultant / provider has their own, even more special skillset that is far form just software, and not easily copied. So even when open-sourcing Open Ethnographer, I think we would not do much harm to ourselves in terms of raising our own competition.
Conclusions
Open source is frequently preferred because it avoids the vendor lock-in. So for a minimum, our software should have an open API, and open source data import and export tools that work with this API and can be adapted by clients to their needs. The “Drupal RDFa to RQDA” export script that I have to create for the Spot the Future Ethnographic Toolkit would be an example (and maybe I can get it done in a Drupal-integrated way that allows to reuse it later in Open Ethnographer). Making the import / export tools open source allows for unforeseen open data related uses as well. Customers for which we did a consulting gig on our SaaS platform would surely appreciate if they can in the end take out their own data and go on hosting and analyzing it with the exact same tool that the consultants used – that would be a selling argument of a fully open source product.
Open sourcing software later is in my view esp. helpful when the software can not be easily copied after exploring its user interface – either because it’s very complex or because it contains new, “secret” problem-solving algorithms. That can allow to slow competitive developments down so much that the first player can get a headstart with a significant market share. However, in the case of the open ethnographer tool, somebody with sufficient funding who looks at the UI could contract developers to have it re-implemented in a short period. Here, it might be better for gathering market share and good publicity to be the free and open loving company right from the start. A bit like Goteo is positioning itself in the world of crowdfunding platforms. Those with the technical expertise to self-host the software and conduct their own ethnographic research will do so of course, and we’ll lose these customers to open source. But some will come back to get custom additions to this open source software from TwinBit. And by being well-known through a well-known, testable artifact (the software), we’ll also earn the trust of many more customers lacking this expertise.
So my proposal would be making this open source right from the start. Or maybe, to do so with a big media sha-bang once the first full release is ready, and together with unveiling our hosted services and offers to clients. Goteo did it quite alike.
Diverging opinions, anyone? 