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.

I guess this is why they call me Professor.

Gender and code

Fardad notes that 70% of the “computer science” students in Iran are women.

Here’s the thing: in Iran, they don’t talk about programming as science. They talk about it as art. Programming classes sit in the arts departments.

Woman are culturally drawn to the arts. Is it really that simple? Probably not — but I’ve heard worse theories.

Gender and code

Matt states the central dilemma for professors.

An excerpt from Matt Jadud’s latest post:

“Perhaps I’m wrong in this—gregdek or another POSSE participant will correct me if I am—but digging in and playing in the sandbox matters. And if I am going to do that, it is going to take time to get involved, and I will want to sustain that activity over the coming 3-5 years at the least. Any project I do on that timeframe, that absorbs a significant amount of my energies, needs to be acknowledged by my institution as having value. It is true that I could just contribute. I could continue to teach without integrating open source, and do my research on things completely unrelated. I can strive to be an excellent husband and father, and … stop sleeping and eating. Ultimately, for me to take part in this, I suspect it must count towards my professional development at the College in a meaningful way.”

No, Matt, you’re not wrong at all. Chris and Dave have been so successful precisely because they have become enmeshed in their communities as you describe.

Now, I happen to know that you’ve got research going on that lends itself really well to community work. If you can derive value by building community around *your* project — and if the lessons you learn at POSSE and in subsequent participation in large projects are the basis of that value — then you’ve got your sales pitch built in.

That’s the thing: for professors to be able to take the time required to build competencies in open source development, we must arm the professors with persuasive arguments. I’m hoping that POSSE will be a big piece of that puzzle.

Matt states the central dilemma for professors.

POSSE, Day One

Some observations about POSSE Day One, in no particular order.

* * *

Dave Humphrey and Chris Tyler are really awesome at what they do. It’s no accident that they are leading the pack when it comes to teaching students about open source development.

* * *

When selling POSSE to various professors, it’s not necessarily important to sell the open source idea. If the professor is excited about open source, that’s great, but the big point is that open source is a means to an end, and that end is “teaching students to work in a big codebase”.

This is not a purely theoretical concern; it’s a real problem, and it is frustrating to industry. Even Microsoft has this problem. When students don’t learn how to be “effectively lost” in a large codebase, they have a hard time fitting into the workplace.

We have the solution to this problem. It requires professors to do more work than they’re accustomed to. Can we find the professors who are willing to do that work, and give them the tools they need to do that work? That’s the 64 dollar question.

* * *

Matt Jadud just introduced us to the idea of legitimate peripheral participation — a notion articulated by educational theorist and practitioner Etienne Wenger.

It’s funny: I’ve been going around preaching this exact message, without ever having had the “proper” words for it. I talk about “on-ramp” projects every chance I get as a way to build the contributor base, and I am delighted to discover that there’s actual research that supports my experience and assertions.

Which, by the way, is crucial as we wade into the world of academia. I may have a reasonable amount of street cred in the open source world, but in the world of academia, I’m a college dropout and a nobody. In academia, appeal to authority reigns supreme. When I can make a point, and then point to personal experience to support that point, and then carry in an armload of reference materials to further support that point, then I feel like I’ve got a much better chance to be heard.

* * *

POSSE is a great idea for computer science professors — but it might be an even better idea for technical writing professors. I’ll definitely need to look into this.

* * *

Quote of the day from The Mel (the Biblical paraphrase is mine): “Whosoever asketh for help, verily they ought offer to document that help. And whosoever offers help, they ought require the help to be documented. Thus do newbies become contributors, rather than annoyances.” Amen.

POSSE, Day One