Network Operators and Open Source Software Study







Full report

Leslie Daigle

December 2020









 

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


Highlevel overview of the (whole) report

There are 5 highlevel sections to this project report:

  1. Background of the project
  2. Targeted takeaway sections — for specific questions or audiences
  3. Pilot project report
  4. General reflections on the answers to the questionnaires and summary results
  5. Full responses from the questionnaires

  


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

 



Network Operators and Open Source Software

Go to any network operator group meeting, and you’ll be met by a pre-meeting hackathon, encouraging participants to engage in open source software (OSS) development of some description.  The sense is that OSS is important to network operators.  There’s also an accepted truth that network operators are not as engaged with OSS as they might, or ought to, be.

In 2019, a project was established to explore this apparent contradiction.  One set of goals of the project was to better understand who is using, contributing to, and supporting OSS, and why.  Another set was to better understand who is not doing some or all of the above.  What are the sources of friction that can be addressed to improve engagement with OSS?  What are the things that are immediate attractors, or outright buzzkills?

The project started with a hypothesis that some organized efforts at collaborative development of OSS could lead to useful things for network operators.   That basic hypothesis left a lot of scope for the kinds of problems that might be solved through such OSS development (tooling?  Reference implementations? Etc), and what “collaborative” might mean.  It also didn’t square up well with the fact that network operators seem reluctant in contributing to open source development projects.  Was that from a lack of interest in OSS tools?  Or something else?

The purpose of this project was to carry out two pieces of critical research as groundwork for creating a viable “platform for open source software for Internet evolution” (POSSIE). The two critical pieces of research are:

  1. A pilot open source project, developed collaboratively, to demonstrate interest in such activities and governance methods
  2. An industry survey to raise awareness in the project and capture objective measures of interest in different possible models for scoping POSSIE’s work, and ensuring any resulting software was useful in industry.


Pilot project

As a first step in developing the governance framework for POSSIE, a pilot project was proposed. The specific proposed project was to work with network operators to develop a router configuration validator tool for the Internet Society’s “Mutually Agreed Norms for Routing Security” (MANRS) initiative. Specific project steps are outlined in the project report, and largely cover managing the processes of developing the OSS problem statement, finding participants, and facilitating development and review, through open and transparent processes.

As the report indicates, the project saw some lumpy progress forward, but it fell apart because the people with the focus and interest to do the work didn’t have the cycles.  In looking to find new project drivers, it became a battle of choice of favourite tools.   While a broad range of network operator participants would show up for calls to talk about the project and requirements, they didn’t have cycles, or necessarily the skills, to do the actual OSS work.    This is backed up by the survey results. 


Industry survey

This project undertook a survey of network operators to gather information about:

The survey took the form of two questionnaires:  one offered for individual contributors to OSS, and the other for decision makers within companies that do (or do not) use, contribute, or support OSS.  

The survey project saw much more response than even hoped for — 48 total responses in the 6 weeks the survey ran.  As outlined in the report, the responses provide some clarity on the contradicting views about network operators and OSS — e.g.,  the biggest impediments are lack of cycles and/or skills; clarity on what both individual contributors and decision makers actually want from OSS.


Overall, project results suggest the following for any OSS project to be successful in attracting network operators to use and contribute to it:

These are all points that could be addressed in any eventual “Platform for Open Source Software for Internet Evolution”.


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

 


Targeted takeaways

There are 3 key targeted takeaway reports from this project:

  1. Top level findings from the study
  2. Key points for pitching OSS within an organization
  3. Best approaches to ensure OSS projects are appealing


Key findings from the Network Operator OSS study

Increasingly,[1] open source software (OSS) is important to network operators of all types.   Interests vary, perhaps stemming from a desire to reduce dependency on any single hardware vendor (by having vendor-neutral software), a preference to be able to examine the source code for independent security review, or something completely different.  

 By the very nature of OSS development, engagement is essential to ensure that the software delivered fulfills an actual need and is useful in an operational context.  However,  while it is clear that hardware vendors are engaging in community open source projects to serve networking needs, such as those at the Linux Foundation Networking effort[2], it is less evident whether network operators are engaged in developing the very open source software of which they are targeted to be consumers.

This project canvassed network operators (individual contributors (IC) and decision makers (DM)) to gather information about their stance towards OSS, with a view to understanding what might increase operator engagement, and where current OSS efforts might be falling short of network operator needs.

