When we say “professional software team”, we’re typically referring to a team building software within an enterprise. Enterprise is kind of a silly IT word, or entrepreneurship business word; it means a company, and often times like a larger company. Again, I’ve spent the last 20 years in and around open source, so I know one of the beautiful things about open source is that it’s accessible to all different kinds of audiences.

If you’re an indie developer – I mean, I started working with open source, getting involved in open source when I was a student. There’s individual entrepreneurs kind of picking up raw open source and building with it… It’s awesome; it’s part of the beauty of the whole thing.

There’s also big teams inside of mega-corps that are building with open source as well, and those different audiences have different needs in and around the software that they’re using. When I’m doing a side project on the weekend, kind of cobbling together some open source components to sort of scratch my own itch, for sure I do not need an enterprise support contract, I’m not super-focused on intellectual property documentation for this thing that’s only ever gonna live on my laptop and never go anywhere. But when you have a team at a financial services company, or a healthcare company, or an industrial company, and they’re building the core software that powers those businesses, and in 2018 for sure they are building that with open source software, they would love to have some additional guarantees around that software.

So the open source software, by the open source definition, gives them a bunch of capabilities right off the bat for software that’s under an open source license. They can access the source code, they can change it, as long as they adhere with the different requirements for what they need to do if they redistribute it… But the open source license doesn’t give you somebody who’s on the hook to make sure that security vulnerabilities that arise will be dealt with in a timely way; it doesn’t give you any certification around the licensing of all the components of the software that you find that are connected to that, or that are dependencies of that… And it doesn’t give you any kinds of assurances about what’s gonna happen with the software in the future - is somebody gonna keep caring for it, and taking care of this essentially living organism that the software projects need to be, as the world evolves over time?

[ ] Those are the things that we think that professional teams need, that not all open source developers need, but professional teams do need it, and as a result, they’re willing to pay for it. One of the things we’ve done in the Tidelift context is verify that by talking to a lot of those organizations, surveying a bunch of those organizations; we shared the results of a broad survey we did this year that said something like more than 80% of professional software teams were very interested in paying for those kinds of assurances around the open source software that they use.