Why Is Government So Slow To Collaborate On Software?

Open source software is free and is often developed by collaborations
of volunteer programmers around the world, along with staff at big
companies who find it in their common interest that this software be
maintained.

Open source software has been an enormous success.
Most of the web services on the Internet are delivered by Apache
software on the Linux platform – both open source projects. Indeed,
there are over 25 million open source projects listed on the open source
directory of GitHub.

Despite the billions of dollars spent by the
public sector for software each year, the public sector’s share of
those open source projects has been much smaller than its share of the
overall economy. This small commitment to open source is not what you’d
expect considering the situation of the public sector compared to the
private sector.

First, unlike private companies, governments
cannot really consider their software to be proprietary and a key
strategic advantage in competing with others. Taxpayers have already
paid for the software and, like much else in government, it is supposed
to be open and available (unless security or privacy is at stake).

Second,
there are many programmers who would help to build and maintain public
sector software out of civic spirit and a recognition that they too
benefit as citizens.

Code For America
has been an outstanding example, but not the only example, of the
willingness of software developers to help even local governments. Ben Balter has been a champion for public sector open source as well. The GovCode
website proclaims:

“Code for your country! We believe in a government
of the hackers, for the hackers and by the hackers”.

[That’s hackers in
the good sense of creative, expert programmers.]

Third, open
source software is often much less expensive than commercial,
proprietary products and just as often better quality. This is
especially true in the public sector where many of the companies
providing products for various special purposes – like jail management or health –
aren’t very big themselves and thus their products are often constrained
or sometimes buggy.

It’s hard to come by the total
number of software developers in governments or total expenditures for
software development – or even packaged software where open source might
substitute. But considering how many government agencies there are, it
is likely that government at all levels has a lot more developers in total than these
companies.

Of course, in fits and starts, open source has come to government, with 2012-2013 a recent peak of interest.

The US Defense Department issued guidelines
for use of open source in that agency. And the US Federal government
has, officially, been an advocate for open source software – at least
within itself. It is not easy to determine what percentage of software
the Feds have actually shifted from proprietary to open source.

image

Also, a few years ago, the Open Source Institute
dedicated itself to

“promote the development and implementation of open
source software solutions within U.S. Federal, state, and local
government agencies.”

Alas, currently it seems to be in a quiescent
state.

More recently, Github has created a platform for public sector sharing. But much of what is being shared is data or best practices, not software.

It’s
worth noting that, despite the efforts of the former DOD CIO and groups
within the General Services Administration, like 18F, too little of that movement
has been the result of leadership from within the government. Most has
come from outsiders offering to help.

Most significant is this
nuance: even when there is interest, government policies on open source
are focused on using open source software developed elsewhere, like
Linux, and not necessarily contributing to that software or creating new
open source software.

A key missing element in the failure to
make open source development the standard approach in the public sector is lack of
collaboration among governments. This is hard to understand in an era
when public agencies are strapped for cash. Each public agency may have
only a small software budget. However, pooling their financial and human
resources will achieve a scale that could allow for the creation of
good, feature-rich software for all of them.

This collaboration
need not stop at national borders. For example, the requirements for
software to manage the vaccination of a population are very much
consistent in the public health agencies of many countries. Moreover,
several trends should make collaboration easier – the shift to cloud
computing, new forms of communications that can ease discussions among
developers and the decreasing cost of building software compared to
years past.

It is now possible for government technologists, with
support from citizens, to truly scale up their open source software
development efforts.

So what are public officials, especially
public sector CIOs, waiting for?

If you have the answer or, better yet,
suggestions on how to make public sector open source more widely
adopted, please let us all know.

© 2015 Norman Jacknis, All Rights Reserved