The full results from the project (questionnaire and pilot development project) reveal many interesting findings.  The three key takeaways can be summarized as follows.

Why don’t network operators contribute to OSS development in their own interests?

The top reason cited for not contributing was a lack of available resources (personnel cycles).  This was especially notable from the decision maker respondents (76%), although it was also a clear message from individual contributors (50%).  

Individual contributors also cited a lack of requisite skills as a major impediment.

Notably, most respondents did not select answers to say they had no use for OSS or failed to see any value in contributing to external projects.


Image

Chart KeyFindings-1

What’s missing in the OSS landscape?

Respondents most strongly supported “Open standards reference implementations” as a gap in the OSS landscape (86% of decision makers and 68% of individual contributors selected it).  

Importantly, roughly 50% (combined) would contribute to projects to address the perceived lack of OSS open standards reference implementations

Decision makers and individual contributors had differing perspectives on what was the second most important OSS gap



Image

Chart KeyFindings-2

Can we address these issues through collaborative open source development?

The pilot project component of the project, which focused on taking an existing set of collaborating network operators with an identified tool need,  revealed one important lesson:  for success of collaborative open source software projects, an active organizer is necessary, but not sufficient.   A successful project must also have identified coding resources (either committed from participants, or provided by the platform) in order to make progress.


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

 



Pitching OSS within organizations

There is a common conception that OSS is just “free software”, or something you reach for when you don’t have the budget to pay for slick, well-packaged, proprietary solutions.  Whether or not that was ever a complete or accurate characterization of OSS, survey respondents made it clear that the lack of a purchase price for the software was one of the least considerations in choosing to use OSS.

In today’s reality, there are business-compelling reasons to use, and contribute to, open source software projects.    It is important to be mindful of why and when to engage in them.  The flipside is that there are compelling arguments to use if you are trying to persuade your management to be supportive.

Top reasons for using OSS

Instead of price tag, respondents (both individual contributors (IC) and decision makers (DM)) indicated that their top reasons for using OSS were centred on the codebase itself.


      

Image

Chart PitchingOSS-1

Contributing to OSS yields more positives

The business of network operators is networking, not software development.  Contributing to OSS projects provides a way for network operators to help shape the software they need, as described above, and keep up with industry trends.  It also allows for individual contributors to engage with others that share common problems (and may have different insights), and broaden their skillsets beyond the range of opportunities the network operator organization could offer in-house.


Image

Chart PitchingOSS-2


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

 


Making OSS Projects Appealing


You can legitimately claim to have made Open Source Software by simply posting your software source code somewhere publicly accessible.  However, if you want your software to be adopted, there are some key expectations of potential users and contributors that are important to address.  

For OSS project owners, making the right choices will determine the likelihood of uptake of the OSS itself, and willingness of others to contribute.   The survey identified key project characteristics that were potential “buzzkills” — things that could turn operators away from using or contributing to projects, in spite of initial excitement in the prospect.

Buzzkills for OSS use

 To get serious interest from operators (beyond a buzz of discussion), OSS projects have to provide a tool that solves an operational need (imperative), and it should be readily integratedwith their vendor hardware/ecosystem.  

Even with those conditions met, respondents identified the top things to avoid if you want network operators to pick up and use your software as:

Those are all features that are withing the scope of an individual project owner to address and improve. 


Image

Chart OSSAppeal-1


Improving chances of contribution

The question of whether or not operators will contribute staff time to OSS projects is chiefly a matter of internal corporate choice.  However, survey responses revealed that there are things that OSS project owners can do to improve the likelihood of contributions.

Chief among these are:

OSS project owners might also consider the other two impediments (time to tailor, lack of skilled resources) when selecting software coding languages and frameworks.  The more common the development environment, the more likely other entities will have skilled resources, for example.


Image

Chart OSSAppeal-2


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

 


Pilot Project Report


Pilot Project — executive summary

Would a platform for collaborative Open Source Software projects be useful and engaging for network operators?  The POSSIE project included a pilot project to explore the issue.  

The project focused on one target software tool to develop, collaboratively, in open source software, and provided an organizational framework in which to progress the work.  The primary question was:  did this framework (an example of what a standing OSS platform could offer) provide the context necessary to engage operators?   And if not, why not?  Results were mixed — the framework was necessary to achieve progress, but more is needed.

In more detail:  The RS-OSS Pilot Project

