Wednesday, July 7, 2010

Government Software Pedigree (a.k.a. Why We Need Forge.gov)

[Note: edited 9/8/10 to clear up misconceptions about my involvement in Forge.gov]

I'd like to talk today about why a system similar to Forge.mil is a good idea for Federal government civilian agencies. I'll preface this with full disclosure: I work for CollabNet, the main infrastructure provider for Forge.mil. The CollabNet TeamForge product is the 'glue' underlying Forge.mil, but it allows for additional services to be 'plugged in' in the future. My role in Forge.mil is that of a community management consultant (and part-time day-to-day community manager). Despite the fact that the GSA (General Services Administration) is looking to the DoD (specifically DISA) to help them replicate the success of Forge.mil, the main point here is not to sell TeamForge, but, instead, to make customers and communities successful from a cultural and process standpoint.

Therefore, I'm posting this here for neutrality rather than at the 'OnCollabnet' blog. What follows is my opinion (and mine only - I'm not officially involved with Forge.gov, though I'd be happy to consult if asked) of why a 'Forge.gov' would be a valuable resource for the US government and its citizens, based on my experiences building Forge.mil, as well as similar 'internal community source' systems for previous employers such as Sun Microsystems and Motorola. The genesis of this post was a very logical and probing question asked by Ryan Brady on Twitter:

'What can a Forge.mil clone offer that you can't already get through popular and proven svcs?'

Ryan also asked a follow up question regarding why we should consider spending the money for this rather than use existing external services (by which, I presume he means one of: github, sourceforge.net, or code.google.com).

Though I tried to answer Ryan within the confines of Twitter's 140 characters, I thought it was important to lay out the 4 areas I think are important to consider when determining what solution to use for a civilian cross-government agency code collaboration initiative.

Pedigree of Contributors



Initially, a site like Forge.gov will probably be for internal government agency use only. That's not to say that private citizen involvement won't become a critical factor, but the pedigree of people participating in software development for government systems is going to be HUGE. Even if code reviews and a more 'Open Source' development model were followed, being able to positively identify and vet individuals contributing to common code utilized by multiple government agencies is critical to protecting our country's infrastructure. That being said, as a firm believer in Open Source, and having a knowledge of how it has helped innovation, I don't want this to become an excuse not to have citizen participation, but given the relatively weak identity mechanisms in use at github, sourceforge.net, and code.google.com, I can't imagine using those systems to develop or host mission-critical government code.

Whether we in the Open Source world agree or not, 'sharing' and 'Open Collaboration' are not things that come easily to the government mindset, and having a 'Forge.gov' type solution solves some of the perception problems as well when trying to get agencies to cooperate and collaborate. Unlike external sites, participants feel there is some 'safety' in participating in a system sanctioned by and using a .gov domain.

The public sites do serve a valuable purpose, though, for open source components that may be used within government systems. I believe that government needs to continue to work with components in the Open Source world where necessary and contribute to communities on the external side as well.

Finding Government-specific Code for Reuse



On public development sites, it is sometimes difficult to build up communities of interest around specific topics, or to find something specific you would like to reuse or work on. Even if you do find it, there are usually multiple competing projects that are difficult to characterize as to their usability. Having a centralized 'Forge.gov' entity would allow for community building & reduce duplication of effort by a simple project qualification process (something which has let us successfully connect multiple duplicate project efforts in Forge.mil). Since the public services mentioned earlier are really trying for the opposite effect (multiple competing efforts), it would be nearly impossible to implement something there that allows for ease of use when looking for code with GPR (government purpose rights) or similar restrictions.

Government Controlling Its Own Destiny



As much as some people may consider this next point 'Big Brotherish,' I think it is critical for software infrastructure used for mission-critical government systems to be within the control of someone other than a corporate entity. No offense to github, Google or Sourceforge.net, but what would happen to not only code and data, but to the accumulated knowledge collected in these public sites if they decide to move to another business opportunity, or go out of business altogether? I know that Google has done a good job of making customer data in its systems portable, but in the extremely unlikely occurrence of Google going out of business, migrating all of that data would be cost prohibitive to the US taxpayer. Having a centralized government infrastructure whose costs could be spread out over the agencies involved is a small price to pay for controlling the destiny of code and knowledge critical to our country's infrastructure.

