Network Operators and Open Source Software Study

Highlights from the Survey

Leslie Daigle

December 2020

 

This document is one subsection of the Network Operators and Open Source Software project report.   Full report available from https://possie.techark.org/

General Reflections on Survey Results

Executive summary of Operators’ Relationship to OSS

There is a complex story to tell of the relationship of operators to OSS.  On the one hand, there are complaints that they don’t engage.  On the other, clearly they use it, and clearly they engage sometimes.  So, what can we say about the usage of OSS, and then the nuances of what pulls them to or pushes them away from OSS projects?  And, how do they describe their overall motivations/expectations of contributing to OSS, and then the reality they experience.

Additionally, understanding how others have motivated the contribution to, use or support of OSS internally might help you in your own organization.  As an OSS project leader, understanding the things that make projects attractive or be buzz kills could inform decisions going forward.

The survey included questions that covered issues related to the use, contribution (of time) to, and financial support of OSS.  The respondents’ input helps paint a picture of why and when network operators use OSS.  On the questions of contributions and support, it’s important to look both at the field of OSS projects, as well as the internal motivations and culture around OSS within organizations.

Key Terms

This report is based on a pilot open source software (OSS) project and anonymous surveys of self-identifying network operators.  There were two closely linked questionnaires, asking similar (but not identical) questions.  

• Individual contributors (IC):  network engineers, personnel who have hands on operations and/or code
• Decision makers (DM):  people who have authority to organizer personnel and resources within the organization.

Where it makes sense, the results from these two questionnaires are shown together, with the chart legend distinguishing between IC and DM.

The questionnaires were set up to step through respondents’ input on three facets of engaging with OSS, and this is how they are used throughout this report:

• Using: Making use of existing OSS tools — for the respondent’s own purposes, or network configuration, management, operations, etc
• Contributing:  Engaging in coding and contributing that code to an OSS project
• Supporting:   Providing financial support to an OSS project

Who Responded to the Questionnaire

Respondents’ employment sectors

Both Individual Contributor and Decision Maker respondents primarily came from operations backgrounds.  

Individual Contributors primarily identified as being from Enterprise Networks operations, although a third said they were from more general Network Operator backgrounds.

Chart SurveyReview-1

The split was somehat the other way for Decision Makers, with the majority identifying with Network Operator backgrounds, and a significant portion saying they were from Enterprise Networks.

Chart SurveyReview-2

Respondents’ roles

The bulk of Individual Contributor respondents identified themselves as network engineers.  Eight of them also identified as software developers (of which there were 13, overall).

Chart SurveyReview-3

Nearly half the Decision Makers reported that they managed technical staff (potential contributors to OSS projects).  A third identified as being responsible for software tool acquisition and deployment (potential OSS use), and one fifth said they were responsible for software development strategy.

Chart SurveyReview-4

Operators and Open Source:  Do they use it?

What the survey responses suggest is that network operators are more than willing to use OSS, if it is available and solves a specific problem for them. 

Chart SurveyReview-5

Additionally, respondents rated freshness of the project (recentness of contributions) and availability of documentation as important considerations in choosing to use specific OSS tools.  In terms of general attractions to using OSS, the top responses (for both Decision Makers and Individual Contributors) were focused on being able to extend the codebase (to suit the organization’s needs), and being able to inspect the codebase.   Getting “cheap” software wasn’t even close to the top reason.

Chart SurveyReview-6

Chart SurveyReview-7

Breaking down OSS usage

The Decision Maker questionnaire included a breakdown of network operational purposes for which OSS might be used, asking respondents to select their likelihood to use OSS for the purpose.

What stands out in the data is that the two most common uses of OSS were for Server OSes or for Network Management.  And, there is a split of opinion about using OSS for Network OSes — 43% of respondents said they use OSS if it is available for the purpose, while 29% said they would never use OSS for a Network OS.

Chart SurveyReview-8

Impediments to use of OSS

Unsurprisingly, the impediments to using OSS largely mirror the attractors, with the additional key challenge of finding a single OSS tool to solve a given problem. 

Chart SurveyReview-9

However, when respondents who were not able to find OSS tools are filtered out, the picture is different for Individual Contributors (who said they didn’t have in-house resources to do necessary work on the tools) and Decision Makers (whose concerns about licensing became predominant).  Both still expressed concerns about finding a single OSS package to meet needs and integrate with their vendor platform.

Chart SurveyReview-10

Why don’t operators engage in OSS development?

Clearly, some do engage

Of the Individual Contributor respondents, 20 (of 34) said they contributed to OSS projects, and 9 said they had never contributed (5 respondents provided no information).

Chart SurveyReview-11

Responding Decision Makers were clearly generally supportive of staff time being contributed to OSS projects.

Chart SurveyReview-12

From both the Decision Maker and Individual Contributor perspectives, the bulk of the respondents’ companies regularly support staff time contributions to OSS projects, and a significant portion are at least considering it for the future.

