In the research Kohsuke, Tracy, and I did in the development of the Continuous Delivery 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 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 and Outreachy, 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.