A Platform for All Stakeholders



Lastly, the public services for code collaboration mentioned earlier all have a few things in common, not the least of which is a focus mostly on enabling collaboration among developers. As a former developer myself, I'm not necessarily against that. However, as someone whose job is now to sit 'in the middle' of developers, testers, project managers, and senior leaders/decision makers while getting them all to collaborate and cooperate, I realize the value of having a platform 'in house' that can be tweaked and modified to allow for integration of other capabilities for these additional stakeholders. Among these necessary capabilities are:


  • Enablement of CI (continuous integration) tools

  • Requirements management/traceability

  • Provisioning of cloud services for development/testing/production
  • Integrated knowledge management



Services like github, Sourceforge.net, and code.google.com have advanced the state of the art in software development and have helped push innovation forward in the technology space. However, seeing what can happen if you take the best of those environments and utilize them internally where it makes sense, I'm comfortable with saying I believe we need a civilian equivalent of Forge.mil - if for no other reason than it takes away one more excuse from government agencies that don't feel 'comfortable' sharing critical code or other technologies 'in the open.'

I realize that putting up a barrier to entry in the form of positive identification of US citizenship and a vetting process will irk some who believe that everything should be free and open. However, I'd urge those folks to think seriously about the balance between security, reliability and transparency when talking about federal government systems that control everything from the IRS, to Veterans Affairs, to Health and Human Services. A centralized Forge.gov that utilizes a strong identification/authorization model gives us the best part of community development while allowing us to protect a critical piece of our national infrastructure.

Monday, May 10, 2010

Community Is...

[This was originally posted on my work blog 'OnCollabNet']

I just returned from a two week conference trip in support of Forge.mil - the first week in Utah was uneventful, but the second week for the DISA partner conference in Nashville, TN at the historic Gaylord Opryland Hotel... well, let's just say it was something I don't think any of us involved will ever forget. For those that may not have been following the news, Nashville got 18 inches of rain in just two days (an all-time record) and those of us in town for the conference were evacuated from the hotel to a local high school due to severe flooding.

Nashville-Flood.jpgMobile Photo May 7, 2010 7 35 12 PM.jpg


Though I was one of the folks living through this, I'd like to highlight some of the things I saw and experienced that, to me, showcase the true meaning and spirit of community. We deal in my world with community in a somewhat abstract sense, because we are talking about online interactions. However, I'm here to tell you, I saw some amazing, simple, and just plain selfless acts from folks living through the Tennessee flood situation that epitomize the best aspects of community.

For me, the following things I witnessed last week complete the sentence 'Community is...':


  • A pre-teen choral group standing at the front of a ballroom at the Gaylord Opryland to entertain 1500 people waiting to hear where we would be staged next during a flood watch


  • Gaylord Hotel employees rushing to bring food, snacks, and even board games to the assembled crowd of people in the aforementioned ballroom


  • Forge.mil's own SPAWAR team members introducing themselves to complete strangers and sitting down to a game of charades while waiting out the flood


  • Forge.mil community manager Aaron Lippold and his friend finding a blanket for, and giving Aaron's coat to a mother at the evacuation shelter so that her very young son would have a comfortable place to sleep


  • Tennesseans showing up unannounced at our shelter with peanut butter & bread for 500 people, apologizing for not having enough, going back to the store for more, and also bringing pizzas, pillows and blankets later, despite their own homes being in danger


  • People living near our evacuation shelter offering complete strangers with small children living rooms/spare bedrooms, etc. in order to not have them sleep on the cold floor of a high school cafeteria


  • Forge.mil team members securing suitcases and other equipment from our operations team's rooms after they were forced to fly out early and leave their gear


  • Employees at the DoubleTree hotel in downtown Nashville finding rooms for some of us from the Forge.mil team, and being incredibly supportive & understanding whenever we needed anything


  • Gaylord hotel staff (security and bellmen, some of whom will be laid off for up to 6 months while the hotel cleans up and rebuilds) carrying suitcases all the way out to cars when we were able to finally retrieve our belongings


  • A cab driver who only charged us for part of our trip from the shelter to the DoubleTree hotel downtown (after the hotel we were going to go to was closed)



