Limn This

AKO et al Should Offer OpenID Services

It's been a while since I've consistently blogged here. At the risk of writing checks I can't cash, I'll state for the record that I'm going to try once again for consistency. It should be easy. If I can just manage to be half as talkative (and opinionated) here as I am in meatspace I'll be golden. That hasn't been the case for the last year, but I'm really going to try. Anyway, here goes...

A few weeks ago I was talking to Blake Hall about the difficulty of on-boarding military members for his new service TroopSwap. It's a cool idea and I wish it had been around back when I was in the Navy and was trying to unload that solid oak 300 lb entertainment center I was stupid enough to buy. It is sort of like a Craig's List / eBay hybrid but focused on those out of the way places where the military builds its posts and bases. You know, places too sparsely populated or interesting to find in Craig's list of supported cities.

Blake's goal is to help military members who are moving every six to eighteen months find someone to trade their gear, tv, or kitchen table with for barter or cash. So in addition to the focus on out of the way places, TroopSwap also wants to take advantage of the circle of trust inside the military and ensure the user that transactions are with other trustworthy military members. Sort of like a USAA for buying and selling your stuff. But to do this effectively he needs to make sure that members are actually in the military without making signing up so difficult that they just don't bother. Right now it's a pain.

Wouldn't it be cool if Army Knowledge Online / Defense Knowledge Online, Navy Marine Corps Internet, Air Force Portal and etc. took a page from the "government as a platform" playbook and offered an OpenID service? And I don't mean on the NIPRNet, I'm talking about out in the wild on the Internet. If they did, Blake could accept OpenID's from that short list of providers and make signing up simple and safe. I know this sounds stupid at first, but stay with me for a minute. It's not just to make Blake's business better.

Lt. General Sorenson, the Army CIO, has been pushing for two years to make innovation possible at the edge of the Army enterprise. Apps for Army, the Army Transformation Architecture, and similar initiatives coming out of CERDEC make it possible for soldiers in the field to write and deploy code without waiting for the core acquisition process to figure everything out. They enable emergent innovation in the field.

An AKO OpenID service is like an extension of that idea, but it goes even further. It would extend the Army's zone of innovation beyond the edge to outside the enterprise boundary, and it would encourage third party services to innovate on their behalf. Ultimately the benefits wouldn't be just for entrepreneurs like Blake, but would be for soldiers, sailors, marines and airmen by making it easier for outside organizations to offer them targeted services. It might be retail companies like Amazon or Best Buy, or even Domino's Pizza, using it to easily offer online discounts to service members. It might be companies like Facebook or MySpace offering specially designed areas catering only to military members. Or, it might be non-profits like the USO that already serve the military but want to serve them better online. Once you start thinking about it, it's hard to stop coming up with ideas.

Flipping the coin over, it's also good for the military because it gives them a way to see who their people are doing business with and pay attention to the nature of that business. They could easily require third parties to meet a set of "safe for troops" business standards before they would be offered OpenID from those providers.

This may be a little bit more of a stretch, but I can also think of more "tactical" use cases too. As the military is asked to do more disaster recovery and humanitarian aid they may find more need to give service members access to the systems and web applications of various NGO's. Those NGO's could easily set up their systems to accept OpenID's served from government networks.

I know this is a counter intuitive idea, at least at first. But the more I think about it the more I think the military and its members would benefit from extending internal identity services beyond the enterprise boundary through OpenID.

The Army, the Web, and the Case for Intentional Emergence

Lt. Gen. Sorenson gave a Higher Order Bit talk at the Web 2.0 Summit in San Francisco back in November. I didn't make it to the Summit this year but I'm glad I got to see the video. 

I'm glad General Sorenson is thinking about how the Army's systems and methods can be improved with Web 2.0 ideas and technologies but I wish the Army would really go after the really fundamental benefit of the Web, the fact that it is a platform that supports emergence. It's not just about the specific technologies, it's about the ecosystem of technology, economics, policy, and culture that supports rapid innovation on a generative platform. 

I think the Army can unleash a wave of innovation at the edge by replicating the web's generativity on the battlefield and a couple of California National Guard guys I met have proven it. They managed to get a single Linux box authorized for the SIPRNET in theater and quickly used it to build a collection of web applications called Combat Operations Information Network that scratched a bunch of itches for their unit.

As simple as it was (a single underpowered Linux machine on the network), once COIN was on the network it was a generative node and people lined up to get other problems solved and is now widely used across the theater.

I tell the rest of the story about my reaction to General Sorenson's talk and how the Army's Battle Command System can support innovations like COIN here at Radar. I'll just link to it rather than cross posting the rest of it.

Technorati Tags: Army, Defense, Enterprise2.0, web2.0

