Categories
society

Healthcare.gov’s Identity Problem

Identity management poses the most important and most striking problem for the new healthcare exchange site. Identity management remains one of the great, unsolved issues of our times and uniquely displays the anti-capitalist postures of some of the biggest technology businesses that exist.

That something as basic to any and every service as identity remains a closely guarded commodity shows that many major companies do not wish to compete on an even playing field. They would rather draw straws amongst themselves for the userbase pie, based on lock-in and turf wars, than to actually free their own markets. But while that general malignance runs rampant throughout virtually every industry, why in gods’ names should it infect government projects?

Indeed, inevitably the government will create a single sign-on or other universal identity mechanism for its Internet services. But in the meantime we all suffer. Everyone includes the government, with all of the bad press the new website received post-shutdown. Finger-pointing from the contractors, calls for resignations, and general what-the-fuckery from most of the attempted users of the site.

But a rough guess would get you the answer that at least half of the problems with the site center on identity when you include:

  • The initial sign-up process (username, password, e-mail verification)
  • The identity verification process (document submission, phone verification integration)
  • Family member and employee identification process

The site, like any government services site, relies on identity for so much of what it does. Handing off to other databases for things like subsidy requirement verification and other eligibility requirements.

A whole swath of inefficiency in government, much less in this one site, vanishes if the government merely gets its identity house in order.

But instead the government pays a high premium to build a monstrosity. Of course, that same argument bears against the Affordable Care Act itself with equal keenness (that a simpler system like single-payer would have saved far more money and woe both in the short term and long term).

What else could have eased the creation of the site? Some say that management of such a large-scale project requires a so-called quarterback. Others say you want a catcher. Some say you really need a good goalie, or a head chef, or even a Benevolent Dictator for Life (BDFL).

Nah. New projects suffer the most pain from the code they use for the first time. Like a new idea, fresh in your mind, or a fresh stone broken off a larger stone. Still sharp, cuts your hand, not yet smoothed by time and trial. Full of mealy worms wriggling waiting to grow into full-fledged bugs.

A QB will screw up a new play the first time through just like the rest of us. The most-needed piece of kit in software? Reuse. Use something that already gets used a ton, that does not have bugs because it gets used all the time.

The site broke because too much of the code and the way the code got used had not been proven. The databases had not been proven for their loads.

Testing a new project does help you sand the code smooth, but building from smooth code to begin with sounds smarter.

Categories
linux

Canonical and GNOME

Removing the minimize button?  Not giving a preference to turn off the display and not suspend when you close your laptop?  Moving the window controls to the other side of the window? Making the tabs square instead of round? Not allowing the editbox to be manually resized? Hiding the RSS icon? Moving the link preview to the URL bar? Removing the status bar?

And those are just the ones I can recall at the moment.

The computer is so central to peoples’ activities, that there is a certain fear that someone will break it for them.  That’s one of the major motivations behind Free Software in the first place: if I can build it myself, then you can’t force me to use the broken one.  If I can’t, then MicrosoftAppleSonyPaypalMastercard can up and decide to force their will upon me, and my recourse is simply to stop using them.  No stabbing big corporations with a fork.

Canonical Limited (the main driver for Ubuntu Linux) and the GNOME project couldn’t work together so they are each moving forward with their own, reinvented desktop interfaces. GNOME is going for gnome-shell and Canonical/Ubuntu will get Unity.

I don’t think this is a bad thing, excepting the bickering.  The larger community of desktop Linux users will get to see two different approaches in the wild for at least a year, which will inform the next iteration of the Linux desktop landscape.  There’s also an open-ended possibility for reunion later.

The dispute is territorial, which is not uncommon in open source.  The uncommon part of this is simply that it’s between two big players rather than between one big player and the users.  Though, the latter has occurred for both reinventions as well (see a few of the questions posed in the first paragraph).

Project governance is hard.  Cooperation is hard.  Finding the best way is hard.

If it weren’t for the bickering, nothing would be wrong.  There’s too much distrust and fear, because that’s what we’ve been taught by the proprietary realm.  When we used proprietary software, we could be stuck with a bug indefinitely.  Or things could change with no warning.

So we’re edgy.  But when the source is open, we shouldn’t be.  And if we weren’t, it would make project governance easier, it would make progress easier.  We should be willing to give the code an honest run.

At the end of the day any shift in any system will require a new equilibrium to be reached.  In open source that means some users will switch, forks might be created, etc.  But it also means that most users will find a slightly better workflow, will be a little (or a lot) happier and more productive.

I just wish that the developers weren’t so quick to assign blame, because they’re both building the foundation for the future, and they should be proud of their efforts even if they fail.