There are several forms of OSS and it seems people often conflate them.
There is:
* "open source as a reference"
* "open source as a line item"
* "open source as a funnel"
It seems like our industry favors line item OSS. Personally, I think the other two are far more useful.
Line item OSS productizes a high-value project inside a company and releases it publicly for no charge. The goal of open sourcing is generally to steer the industry in a direction compatible with your company's architecture. Often times companies are trying to:
* Cultivate engineering talent trained on their architecture that they can hire in the future
* Increase maturity of their software stack by exposing it to environments outside their current architecture
* Recruit maintainers to drive down the cost of maintaining an internal pattern
* Cultivate an ecosystem of plugins and modules they can rely on for future engineering projects
* Cultivate good will in the developer community as a recruiting/dev-rel tactic
* etc.
Line-item OSS projects typically carry a high cost, they don't just become successful when you push to a public repository. These projects require devrel presence to meet 3rd party engineers where they are (conferences, blogs, documentation, branding, logos, news aggregator sites, etc.). They require maintainers to mentor 3rd party engineers through pull requests and issues. You have to navigate community building with codes of conduct, boards, foundations, etc. This all requires salaried employee's time. This high cost raises the bar for contributing to the commons: the return has to cover the salaried time spent on open sourcing the project. If the return doesn't cover your investment, ROI is negative and you're expecting companies to contribute for charity. What's worse is that failing on a line item OSS project often results in the opposite of what you want: a perception that your company is bad at OSS or not a great community participant. Every line item OSS project is a high-cost bet carrying risk to your reputation.
Open source as a reference, in contrast, is closer to publishing a conference paper. You describe how you are doing something, publish the source code as a reference, and call it a day. No community building. You don't commit to merging random PRs. You don't commit to fielding questions on issue trackers. It's a statement that what you are doing is working for you, that other engineers might benefit from similar patterns, and a jump start for motivated engineers to figure out how to apply the pattern themselves. You're contributing to the commons under a permissive license for the cost of a conference road show and a "cleanup" of the code to ensure you aren't leaking anything sensitive in your SCM history. I feel a lot more software would make it into the commons if we normalized this form of OSS.
"Open source as a funnel" is probably the most sustainable OSS model IMH(umble)O. "OSS funnel projects are associated with a vendor that sells services and products in that ecosystem. The services are particularly useful for companies building on top of OSS. If you are a small-ish org, every dependency you're bringing in is a pretty big risk. You have to have internal talent capable of maintaining the entire software stack. "OSS as a line item" and "OSS as a reference" do not give you any guarantees from the project. The maintainers aren't your employees and they owe you nothing. You often have no way to pay maintainers to solve your problems. A show stopper bug in those projects can bury your company. In contrast, "OSS as a funnel" has a vendor you can reach out to for consulting/contracting services to elastically scale out your engineering org for bugs in the stack. In the Node.js ecosystem, NearForm is a great example IMHO. They are maintainers on a pretty large catalogue of software (i.e. fastify). You can bring that into your architecture knowing that, if you end up blocked on a bug your team doesn't have the expertise to solve, you have a vendor you can reach out to and pay to solve your problem.
Sometimes line item OSS projects foster an ecosystem of vendors which in turn checks the OSS as a funnel box. For example, with GraphQL and React, you can't pay Facebook but someone out there will take your money to solve your problems.
I do consulting/contracting in the Node.js space and, when I bring modules into my client's architecture, having a vendor associated with the module is front-of-mind for me. I know I'm not leaving them with technical debt they have no way out of if something goes sideways. They always have me and they have a 3rd party vendor they can reach out to as well.
There is:
* "open source as a reference"
* "open source as a line item"
* "open source as a funnel"
It seems like our industry favors line item OSS. Personally, I think the other two are far more useful.
Line item OSS productizes a high-value project inside a company and releases it publicly for no charge. The goal of open sourcing is generally to steer the industry in a direction compatible with your company's architecture. Often times companies are trying to:
* Cultivate engineering talent trained on their architecture that they can hire in the future
* Increase maturity of their software stack by exposing it to environments outside their current architecture
* Recruit maintainers to drive down the cost of maintaining an internal pattern
* Cultivate an ecosystem of plugins and modules they can rely on for future engineering projects
* Cultivate good will in the developer community as a recruiting/dev-rel tactic
* etc.
Line-item OSS projects typically carry a high cost, they don't just become successful when you push to a public repository. These projects require devrel presence to meet 3rd party engineers where they are (conferences, blogs, documentation, branding, logos, news aggregator sites, etc.). They require maintainers to mentor 3rd party engineers through pull requests and issues. You have to navigate community building with codes of conduct, boards, foundations, etc. This all requires salaried employee's time. This high cost raises the bar for contributing to the commons: the return has to cover the salaried time spent on open sourcing the project. If the return doesn't cover your investment, ROI is negative and you're expecting companies to contribute for charity. What's worse is that failing on a line item OSS project often results in the opposite of what you want: a perception that your company is bad at OSS or not a great community participant. Every line item OSS project is a high-cost bet carrying risk to your reputation.
Open source as a reference, in contrast, is closer to publishing a conference paper. You describe how you are doing something, publish the source code as a reference, and call it a day. No community building. You don't commit to merging random PRs. You don't commit to fielding questions on issue trackers. It's a statement that what you are doing is working for you, that other engineers might benefit from similar patterns, and a jump start for motivated engineers to figure out how to apply the pattern themselves. You're contributing to the commons under a permissive license for the cost of a conference road show and a "cleanup" of the code to ensure you aren't leaking anything sensitive in your SCM history. I feel a lot more software would make it into the commons if we normalized this form of OSS.
"Open source as a funnel" is probably the most sustainable OSS model IMH(umble)O. "OSS funnel projects are associated with a vendor that sells services and products in that ecosystem. The services are particularly useful for companies building on top of OSS. If you are a small-ish org, every dependency you're bringing in is a pretty big risk. You have to have internal talent capable of maintaining the entire software stack. "OSS as a line item" and "OSS as a reference" do not give you any guarantees from the project. The maintainers aren't your employees and they owe you nothing. You often have no way to pay maintainers to solve your problems. A show stopper bug in those projects can bury your company. In contrast, "OSS as a funnel" has a vendor you can reach out to for consulting/contracting services to elastically scale out your engineering org for bugs in the stack. In the Node.js ecosystem, NearForm is a great example IMHO. They are maintainers on a pretty large catalogue of software (i.e. fastify). You can bring that into your architecture knowing that, if you end up blocked on a bug your team doesn't have the expertise to solve, you have a vendor you can reach out to and pay to solve your problem.
Sometimes line item OSS projects foster an ecosystem of vendors which in turn checks the OSS as a funnel box. For example, with GraphQL and React, you can't pay Facebook but someone out there will take your money to solve your problems.
I do consulting/contracting in the Node.js space and, when I bring modules into my client's architecture, having a vendor associated with the module is front-of-mind for me. I know I'm not leaving them with technical debt they have no way out of if something goes sideways. They always have me and they have a 3rd party vendor they can reach out to as well.