Technology, startups, programming, technical management and software architecture
How to manage casual contributors to open source projects
Try these strategies to better utilize contributions from your project's episodic volunteers.
The Missing Middle of Open Source
Why serious, maintainer-driven projects struggle to sustain themselves—and what it will take to fix it.
How to become an amazing contributor (to an open source project)
It's a busy morning here in New York City. My email inbox is full of pleasant surprises. The first is a patch for one of my open source projects. A second will appear this afternoon. A third should come late at night—or maybe tomorrow–from a new contributor. Alongside my day job, I contribute and manage open source projects. The number of projects I work on has grown from a couple of small tools to well over a dozen in the last three years. Open source has become a great way to learn new technology, experiment with modern software development practices, and, of course, meet other like-minded engineers. I find that seeing great contributors send working and tested code provides a unique feeling of accomplishment, as powerful as having many satisfied users of my own applications or strong revenues posted by the employer that pays my bills.
The Few, the Tired, the Open Source Coders
The open source movement runs on the heroic efforts of not enough people doing too much work. They need help.
Is Open Source Broken?
The movement to develop software applications and all manner of IT services through the open source model is fundamentally rooted in the notion of community contribution, but things have shifted.
Ten simple rules for helping newcomers become contributors to open projects
Citation: Sholler D, Steinmacher I, Ford D, Averick M, Hoye M, Wilson G (2019) Ten simple rules for helping newcomers become contributors to open projects. PLoS Comput Biol 15(9): e1007296. https://doi.org/10.1371/journal.pcbi.1007296
Home-Cooked Software and Barefoot Developers
The emerging golden age of home-cooked software, barefoot developers, and why the local-first community should help build it
Robot Pedantry, Human Empathy
Homebrew was the first open source project I’ve maintained where I’ve had to review and merge contributions from other users. Homebrew is also one of the most active community projects on GitHub with a consistently small team of maintainers (always under thirty in total, always under ten doing work every week). As a result I’ve had to figure out over the last twelve years how best to manage large numbers of contributions from users in pleasantly and efficiently for both maintainers and contributors.
Stop Mentoring First-Time Contributors
If you’re an open source maintainer lucky enough to have a significant number of contributors you need to learn to mentor efficiently. First timer issues are not the right good way to get people involved in your project nor mentoring individual first-time contributors. Instead, do things that help all of them.
Professional maintainers: a wake-up call
Open Source software runs the Internet, and by extension the economy. This is an undisputed fact about reality in 2021. And yet, the role of Open Source maintainer has failed to mature from a hobby into a proper profession.
Keep Your Friends Close — Open Tech Strategies | Blog
One of the insider secrets of free and open source software (FOSS) is that most of the rules a project uses on a day-to-day basis are not found in the software’s license. There are contribution guidelines, which are enforced by the project only taking contributions that meet them. There are codes of conduct, which are a condition of community participation. There are endorsements, official membership, a voice in setting the project roadmap, and all kinds of other benefits that attach to varying types of community participation. In each case, entirely external to the license, there are official rules and unwritten norms that govern how participants gain the benefits of joining the civic life of a project.
Open Source Resistance
A direct-action manifesto for maintainers keeping open source alive on company time.
Open Source Software and Corporate Influence — Andrew Lilley Brinker
Exploring how corporations gain power in open source projects, and how to build resilience to corporate capture.
Where Did Software Go Wrong? | Jesse Li
Software is broken, but it's not because of NPM, startups, AI, or venture capitalists. A deep dive into how we think about and produce code, and how our software systems reflect the manic state of the modern world.
How to set up a new Programme | The Commons Conservancy
So you are responsible for some ‘free and open’ project or effort that is in the public interest. This could be free software/open source, open hardware, open science, open content, etcetera. With open, we mean that you are sharing not just the final end result as something immutable, but you’ve made it part of the ‘Commons’ by explicitly allowing anyone to build and extend on what you’ve created. In legal terms this is normally done through a ’license’, and each incremental author actually needs to license his or her part. However, once different people start contributing, managing who can license what becomes cumbersome - especially if you need to make upgrades to a license. Mix in the need to collectively raise funds for promotion, development and maintenance, and you’ve just experienced why people that are involved with larger projects sometimes feel victim to their own success. None of this matters when a project is young, but as soon as it is about to outgrow the original creator it becomes urgent - there is a window of opportunity for quick and effective repair which slowly starts to close once you’ve passed a certain scale, The critical fase of scale up is where we aim to help out.