Being a hardcore developer who cares deeply about software, and having worked for local government for the past eight years, I have pondered this question often. On the one hand, a running philosophical theme is that programming is the new literacy, and because software permeates every aspect of our lives, programming amounts to expressing knowledge, just like writing does.
On the other hand, programming still requires a fair amount of technical expertise and engineering skills, and is therefore difficult and costly to cultivate alongside of the core competencies of an organization. For smaller governments, being a software-competent organization is not on the table as a long-term strategy. Even worse, software is considered a burden, a necessary evil, not only by computer-averse personnel, but by the IT department itself. The price paid for that attitude is much higher than one would suspect.
Supporting vs. Vital systems
This dilemma of in-house software versus outsourcing is faced by any type of organization, and the analysis usually distinguishes between "infrastructure software" and "business software," with the latter encapsulating business knowledge. An essay by Philip Armour in "Communications of the ACM" offers quality insights on the tradeoffs. Instead of the usual distinction of infrastructure vs. business, he talks about supporting vs. vital systems. A supporting system assists the business, but is not constitutive of the business itself. A vital system is the operationalized knowledge of what the organization does, that which justifies its existence.
Armour argues that companies are well-advised to avoid building in-house supportive systems, but also to avoid outsourcing vital systems. The latter is anti-orthodoxy—we’re supposed to outsource as a cost-cutting measure regardless of the system’s nature, right? That's the traditional view of software-as-a-cost: an asset you utilize, just like you rent physical space to operate. The problem with that view is that software has become the best, most accurate (and sometimes only) expression of business knowledge that an organization possesses.The key point here entails a radical shift in attitude toward in-house development: rather than doing it as a last recourse, in-house development should be the first option to consider.
Unintended consequences of outsourcing for government
Outsourcing software means outsourcing knowledge. This may not be obvious, because the people doing the human portion of the service provided are still employed by the agency, yet that's only a superficial assurance. When no true software specialists are available in government IT procurement, gullible career bureaucrats will go with the most charming vendor. Too many hugely consequential technical decisions are made by administrators with superficial knowledge. Even if one refrains from the cynical position that government employees operate under loose financial restrictions, how could one expect them to accurately assess the potential or monetary value of a piece of software?
When a big company comes to a real software professional with an estimate of $200,000 for what is otherwise conservatively estimated as two weeks of work, they will get called on it. When they do that to a glorified Excel clerk promoted to decision-maker as a reward for their dedication, critical assessment cannot be expected. Because all technical expertise and a substantial portion of the business knowledge is essentially deferred to the outsourcing entity, they act as the ultimate authority on the subject matter. This is not about demonizing the private, profit-oriented enterprises. There is nothing inherently ill-intentioned in vendors' behavior. However, the dynamics in this public vs. private relationship are skewed.
Government as its own open source community
Is the alternative that every government agency bear the cost and effort of writing its own software? Clearly this doesn't make much sense either. As often happens when an economic arrangement becomes impaired over time, cutting out the middleman solves the problem—the middleman here being for-profit enterprises that manage the production and costs of vital software systems.
In many open source initiatives, government is not a passive consumer, but rather a contributor. These include the White House’s U.S. Digital Service 18F taskforce, launched in response to the healthcare.gov debacle. For the systems falling into the supporting category, this is a great trend. On the other hand, there aren't any major efforts to tackle “vital” systems following the open source model because of the wrong perception that a government is "not in the business of software."
How about agencies employing qualified programmers well-versed in modern technologies to write the code to drive government business in an open manner, sharing expertise and effort? That is true cost-cutting, and the best possible strategic long-term investment—an open source government-to-government community, with its own set of policies and its own mode of project governance. Besides, having a good team of programmers on board is liberating and enabling. Bug fixes and upgrades are done quickly, and because knowledge remains within the organization, project continuity is ensured, which is critical for long-term cost control.
Jump-starting such a cultural change takes a fair amount of initiative and idealism, but it is worth considering. At Miami-Dade County, we organized a small conference (the 2010 ShareGov Symposium) years ago, consisting of local agencies. The idea was simple: We've written some in-house code, it works well, let's give it to others, and let's collaborate on improvements and maintenance so everybody benefits. Admittedly, creating a thriving open source project from a piece of internal code takes time, but it's worth it. The effort also can be a great motivator for employees when they see their work serving people outside their agency.
A notable outcome of the efforts at Miami-Dade is one of the biggest and most successful in-house projects, the CRM system driving the 311 Answer center. The system is live and operational, and it is on GitHub waiting for attention. Government may not have been good at software development and innovation in the past, but open source is changing the equation.
4 Comments