Now, some might argue that some of these individuals were 'just doing their jobs,' but I'd posit that what we were seeing was some of the finest examples of what it truly means to be a community. These people all put the well being of others above their own needs.

So, what does this all have to do with technical or development communities? I'd say everything - though you probably won't ever have to give your technical community members food and shelter in a storm, you can and should 'do the right thing' when one of them needs guidance, assistance, or someone to pick up the slack in a difficult time. If you are a community manager/shepherd/guide, your job should be not only to encourage this kind of behavior, but also to lead by example in this regard. Keep your hand on the pulse of the community - is there someone who is dealing with a difficult technical task/interpersonal conflict with another team member, or other thorny situation? If so, offer up whatever help you can give, even if that is just an ear to listen to them vent.

The issues that we deal with in technical communities are rarely, if ever, life and death, but I think we can all learn something from the disaster in Tennessee, not the least of which is that having the 'volunteer spirit,' like the people of that fine state, helps us in all aspects of our lives - both personal and professional.

Monday, February 8, 2010

The Power of the Open Source Periphery


Like a lot of people in the tech world, I try to read a variety of publications (both online and physical versions) to keep up with what is going on in the dizzying world of technology. Recently, I read a great article in a recent issue of Wired entitled Accept Defeat: The Neuroscience of Screwing Up. This article explains in some detail, with examples, the problem of 'failure blindness' in scientific research.

This phenomenon causes scientists and researchers to ignore anomalies in their results they didn't expect, which are therefore categorized as 'failures'. The article goes on to state that one of the best ways of overcoming this bias is to involve other people from outside of your immediate speciality in discussions about your results.

For me, this triggered the thought process of why it's important to encourage participation in your communities (Open Source or internal) from folks on the periphery of your project - non-specialists who have something to contribute that could be the key to solving a problem or advancing the state of the art. Being an effective community leader/shepherd/guide/manager is as much about how you enable 'outsiders' to contribute as it is allowing the core group to work effectively together.

The Wired article has a great example of how two different groups of scientists went about solving a thorny issue in their research efforts. The story centered around two different labs studying E. coli, and a problem they had with keeping proteins they were measuring from sticking to a filter.

“One of the labs was full of people from different backgrounds. They had biochemists and molecular biologists and geneticists and students in medical school. The other lab, in contrast, was made up of E. coli experts. They knew more about E. coli than anyone else, but that was what they knew..."

"The E. coli group took a brute-force approach, spending several weeks methodically testing various fixes. It was extremely inefficient, and they eventually solved it, but they wasted a lot of valuable time..."

"The diverse lab, in contrast, mulled the problem at a group meeting. None of the scientists were protein experts, so they began a wide-ranging discussion of possible solutions. At first, the conversation seemed rather useless. But then, as the chemists traded ideas with the biologists and the biologists bounced ideas off the med students, potential answers began to emerge. After another 10 minutes of talking, the protein problem was solved..."


Open Source has long had a maxim that 'with many eyes, all bugs are shallow'. I think it's time we extend that idea to include general problem solving and new features/directions in both internal and external Open Source efforts. To that end, remember to encourage and nurture that 'outsider' mentality in your project - don't be afraid to step back and see things from a different perspective. Note that this kind of paradigm shift can happen in closed 'internal' projects, but given the open and dynamic nature of the way Open Source projects/communities function, it should be easier to implement this culture there.

A big part of the power of the Open Source ethos is meritocracy, and checking of egos at the door (as much as possible). Embracing the 'periphery' of contributors can push innovation and productivity to new levels, establishing a positive feedback loop which encourages more collaboration and ultimately, better software.