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.

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.

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.

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!