I guess this is why they call me Professor.
This, and the elbow patches on my jacket. And the pipe. (It’s certainly not because of any earned credentials of any kind, that’s for sure.)
I’ve been reflecting on POSSE all weekend now. It was pretty insanely great, and I think that we provided a lot of value for the professors who attended.
Once again, though, as so often happens whenever I’m fortunate enough to assemble really smart people — I learned way more than I taught. And I mean, way, way, way more.
When I started as “the community guy” at Red Hat almost five years ago, the job was perceived as “the guy in marketing who keeps the LUGs happy”. The reason I took the job was because I saw opportunities to do a lot more than that. We’d just made the Fedora/RHEL split, with the promise that Fedora would be developed in partnership with the open source community — but we weren’t really delivering on the “partnership” side of that promise. The frustrating thing was that we had a ton of community support, but we weren’t exactly putting it to good use.
So a lot of what I did in those early days, I did by feel. I spent a lot of talking talking to Elliot Lee and Seth Vidal and Karsten Wade and Jef Spaleta and many others, figuring out exactly how to give real responsibilities to our nascent Fedora community — or just as frequently, how to take the legitimate work they were already doing and fit it into the ever-growing Fedora puzzle. Thus were born the Fedora Infrastructure team, the Fedora Extras Steering Committee, the Fedora Documentation team, the Fedora Ambassadors team, and ultimately, the Fedora Board.
As Fedora expanded, my understanding of how community works expanded with it. I quickly discovered that for some tasks, there was no substitute for an experienced Red Hat engineer. For most tasks, though — the great majority, in fact, more than I ever suspected — entrusting those tasks to passionate community members was actually far more likely to get those tasks completed in a timely and effective manner. Thus, Fedora’s community work became tightly focused on making it easier for community to perform these tasks that gave them such enjoyment and fulfillment and purpose. It also became important to discern which tasks were good community tasks, and which were not, so that we could provide satisfying experiences to our volunteer base, rather than frustrating ones.
I never had a name for how all this stuff worked. I never studied any theory. I had no language to discuss these ideas, other than the language I made up or borrowed. I talked about “infrastructure of participation” and “on-ramp projects” and “pulling innovation from the edges” and “the apprenticeship of open source” and whatever crackpot terminology that seemed to sort of make sense. That’s the thing: I just did what made sense to me, and whatever seemed most useful at the time.
So last week, when Cam Seay and Matt Jadud starting nodding their heads and talking about Zones of Proximal Development and Legitimate Peripheral Participation and Communities of Practice and referenced the works of Etienne Wenger and Lev Vygotsky, something clicked, way deep down.
Building community is fundamentally an act of teaching.
I suppose that I shouldn’t be shocked at finding an entire pedagogy around what it is that we do. I mean, I am shocked, of course — but I shouldn’t be. Because while it may be true that the internet makes it easy to build communities of practice at a previously unimaginable scale, it’s also true that people have been enmeshed in communities of practice, of one kind or another, for thousands of years. In the Red Hat Brand Book, we have a clever saying, and I hope it catches on: “open source isn’t a new idea; it’s the oldest idea.”
In other words: there’s nothing magical about community management. When I say “infrastructure of participation,” I’m actually talking about a specific form of instructional scaffolding. When I say “on-ramp projects,” what I really mean is legitimate peripheral participation. And when any of us say “the open source community”, we are talking about perhaps the largest and best example of a global community of practice.
Maybe there’s something to be said for the Art of Community — but for earnest practitioners, it’s far more useful to study the Science of Community. And those books have already been written; I just never knew where to look for them before.
Here are the books I’m reading now, and if you are responsible for building communities of practice, you should be reading them too:
Communities of Practice: Learning, Meaning and Identity. Etenne Wenger, Cambridge University Press.
Situated Learning: Legitimate Peripheral Participation. Jean Lave and Etienne Wenger, Cambridge University Press.
Cultivating Communities of Practice. Etienne Wenger, Richard McDermott and William M. Snyder, Harvard Business School Press.