The Routing Security Open Source Software Pilot Project worked with a group of network operators already engaged in discussions with each other on the MANRS (Mutually Agreed Norms for Routing Security[3]).  In the MANRS discussions, a proposal had surfaced for creating a tool to check router configurations against the requirements of MANRS.

The RS-OSS project focused on the suggestion that had been surfaced, provided the organization and support to schedule meetings to discuss requirements, progress and next steps, and share information from the project (Slack channel, organizing and providing meeting notes, ensure a GitHub repository, etc).  

There was clear interest in the project, as evinced by the participation in the scheduled meetings, as well as the original proponent’s success in finding employer-supported time to code the initial prototype implementation of a solution to the identified problem.[4]  

This prototype was greeted with enthusiasm by other participants, as evidence that progress could be made in the problem space.  However, the pilot project did not succeed in moving beyond this phase — the prototyper had chosen a particular OSS network testing tool[5] on which to base the implementation, and that tool might or might not be the appropriate one to expand the code to address a larger set of practical applications of the tool.  The original developer didn’t have time to delve further into the project, and other project participants didn’t have the wherewithal to pick up where he left off.  Other, external, developers expressed interest in the project, but wanted to use it as an application of their own preferred tool[6] (necessitating a complete rewrite of the original, and targeting a slightly different set of requirements).  

In short — the pilot project was a clear illustration of the principle that,  absent a consistent base of coding resources available to incrementally progress the implementation along collaboratively agreed directions, no amount of discussion would move the project forward.

Key learnings from the RS-OSS pilot project

The pilot project component of the overall POSSIE project, which focused on taking an existing set of collaborating network operators with an identified tool need,  revealed one important lesson:  for success of collaborative open source software projects, an active organizer is necessary, but not sufficient.   A successful project must also have identified coding resources (either committed from participants, or provided by the platform) in order to make progress.

The results of the concurrent open source software survey also brought to light a second point to consider:  the selected pilot project (a software tool) was not operationally-critical to participating network operators, which inevitably reduced the availability of participants and resources.

That’s not to say that the pilot project was without effect.  It started from some observations from network operators, on a shared mailing list, that were literally going nowhere until the pilot project arrived to provide some organizational focus to the effort.  Some code was written, and a prototype created.




RS-OSS Project notes and detailed timeline

March, 2019

One MANRS participant commented on a MANRS mailing list that he wasn’t finding good OSS tools for his needs — abandonware, mostly.

A different MANRS participant suggested to the MANRS list that a router configuration validator tool could be built, OSS — there was zero follow up on the list.

April, 2019

Discussions began, out of band, to see about following up the validator tool idea.

The validator tool proponent pulled together a project plan (statement of work, possible validator tests to do)

Discussions (e-mail) with potential proponents of OSS, from the MANRS list.  Most were supportive of the idea, but expect to have zero cycles (of their own, or resources they manage).  

June, 2019

Some discussions in the corridors at NANOG.  Other base tools were proposed and discussed.

July, 2019

The main proponent did some work on the tool, as part of his dayjob external development.

The project organizer put out a call for participation in a meeting, to the MANRS list.  The aim is to get operator help in developing the specs and scoping for the project, or even possibly the existing OSS tools to do the work, before we start talking about serious coding resources.

Late July 2019

Had a call with the main proponent and folks attracted from the MANRS mailing list.  15 - 20 participants. Key takeaways were:

Following the call, and peoples’ expressed interests, a GitHub repo space was set up in the MANRS project, for the main proponent’s code.  A Slack workspace was established.

Early August 2019

The main proponent worked on getting corporate legal release for putting code in the GitHub repository.

September 26, 2019

The source code was posted on the MANRS GitHub repo.  

A third party shared a Mikrotik config dump so that the main proponents could continue the development.

The project organizer felt that relying uniquely on the original proponent was not a great way to get more people involved in the development.  Floated  “reveal” of the source code call.

November 2019

Had a call.  Made a plan.

December 2019

Had a call.  Made a plan, with a new tool (Batfish)

January 2020

Had smaller call.  Batfish proponents all over this.  Dump the Robot Framework stuff.  But, no cycles.  Anywhere.


Final conclusions

Ad hoc coding resources tend to be driven by their own motivations and timelines.  Which can be okay, but doesn’t lead to a coherent outcome.

To be successful, a collaborative open source project (or platform) must:


