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.
Using OSS
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:
- “The ‘toll-free’ and ‘24×7’ are unnecessary qualifiers. My organization requires a service/support contract, the specifics of which are important but not critical. A phone number of any kind with any hours is what is needed.”
- “For some critical components (e.g. software-defined storage), it’s pretty important to have SOME paid support option to get us out of a potential mess. Doesn’t need to be strictly 24×7, and certainly doesn’t have to be toll-free.”
- “Want someone else to blame when stuff breaks”
- “Approved by Information Security”
- “required some form of paid support email w/limited/surcharged phone is fine”
- “Reasonable support availability, doesn’t have to be 24×7, but needs to be more than e-mail”
- “Support, only if highly critical tool (e.g. database)”
Contributing to OSS
Respondents were not very fussy about requirements for contributing to OSS projects. Very clearly, large project platforms are not perceived as a requirement for engaging with OSS projects. Again, the responses from Individual Contributors did diverge from those of Decision Makers, insofar as Individual Contributors were much more likely to perceive “no non-licensing requirements” for contributing to OSS, while Decision Makers clearly wanted to see a project with active contribution and clear, published governance rules.
Some of the “Other” remarks here included:
- “We must be able to exclude liability for our contributions”
- “Must be a clear, comprehensible business benefit to contribute rather than fork, maintain local patches, develop locally, or buy a proprietary solution.”
Looking for feedback!
What can we make clearer in this part of the report? What other questions does this bring to mind that we should answer?
Send comments in mail to: ldaigle@thinkingcat.com