Federal Source Code Study Series Part 4: Cultural Beliefs

Federal Source Code Study Logo (Code.gov)

By Joe Castle, Ph.D. and Code.gov

We’re back with our fourth installment of the Federal Source Code Series. As summarized in Part 1 of this series, the study explored four organizational factors believed to be hindering or aiding agency publication of OSS. The organizational factors were cultural beliefs, public engagement, structural dimensions, and organizational location and each will be explored in an upcoming series post. We begin here with cultural beliefs.

There is a lot of academic and industry research on culture and its various components. This study briefly defined organizational culture and how cultural beliefs may have impacted federal agency ability to publish OSS.

Culture

There are numerous definitions and elements of culture. Culture was originally rooted in anthropological and sociological studies with a focus on relationships among small groups and tribes through the study of behaviors and norms. It was considered to be relatively stable and homogeneous. Organizational culture provided a view of social arrangements and outcomes in workplaces, which enabled managers to exercise control and ensure success. Culture is often considered as a monolithic phenomenon or one culture to a setting. However, organizational units tend to exhibit subcultures, not necessarily in conflict with the parent culture, but supporting their own norms and behaviors.

Beliefs

Beliefs are a key component of organizational culture and support organizational performance. Beliefs support organizations in making predictions, selecting actions, and play an important role in understanding what was observed and enacted in particular situations. Beliefs can be used for making predictions and selecting actions and they could play an important role in understanding what is observed and enacted when confronted with a particular situation. Beliefs are acquired through experience by explanations and consequences supporting or negating a belief. Finally, beliefs are continually and collectively validated as groups tested and solved problems.

Interview Guide & Cultural Beliefs

Recall for this Series Part 1, there were 25 participants from software development units in 20 CFO Act agencies. Some agencies had multiple participants, but no participant was from the same SW development unit.

The interview guide consisted of the following questions or statements pertaining to cultural beliefs.

1. What are your unit’s beliefs on consuming open source software (OSS)?
2. Based on public data, your agency publishes code minimally, intermediately, or frequently. Does your unit publish code, and if so, does your unit believe this is the appropriate amount?
3. Based on response to the previous question, provide why the unit believes this is or is not the appropriate amount.
4. Does your unit use a public coding platform with open repositories?
5. Describe your unit’s goals with regards to software development (e.g., collaborate, deliver product).

Findings

As a first step, participants were asked whether they believed their unit published enough OSS. The responses were almost evenly split between “yes” and “no,” however the majority of “no” respondents were in units that were minimally publishing OSS. This called for further probing into potential cultural belief factors hindering or aiding publication of OSS.

Data pertaining to cultural beliefs provided for creation of two main categories with multiple sub-categories.

1. Cautionary — Participants whose units held cautionary beliefs were reticent in their response to new technology and technology policy. This reticence evidently stemmed from the inherent scrutiny government entities receive through annual ethics reviews and training as well as frequent public inquiry.

• Align to scope — This sub-category included data from participants who believed that software development should be aligned to a specific organizational scope and that it seldom did.
• Change in practices — This sub-category included data from participants who viewed change negatively, which hindered the unit’s frequency of publishing OSS. Beliefs about change in practice invoked fear, required the actual change itself, and required updated or new high-tech skills.
• Consider risk — Responses from participants that clustered in this sub-category centered on the belief that publishing OSS was inherently risky. The beliefs about risks were related to transactions. These transactional concerns included a consideration of contracts and other aspects of building software, such as the process to publish code, deviation from an approved review process, and consumption of code along with trying new code platforms.
• Need permission — Some unit participants believed permission was required to publish code. These participants believed they needed to obtain permission from their management and customers.

2. Advantageous — Advantageous beliefs were based on perceived and realized outcomes.

• Build community — Participants believed publishing code was beneficial because it created a community of sharing and collaboration.
• Create efficiencies — Participants believed publishing OSS created efficiencies in the software development lifecycle because it allowed the unit to break down development silos, utilize new development technologies and processes (i.e., Development Operations or DevOps), and minimize redundant code.
• Demonstrate competency — Participants believed publishing OSS demonstrated unit competency with software. This competency was the unit’s ability to exercise authority to publish OSS. The unit justified publication based on professional ideals.
• Realize benefits — Participants believed publishing code provided benefits resulting in cost savings and transparency for citizens regarding what the government does with taxpayer funds as well as providing public access to the end product. Realizing benefits encompassed beliefs that OSS publication would help reduce technical debt, improve code quality, provide better documentation, provide cost savings, and help build a sustainable product.

Of note, some participants held both cautionary and advantageous beliefs meaning the categories were not mutually exclusive and further analysis was needed to understand cultural beliefs. As will be shown in later posts, other factors along with cultural beliefs affected whether a unit was more likely and frequently publishing OSS.

Summary

Cautionary and advantageous beliefs were associated with whether and how a unit publishes OSS. Cautionary beliefs centered on scope alignment, change in work practices, risk avoidance, and need for permission; advantageous beliefs included building a community around the software, creating development efficiencies, demonstrating competencies, and viewing code as being beneficial to the public.

Coming Up

The next part of this series focuses on the organizational factor of public engagement and how it affected OSS publication.