Full report available at 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.  

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:




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.


Image

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.

Image

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).

Image

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.

Image

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. 


Image

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.Image

Chart SurveyReview-6


Image

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.

Image

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. 

Image

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.


Image

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).

Image

Chart SurveyReview-11


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

Image

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.

Image

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.


Image

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.


Image

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).


Image

Chart SurveyReview-16


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


Image

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.

Image

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.

Image

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.


Image

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:


Image

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.

Image

Chart SurveyReview-22


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

Image

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.”


Image

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.

Image

Chart SurveyReview-25


Using OSS

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


Image

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:

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.


Image

Chart SurveyReview-27


Some of the “Other” remarks here included:



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. 


Image

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:

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:


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.

Image

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

 


Survey Mechanics and Full Results


Detailed Survey Report

The following sections outline the background and detailed results from the Operator Open Source Software Survey.  



Survey Mechanics

Starting from the premise that this was an information-gathering exercise, as opposed to a rigorous information science study, the questionnaire was set up to capture as much information as possible.  Respondents self-declared demographic information and were often asked to select “all that apply” for informational questions.  

The questionnaire was offered using Google Forms, not requiring personal identification of respondents.  The first choice respondents had to make was whether to fill out the “Individual Contributor” (IC) survey or the “Decision Maker” (DM).  Several questions overlapped, but it was logistically unwieldy to create one survey that would fit both.  It would have meant too many questions outright, several of which were not applicable to one or other group.  In fact, respondents to either form were invited to fill out the other, if applicable, but it’s not clear that anyone did.  

Advertising

Advertising of the survey project started with a lightning talk at NANOG 76 in Washington, DC, in June 2019.  People were pointed at the webpage, which said the survey was “coming soon”.   Subsequent advertising was limited to social media (my own, and then boosts from friends who are much more influential in social media space!), a brief talk at the RIPE Open Source WG in Rotterdam in October 2019, and a posting on the NANOG mailing list.

All advertisements pointed to the https://possie.techark.org website, which got 260 views in October and November, 180 of which included viewing the survey introduction/links page on the site.

Responses

With that, the survey ran from mid-October 2019 to the end of November 2019, and the final tally of responses exceeded project targets,[7] receiving a total of 48 responses:

Contrary to advice that no one would fill out a survey form without prizes being offered, no prize was offered.  From informal conversations, it seems that people were genuinely interested in the outcome of the survey, and therefore willing to contribute their thoughts.

(Potential) contexts or biases

Although the survey did not collect geographic information from respondents, it is clear from the identity of those who opted to share contact information that responses were collected from (at least) North America and Europe.

Respondents self-selected to provide answers, so it’s clear that all respondents have at least some interest in OSS for their environment.  The perspective shared can help paint a picture of what does and doesn’t work for such a population.  The collected responses don’t, however, provide detailed insight into why operators may not be interested in or think of OSS at all.  



Individual Contributor Survey Results

POSSIE Open Source Survey -- for individual contributors

This survey is gathering information about attractions and impediments to using, contributing to, and financially supporting Open Source Software.

There is a separate survey that is focused more particularly on OSS managers and corporate decision makers (URL was provided).  Please complete whichever is more applicable, or both if you feel comfortable wearing either hat.

Background

This section covers some simple demographics and calibrating questions about your context.

1. You are (please check all that apply)


34 responses.

Image

Chart IndividualContributor-1


2. Speaking for your own professional experience, you (check all that apply)


34 responses

Image

Chart IndividualContributor-2


3. The company that employs you, including self employment (check all that apply)


34 responses

Image

Chart IndividualContributor-3



Attractors

This section explores the general space of:  what makes Open Source Software attractive -- to use and/or contribute to.

Please note that the questions come in pairs -- asking about your experiences with specific projects, and then with OSS projects in general.


4. If you were interested in a particular OSS tool, and all other things being equal, which of the following would you consider significant attractions to using the OSS tool


34 responses

Image

Chart IndividualContributor-4


5. Which of the following describe your organization’s major attraction to using (existing) OSS tools? Select all that apply


34 responses

Image

Chart IndividualContributor-5


6. All other things being equal, what attracts you to contributing  to a specific OSS project (please select all that are most applicable)


34 responses

Image

Chart IndividualContributor-6



7. Your purpose(s) in contributing to OSS projects includes (please select all that apply)


32 responses

Image

Chart IndividualContributor-7


