tag:world.hey.com,2005:/doctor_julz/feedJulz Friedman2021-04-18T16:59:34Ztag:world.hey.com,2005:World::Post/96352021-04-17T12:57:21Z2021-04-18T16:59:34ZThe weirdness (and wonderfulness) of the success of big open source, from an agile fan's perspective <div class="trix-content">
<div>It’s not how I’d write software. Hundreds of developers on one code base. Lots of proposal writing and design work before embarking on code. PR-based code review meaning it can take days - or longer - for a change to hit the main branch. Minimal pairing, no stand-ups. Long release cycles meaning the first real customer feedback on a change might be months after it (finally) lands in main.<br><br>It’s not how I’d write software.<br><br>And yet, and yet. It’s exactly how I do write software. And it’s an extremely successful way of writing software. Look at Kubernetes. Look at Knative. Look at any number of big multi-company open source projects built this way.<br><br>It’s not how I’d write software. And yet it’s how I do write software. And yet it’s a great way, if you want to build a project with (much) more than a two pizza team, if you want to build a big community of contributors, if you want to create a common platform that lots of companies can trust and use and build together, to build software. In fact, if you want those things, it might be the <strong>only </strong>realistic way to write software.<br><br>The paradox of big distributed open source. Almost everything I think I know - thought I knew, confidently - about how to write software: small teams, pairing, 100% TDD, stand-ups, a single prioritised backlog, an on-site customer, fast feedback loops, iteration, continuous delivery, is not how we build software in big distributed open source. And is not, I’m increasingly convinced, how we <em>should</em> build software in big distributed open source, at least where big contributor communities and shared multi-employer participation are a requirement.<br><br>I don’t have a conclusion. I’m still learning, I’m thinking out loud. I find the way the changing context invalidates some of my previously held assumptions about building software exciting and surprising - perhaps I shouldn’t: that’s what changing contexts are supposed to do. </div>
</div>
Julz Friedmandoctor_julz@hey.com