[http://njacknis.tumblr.com/post/133033805117/why-is-government-so-slow-to-collaborate-on]

Isn’t There A Better Way To Build Government Software?

The awful performance of healthcare.gov has been a staple of the news as well as satire.  This cartoon in the New Yorker this week sums of the frustration of users – http://www.newyorker.com/humor/issuecartoons/2013/11/04/cartoons_20131028#slide=4

I normally don’t like to comment on hot news stories, but this one offers just too much of a teachable moment, especially for public officials who are not technologists, yet who will suffer public criticism when things go bad.

It’s worth noting that this is not the only case of Federal IT system problems.  Before healthcare.gov, the great cost and the long delays of the FBI case management system were in the news.  And, not to be outdone, New York City had a major scandal with its timekeeping system, both for the huge cost (close to $750 million) and the fact that there was a significant amount of that money diverted into the personal pockets of the project staff.

Indeed, costly and disastrous software projects are not just found in the public sector.  It only seems so because the public sector problems are more visible thanks to taxpayer funding, whereas the private sector can keep its mistakes better hidden.

In part, this review of bad projects reminds me of an old line in IT project management.  “Of the three goals of any the project – being within budget, on time, and of good quality – you’re usually only going to get two, but not all three.”  But, for the Affordable Care Act, is none of the three some kind of trifecta?

Part of the problem is that these projects cost way too much money.  That’s often because of rules intended to ensure everything is above board and serves the taxpayers’ interest, but which have the reverse effect.  And so ultimately, the purpose of the procurement rules is, as a well-intentioned government attorney once told me, to follow the rules – not necessarily to get maximum value for the taxpayers.  The big companies that dominate Federal technology projects have learned to master these rules and not necessarily do the best job.  Their reputations are also victims of this focus on process, rather than outcomes.

Another reason for the bloating of these projects is simple ego.  Some top executives have the belief that big important projects should have big budgets. 

Unfortunately, this attitude fails to distinguish the cost of writing the software from deploying it.  The cost of software development does not increase much if the number of users is 100 or 100,000. 

Obviously, the cost of deploying that software will increase in a linear fashion the more people who use it because the deployment may require more servers, more complex database arrangements, etc.

But spending hundreds of millions just to develop the software is usually unjustified.

So what can be done by executives who have to deliver new systems to the public, but feel they are enveloped in a fog of technical jargon so don’t question things until it’s too late.

Consider these alternative ways of handling software projects, none of which is really new, but seem to be not well known to non-technologists in both government and elsewhere:

  • Adopt the agile approach – this means having frequent deliverables and thus taking advantage of learning by users and developers.  It stands in contrast to the traditional practice of big requirements documents and all at once delivery of mammoth amounts of code.
  • Frequent testing, which is also a part of the agile approach.  It’s so important that some people build the test before the software.  After all, proof of the pudding is in the eating and it’s useful to know you’re off course earlier rather than later.
  • Parameterize.  This is something you don’t hear too much about, but it’s something I’ll mention here because some of the healthcare.gov vendors blamed their problems on changes in Federal decision making about whether users need to register first.  I would always tell my development staff this simple rule – if the debate about whether some requirement should be X or Y will take longer to resolve than it takes to program it both ways, then program it both ways by creating a parameter that will switch the system one way or the other.  Don’t let these debates hold up progress of software development.  (By the way, if the debate is that hot, there is good reason to expect the decision to change in the future, which will cost more money in future programming.  So parameterize and let the decision makers argue and change their minds as much as they want.)
  • Gradual scaling – don’t roll out a big new piece of software to the whole world at once.  (Do we really need to say this?)  If the scale of deployment is expected to be a possible problem, why not minimize the problem by taking it in several steps and, again, learning what needs to be improved.  Even experienced Broadway veterans try out the show on the road first.
  • Simplify deployments by using a scalable infrastructure.  There’s much discussion about “the cloud”, which is really just a good marketing term for the vast scale of computing resources available over the Internet.  Use it instead of trying to reinvent this vast scale, which is impossible for any organization, no matter big.  Many Internet businesses you’ve dealt with use these resources to handle peak demand or initial rollouts. 

I could go on, but these guidelines are normally enough to keep your next big systems project out of the headlines.

© 2013 Norman Jacknis

[http://njacknis.tumblr.com/post/65612237318/isnt-there-a-better-way-to-build-government-software]