Impediments

This section explores the general space of:  what impediments prevent or discourage using and/or contributing to Open Source Software.

Please note that the questions come in pairs -- asking about your experiences with specific projects, and then with OSS projects in general.


8. If you were interested in a particular OSS tool, and all other things being equal, which of the following would you consider significant impediments to using the OSS tool


34 responses

Image

Chart IndividualContributor-8


9. Which of the following describe your major impediments to using (existing) OSS tools? Select all that apply


31 responses

Image

Chart IndividualContributor-9


10. If you were interested in a particular OSS project, and all other things being equal, which of the following would you consider significant impediments to contributing to the project (please select all that apply)


34 responses

Image

Chart IndividualContributor-10


11. What impediments do you face in contributing to OSS projects (please select all that apply)


33 responses

Image

Chart IndividualContributor-11


Requirements

This section explores any requirements  you or your organization has for engaging in OSS projects.

12. What licensing requirements does your organization have for using OSS (Please pick the option that most closely matches your situation)?


34 responses

Image

Chart IndividualContributor-12


13. What licensing requirements does your organization have for contributing code/coding resources to OSS (Please pick the option that most closely matches your situation)?


34 responses

Image

Chart IndividualContributor-13


14. What other (than licensing) requirements do you or your organization have for using OSS tools? These will be interpreted as impediments, or reasons not to use OSS, if the requirements can’t be met (Please select all that apply)


34 responses

Image

Chart IndividualContributor-14


15. What other requirements do you or your organization have for contributing to OSS projects (select all that apply)


32 responses

Image

Chart IndividualContributor-15


Experiences

This section explores your, and your organization's, experiences in using and contributing to open source software.

16. Overall, which of the following best describe your experience in contributing to OSS projects (please select all that you feel strongly about)


34 responses

Image

Chart IndividualContributor-16


17. My experience in using OSS is best described by the following (please select all that are generally applicable)


34 responses

Image

Chart IndividualContributor-17


OSS in the Organizational Context

This section explores how OSS fits in to your organization's business workflow.

18. There is internal coordination at your organization to (please select all that apply)


16 responses

Image

Chart IndividualContributor-18


OSS Project Gaps

This section probes the types of OSS projects of interest to you/your organization that  you feel are currently underrepresented in the OSS landscape.

19. What problem areas are you interested in seeing addressed by (as yet non-extant) open source software (check all that apply)


33 responses

Image

Chart IndividualContributor-19


20.  Which of the following could solve an operations-critical problem for you today, if you could get an OSS package for it


33 responses

Image

Chart IndividualContributor-20


21. Which of the following would you be interested in contributing to build


34 responses

Image

Chart IndividualContributor-21


Composite views of Individual Contributor Perceptions of Gaps, Critical Gaps, and WIllingness to contribute

Image

Chart IndividualContributor-22


Image

Chart IndividualContributor-23


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

 



Decision Maker Survey Results

POSSIE Open Source Survey -- for OSS decision makers

This survey is gathering information about attractions and impediments to using, contributing to, and financially supporting Open Source Software.

There is a separate survey that is focused more particularly on individual contributors to OSS  (URL was provided).  Please complete whichever is more applicable, or both if you feel comfortable wearing either hat.

Background

This section covers some simple demographics and calibrating questions about your context.

1. You are (please check all that apply)


14 responses

Image

Chart DecisionMaker-1


2. Speaking for your own professional experience in managing technical resources/software implementation (check all that apply)


14 responses

Image

Chart DecisionMaker-2


3. Speaking for your own professional experience, how often do you use open source software in your infrastructure for each of the following functions?

Functions:


Rating for each function (choice):

14 responses

Image

Chart DecisionMaker-3


4. The company that employs you, including self employment (check all that apply)


14 responses

Image

Chart DecisionMaker-4


Attractors

This section explores the general space of:  what makes Open Source Software attractive -- to use, contribute to, and/or support financially.

Please note that the questions come in pairs -- asking about your experiences with specific projects, and then with OSS projects in general.


5. If you were interested in a particular OSS tool, and all other things being equal, which of the following would you consider significant attractions to using the OSS tool


14 responses

Image

Chart DecisionMaker-5


6. Which of the following describe your organization’s major attraction to using (existing) OSS tools? Select all that apply


14 responses

Image

Chart DecisionMaker-6