Open Technology Conference Wrap Up - Where the Geeks At?

Yesterday I sat on the panel that I referred to here. I thought I'd follow up with a brief post about one topic of our panel conversation.

To start the panel we were asked "what's bugging us?" This started an interesting conversation about some specific open source roadblocks in defense. In particular, Bdale Garbee made the point that open source projects rely heavily on personal reputation. Even when major corporations participate in open source community, it's the reputation of the individual that determines whether and how contributions make it into the project repository. People get commit rights, not companies. This can be problematic in the defense space.

I added that many key contributors to open source projects have self-selected to participate. The ability to self select is important to the ability of a project to find people with high levels of commitment and expertise. Look at the list of contributors on the Apache web server project for example. While there are certainly participants that represent major corporations, I would estimate from looking at the list that at least a third self selected. And that third is important as it is often the source of key (and difficult to find) skills. In fact, even many of the company sponsored contributors self selected and were later hired because of their participation.

Unfortunately, for a variety of reasons, within the DoD it can be much more difficult to self-select to participate. In defense work every hour is accounted for and must match a specific project plan line item. Community participation often requires a contributor to assist with things that don't have an exact corresponding work breakdown structure element from the program that is paying them. In defense work, if you don't have a charge code, you don't work. There's simply less wiggle room for participation that doesn't directly relate to the program that is funding you at that moment.

We also touched on a bunch of other issues that impact the ability to participate in or contribute to open source projects. Things like export controls, copyright, culture, etc.

These specific issues that impact defense contribution and participation have broad implications if defense is to be able to effectively leverage the work going on in open source communities. One of the things that makes open source community tick is the right to fork. Knowing that you can fork the source if the project direction deviates from your own direction is important to alleviating risk. The antidote to forking is community participation and the development of trust. The more you participate, and the more you develop trust, the more you or your organization can influence the direction of a project or at least make sure that your specific needs can be met. With all of the rules that currently make meaningful participation difficult, it is very difficult for defense contractors to participate in the upstream software value chain. The result is perpetual forking.

It will work like this. A defense contractor does a trade space analysis and decides that they can save a lot of money for the government by using a particular open source project, so they include it in their bid. They win and they build the system using the open source component, however, they realize that they have to modify it in a few critical ways to satisfy some specific requirements. They can't participate in the community so their changes never get offered back, and never make it into the trunk. A few years later, under a follow up maintenance and sustainment contract, they do an upgrade of the system and, because their changes never made it into the core project, they have to repeat the work again on the newest version of the open source project.

In the not too distant future there will probably be whole classes of software infrastructure that are effectively only available as open source. It simply won't be economic for a proprietary software firm to compete in areas that have been completely commoditized. Therefore, it's imperative that the Department figures out how to resolve the issues that are preventing their own people or their contractors from participating meaningfully in the communities that they will be forced to rely on.

That's probably enough on that. There was one other thing I wanted to touch on in this post. This was the fourth year of this conference and, maybe I'm just an impatient person, but I'm getting really bored of the same old remedial conversations with a bunch of suits (full disclosure, I was in a suit too). Or as John Scott put it to me during a break, "Where the geeks at??" Too much of the conversation is still about whether or not Linux qualifies as CoTS in the FARS and that sort of thing. Where are the breakout groups on open geo tools? Where's the presentation from the guys using XMPP as a cheap messaging stack in some major program? Where are the non-DoD geeks who are attending because they are participating in an open source community that was started in defense but is now being widely used to solve all kinds of other problems? Where are people trying to build an open service bus that will deal with intermittent service end points that you find on a battlefield? Where are the SOSCOE developers talking about how they used JXTA's service advertising mechanisms? Etc...

It's time to move from the basics into the advance course kinds of stuff; the stuff you talk about when you are actually doing it. It's time for DoD policy makers and decision makers in key programs to really start to push; push for expertise, program outcomes, and key policy initiatives that will alleviate the kinds of road blocks we discussed (again) in our panel. In short, it's time to stop talking about open source in defense and start using it at such a meaningful scale that next year the room won't be full of suits, but will be full of geeks and practitioners.

Open Source in Defense: Consuming it is Nice, but Building it is Better

I'll be participating in a panel discussion next week at the 4th Annual DoD Open Technology Conference in DC. The Panel is about open source software in defense and will be moderated by John Scott, an author of Sue Payton's Open Technology Development Roadmap (pdf). Dan Risacher, who recently discussed the DoD CIO's upcoming policy memo with GCN, will also be on the panel. We'll be talking about what makes open source valuable to the department - consuming it, contributing to it, and even building it outright. We'll also be talking about the policy, legal, and accidental process roadblocks that make it more difficult today than it should be.

