One of the interesting mysteries of the open source ecosystem, for me, has been the relative paucity of open source “vertical applications“. A “vertical application” is a system tailored to a fairly particular use case, usually requiring multiple software components tied together: an example might be a dental records management system, or a library management system.
Open source has thrived in the IT infrastructure space, churning out general purpose software like databases and operating systems and programming tools while rarely meeting very specific user needs.
The lack of vertical applications is even stranger when you note that, in terms of unit costs, vertical applications are often carry some of the highest price tags in the software world! A dentist might spend hundreds of dollars on Microsoft Office, a rigorously engineered highly polished piece of desktop software, but thousands of dollars on a fairly slipshod dental office management system.
Given all the money floating around vertical applications, open source efficiencies could make the market a lot more competitive. We know it! All too frequently, a group of programmers sits in the pub, sipping beer, calculating that “if just 25 dentists spent their money on an open source application, then every dentist could use it for free”.
But somehow that never happens.
First, building a vertical application requires domain knowledge. The reason there are so many good open source programming tools is that programmers already have the domain knowledge necessary to build good programming tools. Open source dental tools require a dentist (or several) to invest a fair amount of time guiding the development of the tools. Those that have such entrepreneurial and technological bents generally set up side businesses selling software to other dentists.
The vertical application problem is even more keen for governments, whose vertical applications are traditionally built or bought at costs in the seven-figures-and-up range. Ask a government why they don’t spend a little extra money to make their system modular or reusable in other jurisdictions, and they will (rightly) point out that they are not a software company. Their job is providing a public service (like running the jail, or driving the busses) not providing a meta-service of software development. Software is the means, not the ends.
To break out of the logjam, an outside entity needs to fill the role that is usually held by the software company:
- inform the customers of what can be done;
- aggregate development funds to make a large product from many smaller contributions;
- communicate and understand the technical issues of software development;
- manage the process of finding the “least common denominator” of necessary and collectively useful features or standards.
In addition, this entity should have organizational goals that are aligned with the project participants: public service; improved access; and better community value.
This entity looks a lot like our parent organization, OpenPlans.
Over the past year OpenPlans has increasingly taken on this role in important vertical application developments. The Open311 project and the Open Trip Planner are both niche vertical applications where having a non-profit entity work to coordinate efforts, provide communication, and aggregate development funds is a big help.
And (lest I hide our light under a bushel) OpenGeo is doing similar work with the GeoNode project by providing the technical core in a collaboration that includes the World Bank and other international development and emergency preparedness organizations.
Everyone knows what needs to be done in order to build these new open source vertical systems. The difficulty is taking the first step and saying “let’s work together, let’s get this done together.” I think there is a place for the “IT nonprofit” organizational model to help make some of these dreams a reality.