How Online Organizing Lessons from ’04 and ’08 Can Help NASA in ’09
Recently I was asked to reflect on how the lessons of online organizing by those of us who worked in the 2004 Presidential campaign have impacted not only the 2008 Presidential campaign (in which Dean ’04 and Clark ’04 veterans teamed up to create Blue State Digital, the technology backbone of Obama’s online operation), but also the Federal Government, over the past four years.
Many 2004 campaign veterans have been working in the realm of making government more open in order to enable watchdog oversight of it. I have been working more in the realm of trying to make government more efficient and effective through technologies and organizing techniques that promote openness. I’m personally mostly focused on the cultural and policy side of things– trying to get people inside NASA used to being more open and sharing by default rather than only when explicitly forced to. There is also a great deal of work being done by reformers in the CIO’s offices and elsewhere on the communications technology side of NASA’s operations. They’re working on open APIs, open-source licenses, etc. I’ve told a bit of this story, in the context of NASA, in several presentations over the past year. Here below I’ve attempted to break down the problems, implications and solutions I see in a more structured format, again using examples we have encountered at NASA.
Note that none of these observations need be specific to NASA… They apply to any large government bureaucracy, and we are working with our change agent peers in other Agencies as well. We simply have the luxury/curse at NASA of a high-profile brand and significant public interest and goodwill to use as a lever for this change.
I. INTERNAL COMMUNICATION / COLLABORATION IS INEFFICIENT:
EXAMPLE:
- no internal searchable database of people, projects, skills and technology assets
IMPACTS:
- internal inefficiency and redundancy
- internal competition for resources
- a culture of sequestering information because having information that no one else has is perceived as having power
SOLUTIONS:
- reforming human resources policy to permit and encourage more open communication (internally and externally) and bottom-up innovation, and reforming management structure to create a more flat more networked organization
- foster cultural change, including renovating NASA’s physical plant to create inspiring workspaces that foster openness and collaboration
- creation and implementation of systems to capture knowledge and make it searchable
II. EXTERNAL COMMUNICATION IS CONTROLLED, CENSORED, AND UNIDIRECTIONAL
EXAMPLES:
- slides for any Powerpoint presentation to be given to a public conference are supposed to be submitted for review well in advance to make sure that no sensitive information is included in them, rendering it onerous to speak openly or to include recently updated information
- policies for NASA employees to spend their own time working on other projects, communicating through social media about their ideas and work, etc. are restrictive and at best fuzzy, and the burden of proof rests on the employee to prove WHY they should be able to communicate with the public, rather than the burden of proof resting on the Agency to prove why not
- NASA.gov reaches millions but is all processed edited moderated content; very difficult to mash this content up and re-share it, and no opportunity for user-generated content either from the public or from a broader array of NASA employees than just authorized Web Content Managers.
IMPACTS:
- less public interest and awareness and inspiration and educational benefit than otherwise possible, because content consumption is passive
- NASA unable to benefit from the innovation and work cycle leverage that could result from leveraging the goodwill, technical skills, time and creativity of members of the general public, and entrepreneurial private sector
- NASA has difficulty attracting and retaining talent that is used to working in a more open environment in the private sector
SOLUTIONS:
- agency-wide deployment of the Web 2.0 communication tools, communications policies, and processes used by the world’s leading private technology enterprise
- build communities and create formal processes to leverage the time and skill of these communities for practical benefit to NASA
- highlight and build on the few examples of successful crowdsourcing at NASA
- create sustainable professional relationships between NASA and non-NASA personnel that shift NASA’s internal culture through co-working and open-space format events
- shifting the budget and skillset of NASA Strategic Communications staff to focus on encouraging, training and supporting non-StratCom staff in their public communications role, including hiring staff with corporate blogging and online organizing skills
- set communications policy that mandates open publication of all internal Agency communications such as meeting minutes, absent demonstrable and internally verified need to maintain confidentiality; shift the burden of proof from the need to show that information is “safe” to publish, to the need to show the information “is not safe” to publish.
III. KNOWLEDGE, DATA, AND IP CANNOT EASILY BE SHARED
EXAMPLES:
- NASA hires contractors to write code and doesn’t mandate that is be open-source and often doesn’t even acquire the rights to modify, repurpose, or release that code
- IP created within NASA is unknown and unsearchable internally, let alone externally, and it is extremely labor intensive and relationship-dependent for internal business development staff to collect data, identify IP licensing opportunities, and execute those licenses
- petabytes of data collected by NASA that is legally in the public domain is extremely difficult to find, search, interpret, and share, due to slow data processing and archiving and limited APIs
IMPACTS:
- the inability to get more eyes on code eliminates an opportunity to reduce the likelihood of failures such as the Mars Climate Orbiter explosion
- NASA pays more $ for code to be written by contractors than it would have to if it leveraged existing open-source projects (including its own)
- NASA returns less value to the taxpayers because IP assets aren’t easily licensed or contributed to the public domain where they could yield ancillary benefit to society
SOLUTIONS:
- increase the use of open-source software by improving the language of the NASA Open Source Agreement, changing procurement policy to require that contractors use and create open-source software whenever possible, and by creating clear policy guidelines, communities of practice, and hosting infrastructure that make it easier for NASA staff to use and produce open-source
- reform the International Traffic in Arms Regulations
- build (and mandate adherence to) standards and open APIs for all NASA data sets and an upcoming (not yet funded) “NASA.net” initiative
- improve internal knowledge sharing between technical and business groups within NASA through co-working, community building, collaboration tools, and improved knowledge management systems
Keith Cowing on November 7th, 2008
I am rather baffled by the lack of response to Andrew’s post by the Gen Y crowd …
Michael Finneran on November 8th, 2008
I couldn’t agree more with virtually everything written here. Andrew, I would love to have you come talk with the New Media Team (aka the WackoMedia R&D Project) that I recently began leading at Langley. It’s still very much in its infancy. I also invite you to join openLangley and its affiliate Facebook group, and repost what you’ve written here. We need more voices like yours. You can get there through http://openlarc.com and you can reach me at michael.p.finneran@nasa.gov if you’re interested.
Anne DeLion on November 8th, 2008
I think this is a fantastic list. I dealt with Section II just in the past few weeks. I wanted to find NASA-sourced information on the Hubble malfunctions and repairs that happened over the last month. It was impossible to find, and part of the problem is that there seems to be at least THREE “main” Hubble websites! Hubble is one of the most well-known missions at NASA and making it difficult to find information about it does the agency no favors. I think this is a symptom of the larger problem you’re talking about.
It seems that NASA relies too much on its past history to maintain its public image rather than actively engaging with the public to educate and inspire those who aren’t already interested in what NASA has to offer. NASA has a vested interest in having strong connections to the general public, and it has to do a better job building those connections.
I hope there are people within NASA listening to your suggestions!
Karen Freidt on November 12th, 2008
That would be great if Andrew could come talk to us. I just have one suggestion. Why not let all who want to hear him join us instead of just our team hearing the talk?
Michael Finneran on November 12th, 2008
Absolutely.
Karen Freidt on November 12th, 2008
I will help set up it up if he can make it. Let me know. Thanks!
Garth Henning on November 12th, 2008
I love the sentiment, but I’m not sure I yet see how this philosophy translates to an actual implementation.
I. How about the Competency Management System? How about the initiatives to match up the name lookup with the competency data and people’s prior project history? How about the now-canceled Technology Inventory Database? How about any of the myriad knowledge management systems? There are a number of initiatives addressing what you discuss, but naturally they all have pros and cons. For instance, I understand the desire for someone at a research center to make research more discoverable by people working missions, but do you have any lessons that could preclude stumbling right back into the problems that plagued the Technology Inventory Database?
II. Do you have any examples of missions signing up for this kind of communications strategy? I see lots of these kinds of discussions that come at the problem from the IT professionals point of view, but few where anyone addresses things from the mission point of view. There is a historic divide, sometimes called the “valley of death,” where the advocates for a maturing technology can’t seem to communicate its virtues to the missions that might employ it.
I’ve actually heard some discussion over on the human spaceflight side about opening up meetings to the public. While there is some support for this, there are also significant and well-reasoned objections. I’d love to see if you have some ideas for how to address those objections.
III. As someone who used to develop software for NASA control rooms, I’m not sure your approach can apply quite as widely as you may think. I do love the idea of open sourcing more code. However, the current system also has its place. NASA procures lots of code for lots of different reasons. It might be beneficial to set out what you think the criteria for open-sourcing code ought to be (i.e. is scientific data analysis software something to open source where control room software is not?)
The competitive nature of software contracting should also factor in. For a mission with a need and a limited budget, they may not wish to impose any additional requirements such as open sourcing the code. There is a definite possibility that this requirement will cost the government more. For example, it already costs the government more to have extra design documentation written/delivered that might enable a downstream competitive procurement for the software’s sustain engineering. Any additional work that needs to be done will get billed back under the typical cost-plus contract and its not now possible to show a specific project that there will be some offset back to them later due to open sourcing.
Also, I’d love to hear where you stand on software bidders including proprietary patents or trade secrets in their bids. These things are definite advantages certain companies can offer that can save real projects on budget and schedule. However, I haven’t been able to reconcile these advantages with the incompatible advantages of requiring that deliverables have public open source.
ahoppin on November 13th, 2008
Great feedback Garth– thank you for taking the time to give it.
I agree that there isn’t yet an implementation plan in existence, and my goal here isn’t to provide one. I’m also NOT saying that NASA KM (or any other group involved in these realms) is doing a bad job (they’re ahead of most Federal Agencies IMO). Rather, my goals are:
a) to share my experience of and open a dialog about the nature of these problems experienced within NASA and more broadly many Federal Agencies– and in so doing to elicit in an open forum exactly the kind of experience and information that you’ve just shared, and
b) to point out that there are some experiences we can draw on and benefit from from outside Government, and
c) to point out that any technology solution would need to address policy and cultural constraints as well in order to be effective.
…all in hopes that by pointing these issues in a public forum, we’ll increase the chances that solutions to the identified problems, and the people already working to address them, will get more attention, resources, and internal political empowerment in the future.
What we have at the moment are a set of experiences, trials and errors internally within NASA, and a set of experiences and successes external to NASA to draw from. It’s my hope that the development of comprehensive Agency-wide implementation plans for solutions to these perceived problems is prioritized in the future, because I think they’re fundamental to NASA’s long-term sustainability and effectiveness.
To address your specific feedback:
I. You mention three or four attempts to address the tools side of the problem, and I linked to three other related efforts in my original post… The very fact that there are “any number” of initiatives underscores the problem– that there is no comprehensive solution in existence today… My assessment of this is mostly from second-hand reports, and I’d love to be proven wrong on this so please feel free! In re: the Technology Inventory Database, I’m not familiar with its problems– are the problems documented somewhere publicly so that we and other enterprises can learn from them?
II. Piecemeal examples only– Mars Phoenix on Twitter, LADEE doing some great early work, etc. The existence of a Valley of Death, as you put it, is a cultural problem that I have seen addressed effectively through leading by example in other industries. If one adopts new practices and tools that work, documents and openly communicates your successes with them, shares access to them, and provides a policy and cultural environment conducive to widespread adoption, then adoption and demand can snowball quickly. Mission requirements may also need to be altered to drive the demand side of this equation, if you accept that all this is a good idea in the first place– that is a policy battle already well underway.
III. My belief is that all software that is not national-security sensitive should be open-sourced, with the burden of proof placed on proving that is SHOULDN’T be opened up, rather than that it SHOULD be. It is far too onerous today, I’m told, to open-source code developed internally, and to adopt and use open-source code sourced externally.
The economics of open-source, typically result in vast cost savings, but you need to consider economics over the long-term (e.g.: value the reuse of software by other projects in the future, and even reuse beyond NASA by other taxpayer-funded entities, and even by taxpayers themselves). The current nature of missions in competition with one another for funding certainly is not conducive to this sort of long-term strategic thinking, but it doesn’t make it right– it just means, in my opinion, that we need to look at a major overhaul of the way software is procured and mandate changes. As long as every vendor and every mission team is dealing with the same set of rules, they’re still competing on a level playing field. But we need better rules.
The issue of vendors incorporating trade secrets or patents is completely valid– if there is no better proposal out there, then proprietary software proposals should be awarded. I’m a big fan of NASA becoming a customer of SaaS solutions even though they’re not typically open-source, for example, because it is an example of intelligent reuse of a platform, the development costs of which are amortized across thousands of other customers over time. But the value of an open-source alternative that will less expensive in the long-run and deliver more value by being reusable needs to be incorporated in the evaluation of which option is “better.” For example, SugarCRM should have a point in its favor relative to Salesforce.com, in my opinion, because it is a SaaS CRM solution that is also open-source.
Thanks again Garth– I really appreciate your input, and learn from it.
Justin Kugler on November 17th, 2008
At JSC, there are several teams looking at how to be a more inclusive and innovative center. I’d venture to say that the various teams are looking at all the issues you’ve raised, in one form or another.
On the Barrier Analysis team, we’ve spent quite a bit of time looking at the issue of “a culture of sequestering information because having information that no one else has is perceived as having power.” That also works in parallel with the compartmentalization of organizations.
In benchmarking organizations that innovate on a regularly successful basis, we’ve found that a consistently good way to break that cycle down is to promote people into management not solely on seniority or technical expertise, but on the basis of their demonstrated leadership skills.
The principles of “servant leadership,” where a leader’s job is to work to break down barriers for his or her team, have to be promoted not just in word (in which case, people just give it lip service), but also in terms of performance evaluations and incentives for superior leadership.