Chart SurveyReview-13

Interestingly, Individual Contributors and Decision Makers had different perspectives on whether or not their companies provided financial support to OSS projects.  This may be a function of the questionnaire not having enough coverage to be statistically meaningful, or it could be because the Decision Makers were more likely to be in charge of making those financial contributions, or something else entirely.  Nonetheless, it is a curiosity worth noting.

Chart SurveyReview-14

Major attractors and impediments to contributing time to OSS

The key reason for contributing to particular OSS projects is to tailor the code to meet the organization’s own needs.  Additionally, a significant proportion of Individual Contributors identified that they had found bugs in OSS and took the opportunity to contribute the fix back to the OSS project.  Particularly for Individual Contributors, aspects of a given project’s culture clearly come into play — whether the project has an open and transparent governance structure, a lively development community, and whether or not they know and respect other developers on the project.

Chart SurveyReview-15

On the flipside, not being happy with a project’s governance structure was second only to a lack of properly-skilled in-house resources in the identification of impediments to contributing to a specific OSS project (“lack of skills” was asked on the Individual Contributor question about specific projects, and the Decision Maker question about OSS contributions in general).

Chart SurveyReview-16

Looking at the general question of contributing to OSS projects, the top impediment was identified as “lack of cycles”.  

Chart SurveyReview-17

Major attractors and impediments to financially supporting OSS

As noted above, the respondents’ companies do provide financial support for OSS, at least sometimes.   The standout reason for providing financial support for a project was identified as:  the organization believes in the OSS project and wants to support it.  In the remarks for “Other”, respondents indicated they provided support in order to gain access to feature prioritization, or to get technical support, among other reasons.

Chart SurveyReview-18

There are clearly things that can improve or inhibit financial support for particular OSS projects.  Although “lack of funding” is identified as the major impediment to supporting a particular OSS project, it is clear that Decision Makers want to see how the project money is being spent (transparency), and that it is being spent on things that advance the project, specifically.

Chart SurveyReview-19

Interestingly, when it came to the question of more generally supporting OSS projects and platforms, no one said they supported a project because their competitors (visibly) did.  From the comments provided in “Other”, one interpretation of this chart is that responding network operators pick and choose OSS projects to support based on their specific software needs.

Chart SurveyReview-20

Drivers and Rewards

Purpose and Perception

Other sections outline the attractors and impediments to contributing to OSS projects, but it’s also important to understand the broader purposes for contributing, and the rewards reaped.

First, looking at Individual Contributor responses, it’s clear that contributing to OSS projects provides an important avenue for professional development.  The top response illustrates that ICs believe that participating in OSS projects helps them expand their skillset.   

They also identified, in provided comments, that there are community and business motivators, as well:

• “[…] being unselfish and sharing knowledge and tools with a broader community”
• “Lower operational cost when our internal changes are accepted upstream”
• “Developing automation reduces repetitive tasks and makes my day job easier, contributing it upstream reduces the amount of effort to maintain it”

Chart SurveyReview-21

Decision Makers clearly also agree that their engineers increase their skillset by participating in OSS projects.  Additionally, they perceive that participation in OSS projects helps ensure that there is industry alignment on matters of interest to the organization.  This means that OSS contributions have a broader impact for organizations than just the benefits they offer their engineers.

Chart SurveyReview-22

Perhaps unsurprisingly, specifically focusing on those who do support staff time to contributions,  the curves don’t change.

Chart SurveyReview-23

How well does it work out?

The charts above outline the purposes and perceptions of Individual Contributors and Decision Makers in their (support of) contributions to OSS projects.  Later items on the questionnaire explored how well those (largely positive) expectations for OSS projects had played out in the work place.

And, on the whole, respondents found contributing, or supporting contributions, was useful.  Specifically, their experience suggests that they have indeed broadened skillsets, and succeeded in getting software tailored to their need.   There were very low numbers reported for possible negatives from contributing to OSS, although one Individual Contributor respondent did point out that “being outside the core team of any project tends to mean my contributions are given lower priority.”

Chart SurveyReview-24

Organizational Requirements for Use and Contribution to OSS

Licensing

The same questions were asked of Independent Contributors and Decision Makers for both their organizations’ licensing requirements for using OSS, or contributing to OSS projects.

There was more consistency in responses within groups — roughly the same perception of licensing requirements for using or contributing to OSS projects.  However, it is notable that Individual Contributor and Decision Maker perceptions were at odds with each other in important ways.

Notably, most Individual Contributors asserted that their organization had no licensing requirements for using or contributing to OSS projects.   While a number of Decision Maker respondents answered similarly, more of them asserted that the projects had to offer reasonable and non-discriminatory (re-)use of the code in either case.  It’s also important to observe that respondents generally picked that (RAND) over free and RAND.

Chart SurveyReview-25

Using OSS

Neither Individual Contributors nor Decision Makers reported much in the way of requirements (other than licensing) for using OSS.  