7. All other things being equal, what attracts you to contributing engineering time to a specific OSS project (please select all that are most applicable)


14 responses

Image

Chart DecisionMaker-7


8. The organization’s purpose(s) in contributing engineering time to OSS projects includes (please select all that apply)


14 responses

Image

Chart DecisionMaker-8


9. The organization has provided financial support to specific OSS development projects/platforms because (please select all that apply)


13 responses

Image

Chart DecisionMaker-9


10. The organization has generally provided financial support to OSS development projects/platforms because (please select all that apply)


12 responses

Image

Chart DecisionMaker-10


Impediments

This section explores the general space of:  what impediments prevent or discourage using, contributing to, and/or providing financial support to Open Source Software.

Please note that the questions come in pairs -- asking about your experiences with specific projects, and then with OSS projects in general.


11. If you were interested in a particular OSS tool, and all other things being equal, which of the following would you consider significant impediments to using the OSS tool


14 responses

Image

Chart DecisionMaker-11



12. Which of the following describe your major impediments to using (existing) OSS tools? Select all that apply


14 responses

Image

Chart DecisionMaker-12


13. If you were interested in a particular OSS project, and all other things being equal, which of the following would you consider significant impediments to contributing staff time to the project (please select all that apply)


14 responses

Image

Chart DecisionMaker-13


14. What impediments do you face in contributing engineering resources to OSS projects (please select all that apply)


14 responses

Image

Chart DecisionMaker-14


15. Your decision not to (financially) support a particular OSS project is based on (select all that apply)


12 responses

Image

Chart DecisionMaker-15


16. You don’t support OSS (financially), in general, because (please select all that apply)


10 responses

Image

Chart DecisionMaker-16


Requirements

This section explores any requirements your organization has for engaging in OSS projects.


17.  What licensing requirements does your organization have for using OSS (Please pick the option that most closely matches your situation)?


14 responses

Image

Chart DecisionMaker-17


18. What licensing requirements does your organization have for contributing code/coding resources to OSS (Please pick the option that most closely matches your situation)?


14 responses

Image

Chart DecisionMaker-18


19.  What other (than licensing) requirements does your organization have for using OSS tools? These will be interpreted as impediments, or reasons not to use OSS, if the requirements can’t be met (Please select all that apply)


13 responses

Image

Chart DecisionMaker-19


20. What other requirements does your organization have for contributing coding resources to OSS projects (select all that apply)


14 responses

Image

Chart DecisionMaker-20


Experiences

This section explores your, and your organization's, experiences in using and contributing to open source software.


21. Overall, which of the following best describe your experience in contributing staff resources and/or money to OSS projects (please select all that you feel strongly about)


14 responses

Image

Chart DecisionMaker-21


22.  In supporting OSS projects, which of the following best describe your organization’s experiences (please select all that are generally applicable)


13 responses

Image

Chart DecisionMaker-22


23.  My organization’s experience in using OSS is best described by the following (please select all that are generally applicable)


12 responses

Image

Chart DecisionMaker-23


OSS in the Organizational Context

This section explores how OSS fits in to your organization's business workflow.


24.  There is internal coordination at your organization to (please select all that apply)


12 responses

Image

Chart DecisionMaker-24


OSS Project Gaps

This section probes the types of OSS projects of interest to you/your organization that  you feel are currently underrepresented in the OSS landscape.


25. What problem areas are you interested in seeing addressed by (as yet non-extant) open source software (check all that apply)


14 responses

Image

Chart DecisionMaker-25


26.  Which of the following could solve an operations-critical problem for you today, if you could get an OSS package for it. 

(Single choice allowed)


14 responses

Image

Chart DecisionMaker-26


27.  Which of the following would you be interested in supporting (staff resources and or finances) to build


13 responses

Image

Chart DecisionMaker-27



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

 






Leslie Daigle

December 2020

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



[1] https://inform.tmforum.org/features-and-analysis/2015/09/three-reasons-why-open-source-software-is-good-for-network-operators/

[2] https://www.lfnetworking.org/ June 2020, asserts: “9 of 10 Top open source networking projects are hosted at The Linux Foundation; 10 largest

Networking vendors are active Linux Foundation members”

[3] https://www.manrs.org/

[4] https://github.com/manrs-tools/MANRS-validator

[5] Robot Framework — https://robotframework.org/

[6] Batfish — https://www.batfish.org/

[7] The project target was 12 - 20 responses, total.