Highlights from the Survey
This document is one subsection of the Network Operators and Open Source Software project report. Full report available from https://possie.techark.org/
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.
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.
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:
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.
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.
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).
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.
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.
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.
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.
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.
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.
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).
Responding Decision Makers were clearly generally supportive of staff time being contributed to OSS projects.
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.
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.
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.
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).
Looking at the general question of contributing to OSS projects, the top impediment was identified as “lack of cycles”.
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.
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.
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.
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:
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.
Perhaps unsurprisingly, specifically focusing on those who do support staff time to contributions, the curves don’t change.
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.”
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.
Neither Individual Contributors nor Decision Makers reported much in the way of requirements (other than licensing) for using OSS.
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:
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.
Some of the “Other” remarks here included:
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.
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:
The areas proposed in the ranking were:
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:
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.
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.
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
Full report available from https://possie.techark.org/