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:
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:
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.
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
There are 3 key targeted takeaway reports from this project:
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.
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.
Chart KeyFindings-1
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
Chart KeyFindings-2
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.
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.
Chart PitchingOSS-1
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.
Chart PitchingOSS-2
Full report available at https://possie.techark.org
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.
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.
Chart OSSAppeal-1
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.
Chart OSSAppeal-2
Full report available at https://possie.techark.org
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.
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.
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.
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.
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
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.
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
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
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
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
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
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
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
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
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:
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
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
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
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:
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:
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
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.
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.
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
The following sections outline the background and detailed results from the Operator Open Source Software Survey.
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 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.
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.
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
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.
This section covers some simple demographics and calibrating questions about your context.
34 responses.
Chart IndividualContributor-1
34 responses
Chart IndividualContributor-2
34 responses
Chart IndividualContributor-3
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.
34 responses
Chart IndividualContributor-4
34 responses
Chart IndividualContributor-5
34 responses
Chart IndividualContributor-6
32 responses
Chart IndividualContributor-7
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.
34 responses
Chart IndividualContributor-8
31 responses
Chart IndividualContributor-9
34 responses
Chart IndividualContributor-10
33 responses
Chart IndividualContributor-11
This section explores any requirements you or your organization has for engaging in OSS projects.
34 responses
Chart IndividualContributor-12
34 responses
Chart IndividualContributor-13
34 responses
Chart IndividualContributor-14
32 responses
Chart IndividualContributor-15
This section explores your, and your organization's, experiences in using and contributing to open source software.
34 responses
Chart IndividualContributor-16
34 responses
Chart IndividualContributor-17
This section explores how OSS fits in to your organization's business workflow.
16 responses
Chart IndividualContributor-18
This section probes the types of OSS projects of interest to you/your organization that you feel are currently underrepresented in the OSS landscape.
33 responses
Chart IndividualContributor-19
33 responses
Chart IndividualContributor-20
34 responses
Chart IndividualContributor-21
Chart IndividualContributor-22
Chart IndividualContributor-23
Full report available at https://possie.techark.org
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.
This section covers some simple demographics and calibrating questions about your context.
14 responses
Chart DecisionMaker-1
14 responses
Chart DecisionMaker-2
Functions:
Rating for each function (choice):
14 responses
Chart DecisionMaker-3
14 responses
Chart DecisionMaker-4
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.
14 responses
Chart DecisionMaker-5
14 responses
Chart DecisionMaker-6
14 responses
Chart DecisionMaker-7
14 responses
Chart DecisionMaker-8
13 responses
Chart DecisionMaker-9
12 responses
Chart DecisionMaker-10
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.
14 responses
Chart DecisionMaker-11
14 responses
Chart DecisionMaker-12
14 responses
Chart DecisionMaker-13
14 responses
Chart DecisionMaker-14
12 responses
Chart DecisionMaker-15
10 responses
Chart DecisionMaker-16
This section explores any requirements your organization has for engaging in OSS projects.
14 responses
Chart DecisionMaker-17
14 responses
Chart DecisionMaker-18
13 responses
Chart DecisionMaker-19
14 responses
Chart DecisionMaker-20
This section explores your, and your organization's, experiences in using and contributing to open source software.
14 responses
Chart DecisionMaker-21
13 responses
Chart DecisionMaker-22
12 responses
Chart DecisionMaker-23
This section explores how OSS fits in to your organization's business workflow.
12 responses
Chart DecisionMaker-24
This section probes the types of OSS projects of interest to you/your organization that you feel are currently underrepresented in the OSS landscape.
14 responses
Chart DecisionMaker-25
(Single choice allowed)
14 responses
Chart DecisionMaker-26
13 responses
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.