…when other people have already done it better than you. 🙂
I really need to learn more about everything that OpenHatch does. It looks like an especially useful tool, especially for professors. I met some OpenHatch folks at Innovation Philly, and just flat forgot about them — but it really does look like they’re doing a lot of stuff right. Way more comprehensive than a simple idea like studentbugs.org.
Maybe I need to head back to Philadelphia sometime soon and spend a day with them.
Reprinting this comment from my friend Badger, who read my blog post about the Open Textbook Act of 2009 and actually took me up on it:
“I wrote both my Senators. A staffer at Senator Burr’s office just telephoned me, thanking me for the email, telling me the bill has been referred to the Education Committee that Burr is a member of, they’ll be looking into this, and thanks again for the email. (I asked if the staffer knew if the Senator had an official position on the bill, and the staffer said not yet.) But the phone call was a nice surprise.”
Participatory democracy works, people. When you actually tell your senator that something matters, sometimes they even call you back to let you know how things are going — and sometimes they’re even on the committee that determines if that bill becomes law.
These things matter. Do a small thing, and sometimes it turns into a big thing.
Thanks, Badger.
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.
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.
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.
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.
People are starting to trickle in here at the POSSE hotel. Chris, his wife and kids have arrived, as have Matt and Christian, and Fardad, and Kent, and Dave. Mel is on her way from the airport as we speak, and Max is also on his way, after having called me from the wrong hotel, befuddled at finding no one there. Silly Max.
I’d told everyone to meet in the lobby at 5pm-ish for meet-and-greet, but sadly, I did not realize until too late that, here at Candlewood Suites, there is no lobby to speak of. So everyone will be re-convening at 6:15 to head off to our 6:30 dinner reservation.
Still no wireless in the POSSE classroom at Red Hat HQ. Chris tells me that mock for F11 is in shambles. In other words, the typical reasons for slight panic before such an event. Still, I’m excited to get POSSE underway, in what I hope will be the first of many POSSEs around the globe in the years to come.
People behave as they see others behave. If people on a mailing list are civil, then newcomers will try to be civil. If people on a mailing list are snippy, then newcomers will feel justified being snippy.
And if people submit patches to a mailing list, and those patches are treated well by the engineers who receive them, then newbies will be more comfortable submitting patches to that list.
In the past few months, we have seen two newcomers to the Spacewalk project: Joshua Roys of Georgia Tech Research Institute, and Maxim Burgerhout, sysadmin from parts unknown. (I hope they won’t mind being discussed in so public a way.) Let’s see how they joined up.
Maxim Burgerhout’s very first post to spacewalk-devel list, in April, was a patch (0). It was a simple patch to rhncfgcli_verify.py, which is part of Spacewalk’s built-in configuration management. Honestly, so many people use puppet and cfengine these days, I don’t expect many people to be using Spacewalk for configuration management. But its one advantage is that it is quite well-integrated, so it’s worth a look. Maxim is clearly a power user of the rhncfg functionality, but hacking code is only an occasional thing for him. In his words, “I usually spend my time being an sysadmin, so I hope I’m doing this ‘sending patch’ stuff the right way. ;-)” Which implies that this was Maxim’s first-ever patch sent to a mailing list! W00t! Since then he has submitted another couple of patches, and is thus a member in good standing of the Spacewalk team.
Joshua Roys, from Georgia Tech Research Institute, made his initial post to spacewalk-devel list in March 2009 with a simple patch fixing bootstrap scripts to retrieve a server cert using SSL (1). It wasn’t quite the right idea, as Jan Pazdziora gently pointed out, due to a (very common) chicken-and-egg problem with the cert.
Then in April, Joshua dug into a tricky issue with oracle-instantclient-selinux, for which Jan publicly thanked him (2).
On May 28th, Joshua posted the largest patch ever offered by a volunteer contributor to Spacewalk (3) — a massive undertaking, in Joshua’s words, “to make the life of government Information Assurance teams easier on Linux.” This patch, essentially a complete new feature, also came with detailed descriptions of the new functionality, including screen shots (4). He has followed it up with a few patches since, expanding the initial functionality.
Spacewalk is a daunting codebase. I know, because I was one of the original engineering managers for that codebase, and trying to dig back into it after four years is painful. Still, dig into it I shall, in the hopes of making it a little more accessible for the next guy.
Which makes it all the more impressive that Joshua was able to make such invasive changes to such a huge codebase. Why did he do it? Simple. He needed the functionality, so he wrote it, and he needed other people to support it, so he shared it.
I would argue that creating a strong “patch culture”, which the Spacewalk engineers did from the day they launched, is part of what is making such successes in Spacewalk possible now.
(0) https://www.redhat.com/archives/spacewalk-devel/2009-April/msg00029.html
(1) https://www.redhat.com/archives/spacewalk-devel/2009-March/msg00104.html
(2) https://www.redhat.com/archives/spacewalk-devel/2009-April/msg00088.html
(3) https://www.redhat.com/archives/spacewalk-devel/2009-May/msg00121.html
(4) http://www.stl.gtri.gatech.edu/jroys/
It’s been a while since I’ve posted anything substantive about what I’m doing these days, and given the week I’ve just had, I figured this was as good a time as any to catch folks up. Those of you that are interested, anyway.
Today I’ll focus on our shared quixotic attempt to change the way that computer science education works.
This is one of my big goals for the year, both personally and professionally. It all started with a simple premise: wouldn’t it be great if computer science programs around the world could learn computer science by actually *doing* computer science, and helping out the world in the process? Pretty cool idea, right? And also rather obvious, it would seem.
I quickly discovered that it wasn’t as obvious as all that. A big chunk of the last year of my life has been spent learning all about how kids study computer science in college.
In short: I’m not a fan.
On Thursday and Friday of last week, I was at Drexel University in Philadelphia, at the Softhum workshop — an NSF-funded workshop put together by the folks responsible for HFOSS.org. The “H” stands for Humanitarian; the mission of the HFOSS organization is to get kids excited in computer science by giving them project-based learning opportunities in computer science and engineering that have a humanitarian purpose. Learn something, help your fellow man. A simple and awesome idea. Softhum gathered together about 25 professors from around the country, large schools and small schools, all interested in learning more about putting their students to work in the open source world. I was there, along with Frank Hecker from Mozilla, to provide the viewpoint of open source projects.
HFOSS.org and TeachingOpenSource.org are two organizations that share a very similar agenda, and I expect that they will be greatly complementary. TOS.org focuses on identifying and eliminating the barriers that prevent professors from participating in open source; HFOSS.org provides a very specific context in which to put these principles to work. I’m happy to be part of both, and I was delighted to see the people behind Softhum (Ralph Morelli, Heidi Ellis, Greg Hislop) pushing its participants towards TOS.org.
I was gratified to see that one of the biggest questions shared by professors was, “how can I teach open source development practices to my students if I have not myself participated in open source?” It makes me believe that we’re on the right track with POSSE, and with The Mel now driving much of the day-to-day work of making the event happen, and Chris and Humph having the teaching end well in hand, I feel confident that at the conclusion of POSSE in late July, I will be standing high atop the Red Hat parking deck in my flight suit, proudly declaring Mission Accomplished, with a steely gaze in my eye and a spring in my step. Ah, what a fine day that will be. And then, of course, we get to figure out how to make that program scale from seven professors to seven hundred — but one step at a time.
The other big question, though, was a question for which I, personally, am not yet satisfied that there’s A Good Answer For. Of the many unanswered questions that remain, it is this particular unanswered question that will, I think, mark the difference between A Good Idea and A Movement.
That question: “what are the small open source projects that my students can work on, right now, and where can I find them?”
Mozilla is definitely working hard on answering this problem. Which is not surprising; they’ve been out front on this stuff for a while. They’ve instituted the student-project tag for their bugzilla instance, and to date, there are 80 issues in their bugzilla tagged this way. Maybe not perfect — but for a professor who’s considering throwing kids at the Mozilla project, it’s *incredibly* useful. That, combined with the mentoring page for Mozilla at TOS, gives a professor a pretty clear idea of how to get their students involved in the Mozilla project.
We’re certainly close to that in Fedora-land, and with Chris Tyler’s help, I expect that we’ll get closer in a hurry. We need our own project mentoring page on TOS, and that should be pretty straightforward — but figuring out what Fedora projects are suitable for student development may be somewhat more challenging. Looking at the status quo, I see that we’ve got a great list of unaccepted feature requests, which are categorized as “FeaturePageIncomplete” on the Fedora wiki, listed on this single page. (gregdek’s feature request #1: fix mediawiki to put a horizontal scroll bar on this page so you can actually *see* all of them.) There’s very little indication about which of these projects might be suitable for student developers, though, and that’s going to be really important. I’d love to hear recommendations about how to do that.
Anyway, we’re getting closer all the time. Once we’re satisfied that Fedora is Doing It Right, we get to work on all the other projects out there.
Good stuff. I’m excited by our rapid progress in this area in the past few months, and I enjoyed making lots of new friends in Philadelphia. Maybe next summer we’ll hold a POSSE there at Drexel; Greg Hislop seemed to like the idea and was ready to volunteer the space. I hope things go well enough that we can take him up on his offer. Philly’s a great college town.
I visited the University of Waterloo last week to keynote a small conference at their Accelerator Centre, which is their technology incubator. The topic of the conference: “open or closed, which should you choose with your new project?” I posed my keynote as a set of questions that every software innovator should ask themselves when making this decision — and, of course, the questions I chose were quite leading. 🙂
Sometimes I’ve got the mojo and sometimes I don’t, and for this speech, on this day, I felt like I had the mojo. It was a good day. It was a great crowd, very engaged. Mad props to Chris Tyler of Seneca for attending with me, and ferrying me to and from YYZ, and all of the great discussions that we had on those long rides. (And also for the roasted chicken at Swiss Chalet. Yum.)
But the *real* reason I wanted to attend was because one of the hosts of the event was C4, a technology transfer organization counting ten Canadian members, university and industry, from Southwest Ontario. When pushing the open source agenda at the university level, one of the many hurdles we hit repeatedly (and particularly in the US) is the intransigence of TT folks, and their inability to appreciate, or even understand, the value of open source software. After the conference concluded, I had the opportunity to sit down at lunch with a roomful of open source friendly TT professionals, to pick their brains about why, exactly, it’s so hard for TT folks to “get” open source, and what we can do to help change their minds.
Following are some of the key insights I gleaned about the business of TT from this discussion — and if I’ve misunderstood, please feel free to comment, since I’m still new to all this.
* TT orgs differ by mission largely by how the university itself treats IP. In universities where IP is institutionally-owned — which describes the vast majority of large American universities — the mission of TT orgs tends strongly to be generating revenue for the institution. In orgs in which the IP is researcher-owned, which describes a significant percentage of Canadian universities, near as I can tell, and a handful of US schools — the goal of the TT office is much more a facilitator to help the researcher get that technology out into the world, in whatever way the researcher sees fit.
* Most TT folks aren’t generally good at software; it’s not their sweet spot. They are more accustomed to dealing with technology from industries that involve the creation of physical goods. Therefore, their first question is *always* “what defensible IP have you created?” It’s not just that TT orgs are uncomfortable with open source software; frequently, they are uncomfortable with *any* software.
* In those cases where TT is seen as a money-maker, the role of the TT office is very much like the role of a venture capitalist. Unfortunately, the savvy that some VCs have picked up when it comes to dealing with open source has not yet rubbed off on TT folks — and let’s face it, TT orgs doesn’t have the wherewithal, the time, or the inclination to gain that degree of knowledge. VCs look at a whole range of variables in assessing the potential success of a project. TT orgs look at the one thing they can most easily quantify and protect: “what’s the IP?” It might be worthwhile to hook up the smart VCs who “get” open source with some of the larger TT orgs who don’t. Seems like it could be a win-win: VCs get an inside track on cool technology; TT orgs get a more reliable set of indicators about what makes open source profitable.
* Because TT is seen as a revenue stream, university policies make it difficult/impossible to go around them. TT orgs don’t have to “kill” open source projects, and generally they don’t; they just never give permission. Allow me to explain by way of a brief skit: “Hi, Dr. Doom, can I release this work from my thesis as an open source project? Yes, you say, I just have to get clearance through the TT office? Okay, great! Hello, TT office? I’ve got this software project I’d like to release as an open source project. You’ll look it over and get back to me? Great! When can I expect to hear back from you? Hello? Hello?” (Exeunt omnes, laughing.)
* Some professors just release their work anyway, and the ones who do often use the guise of “publication” to do so. Which reinforces the importance of creating a journal for this purpose; not only will it help solve the publish-or-perish issue, it may also help with the TT issue. I’m glad that it’s one of the key focuses (foci?) of the TOS group.
* There is *zero* information for TT orgs to look at when it comes to open source. This was the message that the C4 folks left me with: how will TT folks learn if someone doesn’t produce guidelines for them to follow? The C4 folks vowed to work with us on this problem, if we could help give them some direction. I hope we can figure out how to take them up on that offer.
A very useful meeting for me; I learned a lot. And Chabriol, thank you so much for my speaker’s gift. The dogs absolutely loved the treats. Definitely the most thoughtful gift I’ve ever received as a speaker.
Greg DeKoenigsberg Speaks 