Since I am going to make some potentially controversial observations about the digital health industry and, to some extent, the development sector in general, I think it is fair to begin with a proper self-introduction. I want to make my interest in the subject clear from the onset, as well as stake claim to what I think (vaguely) qualifies me to speak on the matter.
My Software Development Background
My name is Gitahi Ng’ang’a. I am the founder of Hoji, a Nairobi-based software company that provides mobile data collection and analysis software solutions for field-based research. Our clients are primarily NGOs, government and independent research consultants. I am a trained statistician, professional software developer and technology entrepreneur. Before founding Hoji, I worked for 6 years at 3 different organizations.
The first company I worked for was System Partners. They are the developers and vendors of Funsoft, a widely-adopted Hospital Information Management System. My second employer was KEMRI/CDC. While there, I helped develop applications for field-based data collection and did some work on interoperability and unique patient identification through Mirth Connect and the OpenEMRConnect project.
At my third job with the International Training and Education Center for Health, I mainly worked on the organization’s flagship product at the time, KenyaEMR. KenyaEMR is a custom distribution of the popular OpenMRS project. I was also involved with BLIS, OpenELIS and GBVIS to a much lesser degree. Over the years, I have consulted for a number of development organizations as a software professional.
On my personal laptop, I run Arch Linux. Arch is a minimalist flavor of the free and open source Linux operating system. Although it is world-class software, I pay nothing to use it. For my software programming work, I use JetBrains’ IntelliJ IDEA and gladly pay $9 a month for the privilege. I use various other open source and proprietary applications, the most expensive of which costs my company $2,500 a year. And yes, it is worth every penny!
I say this to point out that I am not dogmatic about open source versus proprietary software. I choose my applications simply based on need and whatever best suits the job at hand. And that’s fine. Variety, after all, is the spice of life.
Unhealthy Open Source Software Obsession
Having been in Kenya digital health and the development sector for nearly 10 years now, I have long since observed a pervasively unhealthy obsession with free and open source software. Almost everyone instinctively assumes that free and open source is good, and proprietary is bad.
If Health IT were George Orwell’s Animal Farm, this attitude would be equal to the propagandist maxim “Four legs good, two legs bad!”. In the remainder of this article, I am going to explain why I disagree with this view.
For the avoidance of doubt, free and open source software refers to software whose source code is shared openly and publicly. Anyone is free to use, copy, study or modify the software however they like, subject to any one of several open source licences.
It is important to note that “free and open source” is merely an assertion of the freedom to use software with few or no restrictions. It says nothing whatsoever about the ability to deploy the technology free of charge. Industry insiders like to describe this as “free as in speech, not free as in beer”. The terms libre (meaning freedom), and gratis (meaning zero price), are occasionally used to distinguish between the two frequently confused meanings of the word “free”.
To be fair, libre software is also often gratis. But as the old aphorism goes, there is no such thing as a free lunch. You do pay something, even when the cost of obtaining the application is zero. The time you spend configuring the software, for example, has a cost. As does the time and effort spent scraping the bottom of the internet for bug fixes and workarounds because there’s no technical support team on call.
On the other hand, proprietary software refers to programs whose source code is privately held. Only the application’s owners can use or modify the source code. Just like open source software, proprietary technology can also sometimes be gratis. But here too, the end user incurs indirect costs e.g. time spent watching advertisements, as is common with free mobile apps and applications like YouTube.
We Use All Software Types Daily
For context, the table below provides a few examples of open source applications alongside their proprietary alternatives. It includes both personal and enterprise software listed by domain.
Hopefully, you can recognize at least one and maybe more of these pairs of applications.
Now, If you are reading this on a computer running Windows or Mac OS, if you typed your last report on Microsoft Word or send your emails via Gmail and not Tutanota, then I hope you can already begin to see the folly of taking a dogmatic attitude towards the open source versus proprietary software debate.
Yet, dogmatism is precisely what you see in the digital health sector, and to a large extent, the NGO world generally. I have attended many a gathering where the mention of proprietary software is almost literally taboo. And this, I think, is patently unhealthy.
It is unhealthy because it denies potential beneficiaries of great software the opportunity to appraise available alternatives in a fair and rational way. It dismisses perfectly useful and cost-effective applications without due consideration, ostensibly because they are expensive and unsustainable merely by dint of being proprietary.
Two Common Proprietary Software Criticisms
Let’s examine these two points i.e. cost and unsustainability – easily the two most common criticisms leveled against proprietary software.
1. Proprietary software is expensive, open source is cheap
The theory here is that proprietary software costs more overall than free and open source software. But does it? Not necessarily.
Firstly, while proprietary software has clear and predictable direct costs, open source solutions can be insidiously expensive. Often lacking a unifying vision bearer and having many influential stakeholders, open source projects rely on complex community networks to drive consensus and mitigate fragmentation. This necessitates multiple meetings, conferences and emails in order to make progress even on fairly minor decisions.
Now, don’t get me wrong. I am not saying that this process is inferior. Properly managed, open source communities have proven their ability to generate truly game-changing applications. Ubuntu Linux by Canonical is a shining example of this. I am simply saying that it is important to acknowledge the time and money it takes to run and participate in open source undertakings, and that it adds up both directly and in terms of opportunity cost.
Secondly, most open source applications, including many that I use myself, are objectively more difficult to set up and maintain than their proprietary alternatives. This happens because open source projects rarely have big budgets or large dedicated teams, so they prioritize solving core domain problems over fancy user interfaces and fluid onboarding processes. Also, many open source projects arise out of the needs of the technical experts who build them. As a result, they are developed first for technically savvy people and only secondarily for ordinary folk. R is a great example of this.
Again, I am not saying there is something wrong with open source. I love open source, and I would be far poorer as a professional and an entrepreneur without it. But it is important to acknowledge that a less than straightforward set up process demands time, both to build the necessary capacity and then to actually deploy the solution. In some cases, the help of expert consultants is unavoidable, and anyone who has tried it will tell you it does not come cheap.
2. Proprietary software is not sustainable, open source is
This is the second common criticism raised against proprietary software. Potential clients sometimes ask me, “What if Hoji closes down tomorrow, what happens then?”.
This is a valid concern, of course, particularly in the context of public health where potentially thousands or millions of lives depend on a particular digital health intervention. In fact, any practitioner who doesn’t address themselves to the question of sustainability is being downright irresponsible.
The problem, I think, is resorting to the lazy answer that open source is sustainable and proprietary is not. Four legs good, two legs bad!
It is not that simple.
Many private hospitals, for example, have operated proprietary Hospital Information Management Systems for years without a problem. Equally, many projects have suffered at the hands of unscrupulous private companies who deploy complex applications and then fail to support them or worse, demand inordinate amounts of money to do so. Shame on them, they pollute the reputation of those of us trying to do responsible and honest business.
In the same vein, there are vastly successful open source projects out there creating efficiencies and saving costs for the organizations that use them. There are also many open source deployments which, for all their good intentions, are stuck in a perpetual state of pilotitis, gobbling up thousands of dollars while delivering little to no tangible value.
So the solution to sustainability is not faction wars between open source and proprietary hardliners. Such hostility is unhelpful at best, and hypocritical at worst – with the possible exception of the great Richard Stallman who takes his libre persuasions exceptionally seriously.
All Software Types Have Their Place
The solution to sustainability is a thoughtful, honest and systematic analysis of the problem at hand against all possible solutions – whatever their licensing scheme may be. And in some cases, the best solution is open source. In other cases, however, proprietary software is the superior alternative. And there is nothing wrong with that.
For instance, software used to solve narrow-scope one-off or once-in-a-while problems may not justify the investment and risk necessary to deploy a successful open source solution. The same goes for mission-critical applications where downtime or security breach is completely unacceptable and professional support is paramount.
A good example of this is the platform used by the IEBC for the transmission of real-time election results in Kenya’s general election of 2017. You don’t want to be scouring online forums for solutions when the thing goes down and the wrong candidate is winning. The same can be said of the platform used for collecting data during the national census of 2019.
On the other hand, longer-term deployments with complex and dynamic requirements are likely better served through open source applications that allow for finer-grained control and freer innovation. The District Health Information System (DHIS) used by ministries of health in several countries is a good example of this.
Choose Rationally not Religiously
In conclusion, I think we need to stop regarding open source and proprietary software as being antithetical to one another. In choosing between them, we should embrace rationality and not dogmatism. Private enterprise understands this – think private hospitals, banks and telcos. Public entities not so much. And look who between them runs more efficiently!
What do you think? Leave your comments below.
Originally published as Why Health IT’s Obsession with Open Source Software is Unhealthy
Join Us to Discuss Open Source Software Costs
USAID has introduced the Software Global Goods Valuation Framework to enable donors, software development organizations, governments, and others to estimate the cumulative development cost for software global goods. Recently the framework valued 3 global digital health goods at $109 million dollars.
Please RSVP Now for a lively online discussion of the Framework and how we can use its two key outputs to better value digital health solutions:
- The retrospective development costs of a software global good
- The ongoing costs of maintaining and further developing the software
Together these estimations of financial investments into software global goods provide a calculation of their valuation to-date and can serve as a data point for consideration by decision-makers in selecting software systems to meet country public health needs.
Please RSVP Now to engage with four people intimately involved with the framework:
- Merrick Schaefer, who worked on the valuation framework at USAID
- Theresa Cullen, with OpenMRS at Reginstrief
- Jonathan Jackson, with CommCare at Dimagi
- Wayan Vota, with iHRIS at IntraHealth International
We’ll dive into new research from USAID and the Boston Consulting Group that analyzed the development costs and maintenance needs of OpenMRS, Commcare, and iHRIS using the Software Global Goods Valuation Framework and how each of us are using this new tool in our global good development process.
What are Global Good Software Costs?
15:00-16:00 GMT – February 27th 2020
RSVP Now for Virtual Participation Information
Just to be clear this is not the biggest problem out there. The main issue is procurement of I.T. goods by people who know nothing about technology. Its like sending me to the market to buy ingredients for a pizza. Computers operate on a principle of GIGO – garbage in , garbage out. As long as procurement is undertaken by interns, worse decisions than this simple debate of open versus proprietary. Most of the people making procurement decisions don’t even know that difference between the two, so I wouldn’t worry about it. Very low on my richter scale.
Did also want to highlight 2 tools that have been developed to try to address this knowledge gap
Digital Health Investment Tool – https://www.mcsprogram.org/resource/digital-health-investment-review-tool/ and the Digital Investment Tool – https://www.usaid.gov/digital-development/digital-investment-tool
To say that people are obsessed with Open source software today is a misrepresentation of facts. Some people may have been obsessed with open source in the first decade of the 21 century, but that isn’t the case anymore. There are a number of reasons for this, but I would like to discuss only one. And that is, the leading software companies that previously fought open source initiatives have since softened their stand after realizing that open source is simply unstoppable.
In fact, a lot of these companies now support open source projects and/or initiatives. And they haven’t stopped there; some of them use, develop and offer open source software. I’ll give a few examples. On Microsoft’s Azure, which is its cloud platform, one can access and run open source database programs like MySQL, PostgreSQL and Maria DB among others. In fact, as of 2017, Linux accounted for 40% Azure. Microsoft has even gone ahead and developed its own Linux distribution. And you can now run Linux on Microsoft platforms.
Oracle is another example of a proprietary software company that develops and provides open source solutions. After acquiring Java and MySQL, Oracle has continued to offer them freely to users. In essence, they have upheld the principles upon which open source software are developed and used.
Moreover, employees of these proprietary software giants now participate in open source events. A case in point is Satya Nadella’s keynote address at the Red Hat summit in 2019. To listen to his presentation, visit https://www.youtube.com/watch?v=7YYqJZIvw2U . This could not happen even 10 years.
I could go on and on, but here is the point. The competition is no longer between proprietary and open source software as it were. Instead, technology firms now compete on the basis of how best their solutions deliver value to the customer and other key stakeholders. In other words, it is customer that determines the competitive dynamics today. Technology firms simply respond to customer or market needs by creating innovative solutions that not only solve business’ or customer’s problem but also deliver economic value added (EVA) to them.
What this means is that firms will use whichever technology that can enable them meet the ever changing needs of customers without giving undue consideration to the philosophy behind the development of the software or tool. In some cases, proprietary software firms are forced to collaborate or enter into strategic alliances with open source firms to achieve their business goals. And the converse is true too.
Lastly, I think it is important for people to understand the key freedom that open source affords users. The freedom to run, copy, distribute, study, change and improve the software has been responsible for most of innovation in the IT industry. Open source is in my view the best thing that ever happened to humanity in the technology space. Let us shift focus and attention from competition between the two sides of the tech sector to innovation. This way, we will use technology in a way that benefits us optimally as entrepreneurs, businesses, computer scientists or technologists.
Derrick, unfortunately you are responding to arguments I haven’t made. You will do well to lookup “straw man fallacy”.
I could not resist the temptation to post a second comment after rereading Ng’ang’as article. First, Gmail is a free web service and therefore it is not accurate to classify it as proprietary. It does have alternatives as you indicate but it isn’t proprietary. In fact, you should have replaced Gmail with MS Outlook and taken it on the left side with the likes of yahoo and other free web client software.
The source code that we are talking about in open source is that of the tools or programs that are available to everyone to use to develop solutions to problems. We aren’t talking about source code for a program that you develop for a particular banking, education or healthcare client. Such solutions become proprietary to them even though you may have used an open source tool to develop them. This distinction needs to be made.
I would like to suggest that you visit https://www.gnu.org/philosophy/free-sw.en.html to understand what open source really means.
Care to share a link to the Gmail source code?
Agree with the author and also agree (partially) with Cavin’s point. It is true that procurement may be run by people who are not knowledgeable about technology, but equally true that the IT advisors as well as the procurement people have likely been influenced by the open source good, proprietary bad, and not just bad but even evil or unseemly, which can end up with poor decisions being made.
It cuts both ways, there s also bad proprietary software. In my experience most people seem to think Open source is bad. In the few cases where I see open source portrayed as good, it feels good, not that its true, it just feels good
Excellent post, Gitahi! Very well-reasoned and substantiated. You said what you said. Also incredibly happy that ICT Works identifying voices from the countries where digital development is most often (mal)practiced.
And you know me, Ronda. I try very hard to get posts from every constituent!
Of course, hence my hat tip! One of the best posts in a while!
Thanks Ronda.
Thanks for your post, Gitahi. You make some very good points which are not limited to the software industry. I worked on the team that developed the first genetically engineered vaccine (in the private sector) and then worked closely with the WHO on a public funded initiative- the Children’s Vaccine Initiative to create a whole new generation of vaccines recognising the game changing nature of genetic engineering. However the Children’s Vaccine Initiative failed to deliver. Fortunately Bill Gates’s involvement amongst a number of factors helped it evolve into the hugely successful GAVI initiative which accommodates the public and private sectors, and proprietary approaches. Managing that evolution is not easy and I needed to make that transition as I sought investment for an initiative during the last Ebola pandemic. https://www.elrha.org/project/simulation-based-training-tools-jit-capacity-building/ . Unable to raise investment as a result of declaring everything open source, it became….just another pilot. Gitahi, you have raised a very important issue.
I would be really interested to know why the Children’s Vaccine Initiative failed to deliver. As the organizer of Fail Festivals, I am keen proponent of talking about our failures.
Interesting to learn how this works in your sector. I think it comes down to the same thing: money gets spent one way or the other, but how do economic incentives for producers get aligned with value in a sustainable way.
Thank you for your post, Gitahi. These are the same thoughts I have been mulling over for the last few years. I think something that would add to your argument would also be to look at who is developing FOSS for digital development versus who the intended user is. I think what can make FOSS even less sustainable is if there are not people from the intended user groups leading the development- because as you point out, there is no help desk to call when something goes wrong. This is a great article to start a great conversation about what it really means for software, and digital development, to be sustainable.
Your point – who is developing FOSS for digital development versus the intended user – is something that the entire international development industry wrestles with. Endless projects are designed with the donor in mind, vs. the user. A great example is the play pumps failure where water pumps were turned into merry-go-rounds because that’s what seemed cute (and fundable) to the donor, instead of investing in tried and true hand pumps.
This is a great article Gitahi with lots of hard, practical truths. It helps that you have had a direct experience in the open source digital health world and now are a successful entrepreneur in technology.
I would like to add however that it is also important to expand the value of FOSS to include the collective intelligence and wisdom which is unabated particularly in a mature open source community. When highly gifted members of a mature functional community truly from different but necessarily complementary backgrounds “freely” contribute their intelligence, expertise and time to build a good software, that in my opinion is one key differentiator between “FOSS” and proprietary. At that moment it’s not about the end product/service that then gets deployed to a customer. It’s really about the input and quality of the software built by that gifted team of volunteers. Contrast that with or the same process for “propriety” software where similar a closed team of talented experts using their best wisdom, intelligence and capabilities build what they believe is the best software for specific purposes. Again nothing wrong with that approach and process. There’s lot of evidence for and against the resultant software from both approaches with some of that evidence showing great benefits of the software built the open source way and others for that built the proprietary way. Some of that evidence is philosophical and some quite high quality useful evidence. The Subsequent processes for both approaches of then taking that software to market and how all that happens is where there have been untruths that you have mentioned where some FOSS initiatives have done disservice.
Personally I don’t see the clear cut dichotomy generally propagated by open source versus proprietary, but rather the multiple layers within it that lend to usage of one versus the other. If the development process of open source were as efficient as the one for proprietary from business efficiency perspective, then by all means you can rightly argue that the resulting open source software would always be superior just based on the fact of contributors to that software. But we know that always doesn’t happen and that process inefficiency gets carried over into the resultant software – and if that software is then I efficiently taken to market, we know the results!
I clicked send too fas
The last thing I was typing is that a usually poorly understood part of open source is that it is not a ready made product ready for use by a customer unlike most proprietary products. I see most of open source as “component utilities” and when sometimes put together as a “platform” to build off of greater software products. Most open source communities then try to their best knowledge solve those fundamental and common components and utilities that any application software developer would nevertheless have to build first for their application software that has market intelligence to function optimally and cost effectively deliver value.
What the open source digital health world is grappling with is how to build in Production and maintenance cost effective efficiencies into their business processes underpinned by sustainable business processes which work very well with proprietary groups.
Steven, this is a great point: open source is usually “component utilities” vs. finished consumer facing software product. Too many software developers have sold Open Source as a ready made solution (and it is for them), instead of a reference design for components that will need to be integrated into a usable system.
I cannot count how many times I’ve heard non-techies ask why they need to pay for software development with open source, as if they can just download something already perfectly customized to their needs.
I also agree with Steve’s point. The majority of open source software is rarely user-facing, and when it is, it is rarely user-friendly or professionally supported. When it is user friendly and professionally supported, it is because someone has taken their time to make it so – and more often than not, built a business model around it. Examples like MySQL Enterprise, Red Hat Linux, IntelliJ Ultimate and even SurveyCTO come to mind. But each one of these solutions, for all their desirability, involve a direct cost. And buying them should not be perceived as a bad thing, anymore than buying an office chair or an airline ticket.
Hi,
I definitely agree that one should “choose rationally, not religiously”, even as an open-source developer and CEO of an open-source startup.
I would note that some of the best examples of open-source software were missed here.
Web Browser: Internet Explorer (proprietary) | Chrome and Firefox (open-source)
Mobile OS: iOS (proprietary) | Android (mostly open-source)
Web Server: Microsoft IIS (proprietary) | Nginx and Apache (open-source, Nginx is running ICTWorks)
Blog content management system: Squarespace (proprietary) | WordPress (open-source; and it is the content management system for this ICTWorks)
Whoa! Looks who’s back with great examples of Open Source, and yes, ICTworks runs on Open Source. Don’t forget AMP for those who are reading links from the Google.
Procurement of ICT goods is a mess in the developing and developed worlds as seen in the Iowa primary circus [pun intended]. High school students could have developed a better election app, in any case there was even no need for a mobile app. Am sure the company selected to develop the election app went wax lyrical over their expertise. The intern who selected that company was like the proverbial deer in the headlights. This open source vs proprietary is really a side show everyone trying to ensure they butter their side of the bread. ICT projects have a higher failure rate than most other industries. The reasons are varied and I wouldn’t be doing justice to try and explain them but at the end of the day, its a case of trying to make an omelette without breaking the egg. There s alot of misinformation about open source software, I have seen examples here with people claiming its developed as a utility, some kind of patch , maybe that is from their limited knowledge or understanding. The two models are symbiotic , they feed off each other, without Windows maybe Linux would still be command based, organizations such as UNICEF have a preference for open source. In their world they think its cheaper or makes sense. The bottom line is, its better to be pragmatic and select software that works and solves a problem, for example I havent seen many organizations using open source video conferencing software. The market is dominated by proprietary vendors.
Whether software is open or closed is unrelated to procurement in majority of such processes. Procurement decisions are typically made based on capacity to select the right tool for the job (further described in technical, procedural and legal jargon in procurement policies), and motivation of the procurer. Half the time motivation is for everything else except truly solving the problem and mostly is driven by self interests around financial gain, power, influence etc
The comment on “utility” from “limited knowledge or understanding” is about the the tool itself including the process or development, and not how it is used or procured. There’s a difference!
If you haven’t participated in procurement you can say that
As a matter of fact I have. I have supported more than 10 countries in Africa in digital health and been part of procurement boards/tender boards, technical working groups both in public and private health sectors. I speak from more than 15 years first hand experience. Let us leave theories out and talk facts then we will solve real problems.
Great piece, thank you for this.
I think it could be appended to with a paragraph about the complexity of OSS licenses out there.
I’m concerned that adopters of OS systems don’t fully understand the risks of implementing something that has a network restrictive license, for example.
Steven, am sure you can’t share just 1 link for a software tender, where the license is not specified. I already mentioned UNICEF will specify the software needs to be open source. Other organizations like the World Bank will talk about ‘off the shelf” and you can go wax lyrical about definitions of off the shelf, but they are referring to proprietary if you are able to read between the lines.
Since you claim to have been involved in procurement of I.T. projects, aren’t you deflecting the fact that most of these ICT projects fail as a result of the flawed procurement practicses you have been a part of, or the procurement teams are blameless in all this. Like I stated in an earlier comment, everyone fights to keep their side of the bread buttered.
By the way the incompetence of procurement teams is not down to simply based on the license type specified in tenders, but as result of selecting incompetent companies. This requires some expertise in software development which most procurement teams lack.
I like my bread buttered, but I don’t have to eat buttered bread all the time. This is why such debates provide little to no value, just like drug dealers each person wants to keep a stranglehold on their street corner. There’s a lot of resistance when opinions that seem to threaten your position on your turf.
Cavin, you are completely missing my point about my opinion regarding open source and proprietary software. I’ll try again…
My argument for open source is as far as the benefit such software gets from broad contribution of different experts and implementations. My point is not about how it is the. adoption, use and maintenance through whatever methods (formal procurement or not) which present completely different issues from the tool itself.
It’s good you have finally abandoned the procurement rabbit hole.
There’s a general misunderstanding of how open source software works. It’s automatic or a given that every open source software will benefit from the brightest of minds.
If you look at most open source projects they are started by a group of individuals could be 1-3, most times one only. It’s only if the original project is built on robust principles that it’s likely to have a chance of attracting the community. OSS projects also have a gatekeeper, and the direction is down to how open he is to new ideas. Am sure you have been involved in Open MRS which was designed badly.
Being open source doesn’t exactly translate to benefits to the community, actually most of these open source projects are only breathing due to donor funding, they would have been in the grave yard before the even the last grant dried.
When I address the broken procurement of ICT products it;s simpy because that is how software is acquired, it doesn’t fall from the sky. They are many snake oil salesmen who murk the ICT waters. They are able to write good proposals even though they are low on substance and get awarded projects which end up failing. We shouldn’t be having a conversation about open versus proprietary. If the procuring entitites were abreast with technology, this wouldn’t be an issue.
Am actually happy when organizations adopt open source software. The good ones like Linux, Drupal, Apache the list is long. Government institutions can save a lot of money if they used Linux and Open Office for example. But the cost savings are not a given, just because you are using oss. German is a good example of a country that uses open source, the city Munich recently rolled back Linux and they are going back to Microsoft Windows.
Great article Gitahi!
For a long time I have been concerned by the “4 legs good, 2 legs bad” mantra. This simplistic approach actually does FOSS a disservice, as it does not sufficiently highlight where open-source is the right option.
A couple of reflections from the Civil Registration space, for which we have developed OpenCRVS (see http://www.opencrvs.org) as an open-source alternative to proprietary solutions. We typically refer to OpenCRVS in this way to emphasize our belief that the market needs an open-source solution, but that doesn’t mean that it’s the best solution for all contexts.
Point 1: Given that the procurement process has already been dragged into this discussion, from my perspective the biggest failure in the whole “digital development cycle” is defining the business requirements. In the civil registration world these are often a rehash of the existing manual processes, as if digitization of these would bring great efficiencies and service improvements. At this point, the choice of FOSS vs proprietary is pretty irrelevant.
Point 2: I am often spending my time myth-busting open-source software, responding to comments like “We don’t want open-source as we are capturing personal data and we need to keep it private”. I can cope with this misunderstanding and do a FOSS 101 (if there is a great explainer that others use, please share), but this means I have less time to spend in the real discussion, debating the relative advantages of different solution options (including both open-source and proprietary).
Thanks for stimulating the discussion 🙂
Totally agree, Ed. Especially with: “This simplistic approach actually does FOSS a disservice, as it does not sufficiently highlight where open-source is the right option.”.
If someone argued that proprietary software was the only answer, I’d disagree just as vehemently as I do with people who think open source ought to have a monopoly on ICT4D.
Technology decisions are complex, and their consequences are far reaching. The least we can do for our industry is to be honest and rational in the way we choose. Simplistic maxims like “always use open source” or “don’t put anything in the cloud” are not how to maximize value.
Defining business requirements can be a challenge but it shouldn’t. Maybe one of the self inflicted challenges arise when the procuring entity wants an application that can wake you up at 6:00 am, and if you don’t wake up, it sends u an SMS message. This software should be able to make you a cup of tea/coffee if the person who wrote the requirements is from North America.
One of the reasons these projects fail, which is more interesting to me is down to a very simple thing. The requirements look like the old testament. And am not making this stuff, I have seen this on numerous ocassions and can send u a link if u think, I have lost my marbles. The KISS (Keep it simple stupid) princple is lost on many people.
Common sense dictates that most useful software applications have very few features, and are simply added with time, taking a look at Microsoft Windows, Facebook, Gmail, Skype can point anyone in the right direction.
Even the Mobile phone which many look at as a revolutionary product, started without SMS or even an Internet connection, but for some reason you look at procurement tenders and shake your head.
Within less than 3 years these systems are abandoned. Every open source software starts with the right intentions, but the execution is down to 1 or 2 people who make mistakes from the onset, from choosing the wrong tech stack to a load of other things I will not delve into. Undoing some of these mistakes requires abandoning their entire project or building from scratch.
It’s amazing to see the amount of interest in this discussion. Thanks, Wayan, for re-publishing my post here and bring it to a wider audience.
Josh Mandell, responding on LinkedIn, linked to 2 other related articles that raise many of the same points I did. They both make for good reading on the subject.
1. The Revolution Will Not Be Open Source (https://blog.devresults.com/the-revolution-will-not-be-open-source/)
2. Hope for a Post ICT4D World (https://www.surveycto.com/blog/post-ict4d-world/)
I think there’s a tendency to frame this discussion as “money-minded for-profit people” vs “noble-minded non-profit people”. This is simply the wrong way to think about it.
As several people, including myself and the articles above have conceded, the open source community produces incredibly valuable software. There is no doubt about it. Most private companies, in fact, build their technology on top of a wide variety of open source libraries, servers, operating systems e.t.c.
Secondly, the majority of open source software is not created by charitable do-gooders committed to giving up everything to save the world. Most open source engineers are paid (handsome salaries) for their work. I have been in that position myself, so I know. Otherwise what do people imagine they eat? You can’t expect software developers to work for free anymore than you could doctors or janitors. Now, have some developers contributed code to their favorite projects for free? Of course. But just because one or two doctors volunteer their time at a hospital doesn’t mean we should expect free healthcare across the board.
So this discussion, isn’t about whether resources need to be committed to developing ICT4D solutions. That’s a given. It is about how to foster an environment where the best solutions rise to the top, and their producers are compensated in a fair and sustainable way. It is about acknowledging that the economics of digital products are no different from economics generally. There is nothing magical about how software is produced, maintained or supported. It takes effort, time and money. In the words of Christopher Robert:
“When a local project or organization can’t afford chairs for their office, do donors fund an industry to build chairs and leave them out on street corners so that project teams can just swing by and pick them up (gratis, but perhaps with the appropriate fee to a consultant who can direct them to the proper street corner and perhaps show them how to use the chair)? How about their transportation needs? Does the donor community build cars and leave them lying about with keys in the ignition? No, of course not: appropriate funding is provided for grantees to buy chairs, cars, fuel, and all the rest. Why not technology?”
Just this week, Wayan published a post about the sustanability challenges being faced by OpenLMIS (http://www.ictworks.org/openlmis-open-source-software/). Stories like this should make us pause and reflect on the economic incentives for solution developers and how innovation should be funded.
Private companies in the ICT4D space are not asking for handouts or grants. They are asking to be accorded a fair opportunity in a liberalized market. And that means judging all solutions by their utility, not by their licensing schemes.
As someone running a private company in the ICT4D space (where our solution is open-sourced), our licensing is part of our utility.
An open-source solution by nature gives the user the utility to serve as many people as my server can handle, a proprietary license will limit how many devices/users I can use software with according to how many licenses I purchase.
Open-source is generally the best insurance policy against vendor lock-in. When you buy a chair, you own it. You don’t buy proprietary software. You get a limited license to use it. Donors do not buy a license for a furniture that limits how many people can use it, or what rooms it can be in, and how long they can use it for. When you buy furniture, you can get any woodworker etc. you want to adapt it as you want.
No-one is saying that donors should leave cars etc. laying around on the street. However, if donors did spend their money to design a completely new kind of car, shouldn’t that design be freely usable by whoever wants to use it? Pragmatically, there is no case for donors to develop a new kind of car, and yes it makes more sense to buy or lease existing vehicles. But for unique software needs, sometimes there is the case to create new software.
There are successful open-source software companies and business models. The world’s most popular Learning Management System (Moodle) is open-source, and a central organization generates revenue by selling hosting, accrediting service providers, taking a percentage of partner training program fees, etc.
Red Hat sold enterprise support services for open-source software (and invested a large amount in open-source development). It was bought by IBM for $34 billion USD. It’s not easy (I know that first-hand). But it’s definitely not impossible.
I don’t think there’s anything about proprietary software that inherently limits the number of users. This is a business model question, not a code licensing one. All-you-can eat and volume-based pricing models, for example, don’t impose such limits. Companies like Basecamp offer a single price regardless of the number of users. At Hoji, we bill our customers based on the volume of data processed through our platform – again with no regard to the number of users or devices involved. On the other hand, Moodle, the very open source example you have cited, bills on a user-based model when offered as a hosted service.
What about vendor lock-in?
It is an important issue, no doubt, but I think it is a mistake to prescribe “simple” answers like (a) vendor lock-in is necessarily bad and (b) open source does not lock you in but proprietary does.
For example, two of the most popular EMRs in Kenya are KenyaEMR (based on OpenMRS) and IQCare. Both are open source and widely deployed across government health facilities. Let’s say you got fed up with one and decided to switch to the other. Their architecture and data models are so radically different that you would have a giant migration headache in your hands. If vendor lock-in is about high switching costs, it would be hard to argue that you are not locked-in under these circumstances.
Vendor lock-in matters because customers understand that their needs or circumstances (or those of their current technology provider) might evolve in ways that necessitate switching to a different supplier. Open source alone cannot insulate an organization against these challenges. If anything, the pressure to switch may well originate from choosing poorly to begin with.
Let’s say you needed to choose between two EMRs. One is a proprietary, full-featured plug-and-play Hospital Information System (HIS) and the other one is a nascent open source project designed around one chronic condition but hoping to grow into a fully-fledged HIS. Assuming the total cost of ownership is the same, I believe most rational customers would chose option one. Indeed, this is what most private sector players do. Objectively, choosing the tried-and-tested HIS would radically reduce the odds that the customer needs to switch to something else later, so that even if they are “locked-in”, it is not such a big deal. Someone who chooses option two, however, may get frustrated along the way, and need to explore other options, thereby spending more both directly and in terms of opportunity cost.
Again, all I am arguing for is a less dogmatic approach to making these decisions, a willingness to accept that technology decisions are complex, and all available solutions deserve a fair chance, without being dismissed out of hand on the basis of their code licensing schemes.
I rest my case.
No one has done a study to determine where the most $$$$ are spent. If am to use common sense, I will say 90% of the donor grants are spent on proprietary software.
Obviously that study would be as useful as dehydrated water. What donor agencies and other organizations should worry about is value. The Open source vs proprietary is a good topic at high school debates.
Too many digital projects fail, and u don’t need a corona virus expert to know if a project is going to fail. Most fail before they even start.
Digital Projects are complex with a seafull of amateurs. That’s where the cracks start to emerge. You look at the project and u wonder what in the world were they thinking.
Gitahi and Mike, you guys make very good and practical points particularly as people who have first hand extensive experience developing and deploying software. As we say in Kenya, “vitu kwa ground ni different”…loosely translated to mean “things on the ground are different”. Boardroom and armchair theories are great, but first hand on the ground experience provides invaluable insights and knowledge.
Some of the key investments to properly solve/enhance/augment health care using digital health solutions are clearly described in the principles for digital development. The principles are just that but we know all the important work that goes behind the scenes irrespective of open or proprietary nature of the software makes all the difference. This includes;
1. The (engineering and management) process of building high quality software that is clear what it is for and gets built to do that very well – is a function of knowledge, skills, experience, etc.
2. Deployment, support and maintenance
3. Underlying Sound business model (including operations, CRM, etc) to support continuous delivery of distinct value to customer. The elements and relative importance of that value are as also varied.
What I see as one key benefit that global digital health community has contributed is further “democratization” of Information and knowledge of this previously hitherto and historically heavily mystified space of digital health tech solutions where a few software companies dominated and sold sickeningly expensive software some of which was crappy (and some are still there) – basically blackmailed the market thag was limited in what investment decisions it would make based on the manipulatively controlled solution development industry that was a preserve of a “special” few . The notion that only a few people Posses these unique and special capabilities to design and develop good software that actually works sustainably has been dubunked and the accelerator for that has been to a large extent open source initiatives. And as expected with such happenings, with it has brought quacks.
Freedom to choose (whether a solution developer or customer) is about value and while value is relative, it’s worth is increased by basic democratic principles including of openness.
Great article, Gitahi, and while I don’t disagree with any of your main points, I agree most with your call to take a measured approach and thorough analysis to the problem at hand before choosing to build, buy — or extend. Many NGOs often have both extremely limited budgets for software and intense time pressure to deliver. I haven’t observed that those leading the programmatic work to deliver services have a strong view about COTS vs open source, but rather that those software developers trying to help are often tasked with trying to rub two nickels together to make a quarter of a solution to a problem that is larger still.
Also, many FOSS solutions in this space lack disciplined product management and requirements gathering, which frequently foregoes existing FOSS (and COTS) solutions and leads to gold plating and scope creep that when combined with the free-rider problem usually begets more unsustainable, fragmented forks and solutions.
So while the COTS vs FOSS argument will always be a perennial topic for debate, as it should be, we can’t ignore the not-technical aspects of the entire lifecycle to provisioning, implementing and supporting software — starting with a detailed analysis of the problem/need and rigorous market evaluation.
The limited budget argument is good, even though it falls flat. What is more expensive is deploying technology which serves no purpose. The majority of open source applications are bad, at least 98%.
The success of a digital solution does not hinge on whether OSS or proprietary software is used. It boils down to a few common sense mistakes. Hiring a wrong team without depth in skills, and identifying what problems need to be solved.
The KISS (Keep it simple stupid) is lost on most interns who are in charge of procurement. Many people rave about facebook and its vast array of features, little is understood how they came about. These features were added over years. The first version of facebook looked a second grade piece of bad art.
Looking at a number of software tenders, I can’t help but laugh at the level of naivety. The assumption that some kind of software exists that can wash all the problems away.
Friendster lost ground to facebook mainly due to using a poor tech stack. Cold fusion to be exact. Even in cases where a system is developed ‘well’ a lot of the user experience is mind boggling. Let’s take an example of a system where a user is supposed to indicate their date of birth, you will find the app expecting u to scroll backwards from the current date, month by month, then year by year. Such simple mistakes can be wished away, but that’s where the vast majority of problems start. Poor design, horrible user experience. Google plus and the Espn Phone are good examples. They didn’t fail due to a lack of budget, actually having a big budget can be an impediment in itself.
The software license is at the bottom of the barrel. In theory some will argue open source has more eye balls, but this argument holds no ground if the eye balls revolve around tunnel vision.
Non profits and any other organization are free to use open source and by the way these numbers in my estimate are below 10%. I wouldn’t care less what their choice is, however I am a strong advocate that government institutions should use open source especially in Africa. The funds wasted on Microsoft license re mind boggling yet Linux and Open Office could do the trick. Other organizations are free to experiment and fail, afterall they are fail festivals where they can showcase their success at failing. I wouldn’t lose one iota of sleep what they choose.
Thanks, Jake. I agree that “many NGOs often have both extremely limited budgets for software and intense time pressure to deliver”. But, I think this is merely a symptom and not the real problem.
Let’s take data collection for example, where I have quite a bit of experience. You’ll find projects that plan for large-scale surveys and budget down to the last meatball to be eaten at the offsite report writing meeting. There will be money allocated for airline tickets, ground transport, hotel accommodation, mobilization fees, report printing … everything but technology.
But why doesn’t anybody deign to budget for software? Because people expect it to be free. On the other hand, no one expects airline tickets (or meatballs) to be free.
Why do people expect software to be free? A number of reasons:
(1) The mere existence of the word “free” in FOSS promotes the misunderstanding that open source software is free of cost.
(2) People use “free” software daily, especially on mobile. Overtime, it gets lost on them that there is a cost associated with these applications, often paid through advertising revenue.
(3) The “raw materials” that go into producing good software are not obvious in the same way that, say, printing paper is. Programming, unfortunately, is largely indistinguishable from typing.
In my view, the solution lies in the ICT4D community helping stakeholders understand the economics of creating, adopting, extending, deploying, maintaining and supporting good quality technology solutions. This means, for example, banishing the idea that FOSS implies free of cost. It also means exposing some of the not-so-obvious costs associated with technology choices.
For instance, software that’s easy to use saves time and money. It also takes less time and effort to train and support users. Software that’s easy to deploy e.g. no complex server configuration, is likely cheaper and faster to roll out. Software that has strong security and disaster recovery mechanisms built into it minimizes the risk of compromised or lost data. Software that is well designed and applied to the right problem is likely to scale better and accommodate emergent needs than software that is poorly designed or applied to the wrong problem.
I think these are sorts the issues that should be taken into consideration when evaluating the suitability and total cost of ownership of any given technology solution. And, as I have argued throughout this discussion, the “open source good, proprietary bad” heuristic undermines healthy discussion on the matter.
Derick, do you expect turkeys to vote for thanksgiving. Everyone in these debates looks out for which side of their bread should be buttered, that’s where everything gets lost in translation.
It’s true certain non profits favor open source but these are far and in between, if am to make a guesstimate, it would be in the region of 5%. The actual figure could be much less. And by the way I think more non profits and government institutions should get an Open source bias, which is a non starter in the 1st place. The major issue isn’t proprietary / OSS which is a side show from ‘experts’. And you know most experts know very little about technology.
They are bad products from the proprietary and open source worlds, but some how the debate is reduced to non entities on definitions of OSS, which is ideal for a junior high school class curriculum. The high failure rate of digital projects is down to not having a qualified team to procure the right tools and technology. If you go to a restaurant and buy a pizza which turns out to be as tasty as chalk, next time you will avoid that establishment, with technology after selecting an inept company you are prolly stuck with it for at least 15 months. Then you will hire another team to clean up, but you dont have the skills to differentiate the chaff, and most of these pseudo ‘tech’ companies have stellar presentations to make up for the hollow tech. They can go wax lyrical about why you are making a mistake not to hire them.