Chart SurveyReview-26

The fact that support availability was not a top issue seems interesting, as it is often a key differentiator between OSS and commercial software.  Perhaps the bulk of respondents (who answered “None”) had already factored that expectation into the choice of using OSS.  Perhaps being able to “self-support” is an attractive feature of using OSS.    

The “Other” elaboration, Individual Contributor and Decision Maker remarks provide insight into what might be missing:

• “The ‘toll-free’ and ‘24x7’ are unnecessary qualifiers. My organization requires a service/support contract, the specifics of which are important but not critical. A phone number of any kind with any hours is what is needed.”
• “For some critical components (e.g. software-defined storage), it's pretty important to have SOME paid support option to get us out of a potential mess. Doesn't need to be strictly 24x7, and certainly doesn't have to be toll-free.”
• “Want someone else to blame when stuff breaks”
• “Approved by Information Security”
• "required some form of paid support email w/limited/surcharged phone is fine”
• “Reasonable support availability, doesn't have to be 24x7, but needs to be more than e-mail”
• “Support, only if highly critical tool (e.g. database)”
• 
  

Contributing to OSS

Respondents were not very fussy about requirements for contributing to OSS projects.  Very clearly, large project platforms are not perceived as a requirement for engaging with OSS projects.  Again, the responses from Individual Contributors did diverge from those of Decision Makers, insofar as Individual Contributors were much more likely to perceive “no non-licensing requirements” for contributing to OSS, while Decision Makers clearly wanted to see a project with active contribution and clear, published governance rules.

Chart SurveyReview-27

Some of the “Other” remarks here included:

• “We must be able to exclude liability for our contributions”
• “Must be a clear, comprehensible business benefit to contribute rather than fork, maintain local patches, develop locally, or buy a proprietary solution.”

Internal coordination

Individual Contributors and Decision Makers were asked about the degree of internal coordination of OSS use, contributions and support.   The area most identified as having internal coordination was related to keeping track of OSS software being used / depended on.    That suggests that OSS is treated no differently than commercial software packages.   Overall, fewer than half of respondents (of either group) indicated that there was coordination of engagement with OSS — contributions, financial support, or direct management of engagement. 

Chart SurveyReview-28

Perceived Gaps in OSS

Both Individual Contributors and Decision Makers were asked to identify where they saw gaps in the landscape of available OSS tools.  They were asked about the same potential gap areas in terms of:

• Whether they’d like to see OSS address the area
• Whether the gap posed a mission-critical issue for them
• Whether they would contribute (time and/or money) to address the area.

The areas proposed in the ranking were:

• OSS reference implementations of new open standards
• A credible (reliable) OSS networking stack to ensure that new devices (e.g., IoT) have a decent likelihood of doing networking properly
• More network configuration tools available in OSS
• More network management tools available in OSS
• A tool to configure and manage my entire network through a solid OSS package
• Nothing
• Other

Only two concrete suggestions were recorded in “Other”, both on the Individual Contributor questionnaire in the question about what areas they would like to see addressed by OSS:

• “I would like more projects to adopt structured processes for governance, release engineering, standards, documentation, testing, etc.”
• “Secure firmware updates for embedded devices and IoTs”
• 
  

Perceived Gaps

Although it makes for an eye-strain chart, it’s best to look at all the results together — across both Individual Contributor and Decision Maker responses, for the 3 questions.

Chart SurveyReview-29

Clearly, both groups want a lot more from OSS, ranking all concrete offerings highly.  Neither group views many of these choices as solving mission-critical issues for them.  Nonetheless, and on a positive note, there seems significant willingness to contribute to the different areas.

Interestingly, “Open Standards reference implementation” ranked highly for both Individual Contributors and Decision Makers, in terms of both interest and willingness to contribute.  In fact, that was the highest ranking gap, looking at the composite rating, for Decision Makers.  Not so for Individual Contributors, who viewed OSS for Entire Network Configuration and Management as their top choice.

Conclusions

Clearly, network operators are using and contributing to Open Source Software.   They are selective in where they choose to engage: picking projects and tools that solve operational problems.  Key challenges for contribution include lack of cycles and lack of (coding) expertise.  Put-offs are focused on whether a project is well-documented and has recent contributions.

Organizers of individual OSS projects can improve their attractiveness (likelihood of engaging operators) by addressing the last two points — documentation and project freshness.    They can also work on ensuring that the subject of focus in the OSS project actually targets an operational problem experienced by operators.  It’s more of a challenge for OSS project organizers to address operators’ lack of cycles or coding resources.

  Also clear from the results of the survey:  people should be encouraged to participate in OSS — clearly, Individual Contributors and Decision Makers that answered the questionnaire find it useful, and haven’t experienced anticipated negative side effects.

Full report available at https://possie.techark.org

 

Leslie Daigle

December 2020

Full report available from https://possie.techark.org/