Sumana Harihareswara

Sometimes different participant groups want different project velocities and rhythms. That’s cadence shear. Like when:

• Most of your team is volunteer, but there’s a Google Summer of Code intern who’s working 35-40 hours per week for 3 months, and who needs faster turnaround on code reviews.
• Some of your contributors are tied to the release cycle for a related organization/project (such as Debian releases), but some are not.
• A few different companies, nonprofits, government agencies, or academic teams are maintaining and improving a tool together – but one of them is working way slower or way faster than everyone else.

In general, cadence shear is a problem where different subsets of the team are attuned to different deadlines, or have different levels of urgency for project progress.

This is a problem of success. Congratulations: your open source project includes contributors with genuinely different incentives and from genuinely different contexts!

Let’s talk about some of the participant configurations that you see in this situation – paid plus volunteers, volunteers plus time-limited paid, paid teams in a consortium, and volunteers with disparate deadline affiliations – and some approaches to learning and addressing everyone’s expectations.