potiuk commented on code in PR #216: URL: https://github.com/apache/comdev-site/pull/216#discussion_r2652713915
########## source/companies/benefits.md: ########## @@ -0,0 +1,65 @@ +--- +title: Benefits of Open Source Participation +url: /companies/benefits.html +tags: ["companies", "benefits", "business value"] +--- + +# Benefits of ASF Participation + +Companies that actively participate in ASF projects realize significant +strategic and operational advantages that extend far beyond cost savings. Review Comment: > ...advantages that extend far beyond cost savings. Key among these is the ability to influence the project's trajectory through employees who have earned committer status. It's important to think strategically... I personally think this is quite against the spirit of the ASF to suggest that this way. Wth the Apache Way, the whole idea is that individuals act on their own behalf, and with the direction of the project not being "skewed" unnecessarily by the fact that the company employs committers and PMC members. Of course that's a bit of idealistic approach to think that employees interests are neglected by their employees - that would be insane to think tihs is happening. However I think in this case this work in a bit of a different direction (Ideally - according to how ASF model of influence on the project should work). I think by employing committers and PMC members, what company achieves is not "influencing the trajectory" directly, but making PMC members and committers incentives more aligned with the company interests. There is a subtle difference there - as a company management you should not be able to "tell" those PMC members what to approve and what to not approve, you can tell them what is the overall direction the company is going and let those PMC members and committers decide what they do - whether it aligns with this direction, or not. I think "influence the trajectory" might be understood more of "tell employees what changes they should implement and release" - which of course happens. But it has nothing to do with what "committer" status gives. Committers can "approve" things. Anyone can implement them. What you implement and submit as a PR to the project (as employee) is logically different thing that what you "accept" as a "committer". Your employee can tell you to "work on something" but they cannot tell you to "get something merged" - not formally and legally according to the ICLA every committer and PMC member signs. -- 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]
