bproffitt commented on code in PR #216: URL: https://github.com/apache/comdev-site/pull/216#discussion_r2658912629
########## source/companies/_index.md: ########## @@ -0,0 +1,61 @@ +--- +title: Companies and Open Source +url: /companies/ +tags: ["companies", "business", "navigation"] +--- + +# Companies and Open Source + +All modern digital infrastructure is dependent on open source software. +Companies must think strategically about how they will engage with the +open source projects on which they rely in order to ensure +sustainability, and influence the direction of these projects for the +benefit of their customers. + +## [Benefits to Companies](/companies/benefits.html) + +Active participation in open source projects provides significant strategic and operational benefits to companies, from talent acquisition to technology innovation and market positioning. + + +## Ways to contribute + +There are three primary ways that companies can engage with ASF +projects. Each has costs and benefits that should be carefully +considered. + +<div class="row"> + <!-- Employ --> + <div class="col-md-4"> + +### [Employ Contributors](/companies/employ.html) + +[](/companies/employ.html) + +The most impactful way companies support open source is by employing developers and other professionals who contribute to projects. This includes not just code contributions, but documentation, community management, testing, design, and advocacy work. + </div><!-- End Employ --> + Review Comment: Obviously there are different modes in which ICs can get paid to work with open source projects, but we need to remember the audience for this set of documents. My point was addressing "Employee (prety much always by definitiion) has a non-compete agreemeent and cannot cooperate with other stakeholders," which is one of the biggest problems I see when talking to companies about working with open source. Going through every single permutation of how a company can interface with a project is, of course, a choice, but I believe it to be overkill. How an employee or a contractor interfaces with a project is the fundamentally the same for a company. There's just different legal structures setting up the rules. But that is just getting buried in the weeds. We should be aiming this document to outline the greater principles of collaboration in open source, and the benefits of that collaboration, not trying to figure out all the tactical expressions of what that collaboration looks like. ########## source/companies/_index.md: ########## @@ -0,0 +1,61 @@ +--- +title: Companies and Open Source +url: /companies/ +tags: ["companies", "business", "navigation"] +--- + +# Companies and Open Source + +All modern digital infrastructure is dependent on open source software. +Companies must think strategically about how they will engage with the +open source projects on which they rely in order to ensure +sustainability, and influence the direction of these projects for the +benefit of their customers. + +## [Benefits to Companies](/companies/benefits.html) + +Active participation in open source projects provides significant strategic and operational benefits to companies, from talent acquisition to technology innovation and market positioning. + + +## Ways to contribute + +There are three primary ways that companies can engage with ASF +projects. Each has costs and benefits that should be carefully +considered. + +<div class="row"> + <!-- Employ --> + <div class="col-md-4"> + +### [Employ Contributors](/companies/employ.html) + +[](/companies/employ.html) + +The most impactful way companies support open source is by employing developers and other professionals who contribute to projects. This includes not just code contributions, but documentation, community management, testing, design, and advocacy work. + </div><!-- End Employ --> + Review Comment: Obviously there are different modes in which ICs can get paid to work with open source projects, but we need to remember the audience for this set of documents. My point was addressing "Employee (prety much always by definitiion) has a non-compete agreemeent and cannot cooperate with other stakeholders," which is one of the biggest problems I see when talking to companies about working with open source. Going through every single permutation of how a company can interface with a project is, of course, a choice, but I believe it to be overkill. How an employee or a contractor interfaces with a project is the fundamentally the same for a company. There's just different legal structures setting up the rules. But that is just getting buried in the weeds. We should be aiming this document to outline the greater principles of collaboration in open source, and the benefits of that collaboration, not trying to figure out all the tactical expressions of what that collaboration looks like. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