Yesterday, while I was doing some preparation, I ran across this sources sought on Fed Biz Ops. It got me thinking about the down to Earth practical stuff that is necessary to make a difference in encouraging open source in defense. I am going to come back to the details of this sources sought in a moment.

The DoD has broken the seal when it comes to consuming open source, at least in packaged form. I'm not certain where I got this factoid, but I think the US Army is now Redhat's single biggest customer. But like I've said before, consuming open source is no big deal and really isn't occasion for a big celebration. Where the DoD stands to gain much more value is in producing open source software.

Every industry has at least some domain-specific software needs. The stuff that makes up their industry-specific "stack" and that isn't readily provided in the cross-industry products from the major software vendors. For example, the financial services industry depends on things like high speed messaging buses and high availability transaction monitors. Web firms use things like Perlbal, Hadoop, and of course Apache that help them build a massively horizontally scaled web presence. Telecom has specifications like H.323 and now SLEE and SIP and products built on them.

In the old days, if the industry was big enough, domain-specific software vendors would spring up to provide them with the infrastructure that they needed (e.g. Tibco's Rendezvous). If they were REALLY big, a large software vendor might even offer a domain-specific product, or at least a version of their product.

These days though there is an alternative, Open Source Quasi- Joint Ventures. Well, nobody really calls them that, but that's how I think of them. They are like accidental joint ventures that do resource sharing the way a traditional joint venture would, but they rely on open source licensing to make the risk of participation low. Plus, they avoid most of the legal and ownership wrangling that happens in a real joint venture.

A great example of this approach is the Advanced Message Queuing Protocol (AMQP) (and associated AMQ implementations such as OpenAMQ). It was initiated by JPMorgan but has grown to include many large banks as participants. The banks don't give up any competitive advantage by participating because messaging is about passing information to trading partners, but they save money by more efficiently providing for their own infrastructure.

Things like OpenID and Hadoop also fit into this mold. Companies like Yahoo and SixApart are taking active roles in funding and guiding the development of their industry-specific technology. Again, it's far enough down in their stack that they aren't giving up a competitive position; but they are saving money by sharing their development resources.

I don't mean to say that these aren't normal open source projects in every way. I'm simply making a distinction about how and why they are funded in terms of the specific needs of the industry that is funding them. By joining together to build components for an industry-specific stack and then intentionally commoditizing it within that industry, these projects seem to be filling in where JV's or domain-specific software companies might have focused before. This open source approach is better than a traditional JV though because new participants can join up at any time and they avoid many of the up front issues of starting a JV.

Back to the DoD. Defense has saved a great deal over the last decade recognizing that it can leverage COTS hardware and software. However, it still has many unique needs for its information technology stack - the DoD operates in a different operational environment and has many specialized requirements. So, while the DoD today is beginning to consume "package" commodity open source projects such as Linux, there is still a great opportunity to steal a page from JPMorgan's playbook and build defense-specific infrastructure as open source. The DoD builds defense-specific stack components all the time, but they rarely do it in a way that makes it easy for other programs to adopt them (or even know about them). An open source approach would better spread the funding and would also ensure that once the money is spent the pieces could be widely used and adopted.

This brings me back to the WebTAS sources sought.

FCS, SOSCOE, and the Big Bang

It bums me out to read statements like this one in this article about FCS/SOSCOE:

The software program "started prematurely. They didn't have a solid knowledge base," said Bill Graveline, a GAO official involved in the government's ongoing review. "They didn't really understand the requirements."

That isn't to say that I think FCS/SOSCOE is on track and being developed the best way, it's just that I think these kinds of statements perpetuate the idea that software of this magnitude should be written as a Big Bang after every requirement is fully understood. There are 3000 developers working nine years at a cost of $6B and the expected value curve is supposed to look like this:

Contrast this with something like Linux where value has tracked much more closely with effort:

Why the difference? Well, unlike an open source project like Linux that slowly moves its way up the food chain from departmental web servers to mission critical applications as it matures, the government acquisition system tends to assume that at 8 years 364 days SOSCOE is an entry in an earned value report. Then, suddenly as the calendar turns over 9 years it is hatched as a fully functioning completed system ready for operational deployment. In the meantime, as it hasn't been "delivered" it isn't available to be used anywhere.

I would love to see large scale software developments like this thought of in much more incremental / evolutionary terms. I'd also like to see a greater degree of transparency and openness so that incremental value could be provided along the way, even to completely unrelated programs. After all, many of the component parts of SOSCOE are lego blocks that could be readily used in other environments.

In fact, my first graph is probably completely wrong. Without the hardening that comes from incremental use it is much more likely that the budgeted 9 years / $6B grows dramatically (like it did for Vista) before the value bit can be flipped.

In an effort to create a market dynamic to encourage NetCentricity within the Department of Defense Command and Control community, the Defense Information Systems Agency announced today that the $2.5B Net Enabled Command and Control program has been reprogrammed as the Defense Information Mobility Encouragement (DIME) fund.

The DISA press release describes DIME as a new approach to achieving NetCentricity; one where market incentives similar to those found in a commercial market will replace the centralized-program-oriented approach taken to date. It is a simple concept, beginning in FY 08 DIME will pay $.10 to any C2-related Program of Record for each and every service oriented transaction that it suppports during the five year period of the original NECC increment one. The idea is to encourage NetCentricity while leaving the door wide open for innovation by creating an additional funding stream for those programs that achieve adoption for their services.

Despite the bland bureaucratic language of the release, this is an amazing announcement. It is an unprecedented admission of the value of market forces in guiding co-evolutionary systems development in an enterprise too large to effectively centrally plan. While DIME doesn't eliminate policy and requirements such as Net Ready Key Performance Parameters, it fundamentally changes the drivers to achieve compliance. The faster a program operationalizes services, the faster it can start servicing transactions and get paid. Though the NRKPP's will still be verified, the spirit of the NRKPP's will be primarily tested by transaction adoption and volume.

DISA doesn't say it, but I suspect that they are also hoping that this approach, by being a funds multiplier to programs that are serving a broad customer base, will reward well-managed programs at the expense of those that don't grow their base.

I don't think it will take long for a more granular payment scheme to evolve as this approach will clearly benefit high frequency services such as situational awareness more than lower-frequency capabilities such as planning. I'm sure DISA will have to be nimble to evolve the program as high transaction rate designs are floated to game the fund, but despite these nits, I applaud DISA for taking a step that recognizes a dime of incentive can be more effective at achieving their goals than pounds of policy.

Implied in the new fund is the sheer scale of DISA's expectations; $2.5B will pay for 25 billion transactions.

:)

