From f3dddc12587dc86b0c3b52f6faa1a24a51b5ae6e Mon Sep 17 00:00:00 2001 From: "R. Tyler Croy" Date: Mon, 1 Apr 2019 07:49:45 -0700 Subject: [PATCH] Pay people damnit --- _posts/2019-03-28-scribd-core-platform.md | 2 +- _posts/2019-04-01-we-dont-pay-coders.md | 65 +++++++++++++++++++++++ 2 files changed, 66 insertions(+), 1 deletion(-) create mode 100644 _posts/2019-04-01-we-dont-pay-coders.md diff --git a/_posts/2019-03-28-scribd-core-platform.md b/_posts/2019-03-28-scribd-core-platform.md index c1edbde..9dafe11 100644 --- a/_posts/2019-03-28-scribd-core-platform.md +++ b/_posts/2019-03-28-scribd-core-platform.md @@ -34,7 +34,7 @@ tooling including tracing, discovery, and that sort of thing. Like any internally focused team, Core Platform is also responsible for education and evangelism of our work within engineering, whether we're writing thorough documentation for the systems we build, hosting internal workshops, -and providing implementation support to our peers across engineering. +or providing implementation support to our peers across engineering. This is where I'm excited to utilize some of the skills I had honed over the past three years. diff --git a/_posts/2019-04-01-we-dont-pay-coders.md b/_posts/2019-04-01-we-dont-pay-coders.md new file mode 100644 index 0000000..1b4c00a --- /dev/null +++ b/_posts/2019-04-01-we-dont-pay-coders.md @@ -0,0 +1,65 @@ +--- +layout: post +title: "We don't pay for coding" +tags: +- opinion +- opensource +--- + +In the research [Kohsuke](https://kohsuke.org), +[Tracy](https://tracymiranda.com/), and I did in the development of the +[Continuous Delivery Foundation](https://cd.foundation), we learned a _lot_ +about how other free and open source foundations operate. I know more now than +I had ever before about how the Eclipse Foundation, Apache Software Foundation, +and numerous other LF-based foundations operate. One recurring theme which has +come up has been the aversion to paying people to contribute code directly to +the open source project. While not a universal pattern, looking to the FreeBSD +Foundation which regularly issues grants for FreeBSD development, I am +perplexed by this mindset in various foundations. + +Perhaps the most oft cited reason for this rule is that it creates what I would +characterize as "people problems." Concerns about reducing incentives for +volunteer contributors, creating conflicts of interest, and a number of the +other predictable but avoidable problems between people when money becomes +involved. Another very understandable issue is one of budget, people-time is +very expensive and foundations are not typically flush with cash. While I +understand the concerns around directly funding development, I cannot shake the +feeling that this attitude is simply **wrong**. + +Leaving the coding to be done by volunteers doesn't _democratize_ anything in +my opinion. Instead, I believe it ensures that external corporate actors in the +ecosystem, which pay for development time, will have an outsized impact on the +roadmap and progress of any project in a given foundation. If we can assume for +the moment that the technical oversight committee, or governing board has the +growth and success of the project in mind, wouldn't they be much better suited +to fund development in key areas of the project? + +Looking at the Jenkins security team as an example, I am **extremely** grateful +that [CloudBees](https://cloudbees.com) has been such a prominent supporter and +investor in the development of new security fixes and research. Without +CloudBees funding that development, Jenkins be severely behind in triaging and +_fixing_ outstanding security issues affecting the 200,000+ Jenkins +installations in the world. But is that fair, is that appropriate? I don't +believe so. What would be much more reasonable to me, would be for the pooled +resources of the many organizations who believe in Continuous Delivery and rely +on Jenkins as a part of that story, to improve a crucial area of shared +interest like Jenkins security. + +Overly relying on volunteer efforts for code contributions also negatively +affects the diversity of open source projects. Setting corporate-funded +development aside, limiting the contributor base to only those who have +significant amount of passion and a significant amount of surplus labor to +donate, ensures that the project will only be made up of a certain subsection +of the code-capable population. This is in part why I'm a strong believer in +stipends and funding programs like [Google Summer of +Code](https://summerofcode.withgoogle.com) and +[Outreachy](https://outreachy.org), both of which I have supported as best I +could within the Jenkins project. + + +As my opinions on the subject have evolved, were it strictly _my_ call on how +Jenkins' annual budget should be spent, I would ensure we were paying for code. +Once the infrastructure, key events, and advocacy materials had been covered, +whatever was left over would be directed into funding development in Jenkins. + +There is no purity of ideal that comes with free code.