Since the 1980s, memo after memo has tried to convince agencies to make better use of open source software, and share the code with other agencies that they are using.

Despite the top down push, new research finds federal success with open source is less about the permission slip and more about how the culture of the agency.

Joe Castle, a recent PhD graduate from Virginia Tech, who studied federal technology policy and open source software, and is a federal employee, said the current state of the culture about open source in government is driven by the people, not the agency or memos or any other reason.

“The organizational factors that I looked at was culture, public engagement, structural factors and organizational location, which speaks more to hierarchy in the organization. I went by 24 CFO Act agencies and you see who’s publishing, or how much they’re publishing by volume,” Castle said on Ask the CIO. “Then you go back and say, ‘Well, okay, so if everyone has a CIO shop, conceivably everyone has a budget relative to size, and everyone has skill, then how come this one agency publishes more frequently than this other?’ That’s really where it’s like, there’s got to be something else going on here. If one agency wants to publish, they can publish and the other one just can’t because of some weird reason. So I said let’s apply some logic to this and look at these organizational factors to see what’s really happening here?”

Castle said over three years he interviewed 25 participants from 20 agencies with no participant coming from the same place in their organization. He also collected artifacts like organizational charts and data on open source code release to help inform his research.

“Culture kind of split itself between what I called ‘advantageous’ and ‘cautionary’ beliefs. Advantageous tended to be that organizations or units that had sort of this positive notion of open sources is good, and they should publish for multiple reasons. One of them was demonstration of competency, which I thought was interesting. There’s federal employees out there that develop software they want to publish because they want to be able to show others that they’re actually competent in some sense,” he said. “Cautionary was like, it doesn’t align to the scope of work that we do and my focus is on, say the IRS and tax returns and tax automation or something else. But it’s not really just to develop software to publish it. That is like a side effect, and we’ll do it if it makes sense for us as a unit, but we’re not getting paid to publish software necessarily.”

This means the culture of the organization and people is what is driving the value of publishing the software code. So the memos and guidance that started with the Defense Department’s frequently asked questions in the mid-1980s through the 2016 memo from the Office of Management and Budget were helpful, but not a driving factor.

“I would say that there is a history of policy development and one builds on the next so it’s an incremental change over time,” Castle said. “There’s actually multiple factors that that come into play. In some cases, for cautionary, it’s like, advantageous wasn’t enough. You also needed participatory decision making. You needed some sort of, I won’t call it autonomy, but you needed some sort of hands off nature or some way that individuals say ‘we should do this, we should help each other’s community,’ which kind of leads back to what open source is. You need individuals who understand what code is and how to publish it properly, and then you also need a lot of varied and more often public engagement.”

Policy is important for some agencies

Castle said the policies are important to act as that permission slip. He said he heard from other groups that weren’t publishing as much that they couldn’t publish because their CIO or director or whoever makes the decision has not given them permission.

“There definitely was some individuals who won’t move without a policy. But it has to be like localized policy. When I went to one unit in particular, they just thought they were default to open and they were just publishing whatever they wanted. One person I interviewed said the first thing they did when OMB’s 2016 policy came out was create their own internal policy that matched up to the agency policy that matched up to OMB’s,” he said. “They wanted to make clear that among their organization or unit what someone can and can’t do. So there definitely are layers of policy that has to get to the individuals who are doing the work.”

He added in many ways the policies have to be bottom up, instead of top down where the people who are working with code every day understand the value of sharing and help explain why others shouldn’t be risk averse to the idea and concepts of sharing open source code.

The most recent memo from 2016 required agencies to do three things: Develop their own source code policy internally, how they deal with source code and how they deal with open source; update acquisition language to capture new custom code as it’s developed by a federal employee or a contractor; and create a software inventory or source code inventory, publish that on the agency’s website, preferably the root directory, that would be posted on code.gov, and 20% of that inventory should be published as open source software.

Code.gov has about 6,800 code repositories, which are the meta data of where the code actually lives whether on GitHub or the agency’s website or wherever.

Awareness, acceptance improving

Castle said one common thing he heard about open source is as time, money and people remain in short supply, they see open source as a path to get new capabilities in place more quickly.

“I talked about organization location, there’s definitely a layered sort of the hierarchy of the organization. But the units that did tend to publish more tended to be closer to an authority figure, typically a SES-level person. That gave them this autonomy of trust about what they’re doing with your technology,” he said. “In the places where they said they had to ask their architectural review board, which is five layers above and they’ll never approve this stuff, they were less likely to share. So in some cases the decision to share also came down to professional orientation.”

Castle said his research showed there is more awareness and understanding of open source and the benefits it brings. He said the requirement in the 2016 memo for agencies to publish at least 20% of their code expired in 2020, so he would like to see OMB update the policy and reinstate the requirement.

“I would really love to see open source by default. Why not put it out there because it is a public good, just like anything else, and it’s paid for by taxpayers, and you have to justify why you can’t publish this,” he said.

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.