Update (11/6/07): I guess the smiley face wasn't enough so it's time to come right out and say that this post is a farce. There is no "DIME" program but I can't help but think that a little bit of Adam Smith Invisible Hand would go a long way toward reducing the need for complex centralized planning as we move toward NetCentric systems. The question is, what simple incentives might make viable substitutes for the missing market economy that serves as that hand throughout the rest of our economy? Note the comment on centralized planning here.

DISA Announces $2.5B Fund for Netcentric Transactions

In an effort to create a market dynamic to encourage NetCentricity within the Department of Defense Command and Control community, the Defense Information Systems Agency announced today that the $2.5B Net Enabled Command and Control program has been reprogrammed as the Defense Information Mobility Encouragement (DIME) fund.

The DISA press release describes DIME as a new approach to achieving NetCentricity; one where market incentives similar to those found in a commercial market will replace the centralized-program-oriented approach taken to date. It is a simple concept, beginning in FY 08 DIME will pay $.10 to any C2-related Program of Record for each and every service oriented transaction that it suppports during the five year period of the original NECC increment one. The idea is to encourage NetCentricity while leaving the door wide open for innovation by creating an additional funding stream for those programs that achieve adoption for their services.

Despite the bland bureaucratic language of the release, this is an amazing announcement. It is an unprecedented admission of the value of market forces in guiding co-evolutionary systems development in an enterprise too large to effectively centrally plan. While DIME doesn't eliminate policy and requirements such as Net Ready Key Performance Parameters, it fundamentally changes the drivers to achieve compliance. The faster a program operationalizes services, the faster it can start servicing transactions and get paid. Though the NRKPP's will still be verified, the spirit of the NRKPP's will be primarily tested by transaction adoption and volume.

DISA doesn't say it, but I suspect that they are also hoping that this approach, by being a funds multiplier to programs that are serving a broad customer base, will reward well-managed programs at the expense of those that don't grow their base.

I don't think it will take long for a more granular payment scheme to evolve as this approach will clearly benefit high frequency services such as situational awareness more than lower-frequency capabilities such as planning. I'm sure DISA will have to be nimble to evolve the program as high transaction rate designs are floated to game the fund, but despite these nits, I applaud DISA for taking a step that recognizes a dime of incentive can be more effective at achieving their goals than pounds of policy.

Implied in the new fund is the sheer scale of DISA's expectations; $2.5B will pay for 25 billion transactions.

:)

Update (11/6/07): I guess the smiley face wasn't enough so it's time to come right out and say that this post is a farce. There is no "DIME" program but I can't help but think that a little bit of Adam Smith Invisible Hand would go a long way toward reducing the need for complex centralized planning as we move toward NetCentric systems. The question is, what simple incentives might make viable substitutes for the missing market economy that serves as that hand throughout the rest of our economy? Note the comment on centralized planning here.