rtyler
/
brokenco.de
1
0
Fork 0
Code Pull Requests Releases Activity

Pay people damnit

This commit is contained in:
R Tyler Croy 2019-04-01 07:49:45 -07:00
parent f5cb35df7e
commit f3dddc1258
No known key found for this signature in database
GPG Key ID: E5C92681BEF6CEA2
2 changed files with 66 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
_posts/2019-03-28-scribd-core-platform.md
View File

@ -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.

65
_posts/2019-04-01-we-dont-pay-coders.md Normal file
View File

@ -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.