Dear Lazyweb: Build Insanity Stories?

Dear Lazyweb,

I’m working on a text to introduce n00bs to the open source development process.  The latest chapter: The Horror of Building Software.  (That’s a working title.  I’m not sure whether it will be the final title or not.)

One of the things I’d like to include is a good-sized list of “all the stupid things you’re likely to run into when you try to build a project from the latest version of the source code”.  Like:

• B0rken deps
• Mispelings in configure.ac
• The utter lack of an INSTALL file

…and so on.

I’m focusing on GNU Autotools-based projects, just because I have to start somewhere, but Ant/Maven horror stories are also fine.  What small, stupid things have cost hours of your life in a software build process?  Lemme hear ’em.  In fact, I think this might be an entertaining standalone site.  Ismybuildhotornot.com or some such.

Anyway.

Enough of the boo-hoo-hooing about OLPC.

Wayan, here’s the simple fact:

The OLPC organization is built to do hardware innovation. Of the many things they’ve attempted, it’s the one thing at which they have clearly been wildly successful. They put the fear of God into Intel and forced the worldwide introduction of the Netbook, thus driving down the median price of personal computing all over the world — whether you choose to give them credit for that achievement or not. Their decision to focus on hardware innovation as a core competency is a good thing, not a bad thing.

Is the challenge of educating every child in the world bigger than OLPC can handle? Why, yes. Yes, it is.

There’s the problem of open educational resources, which is being attacked by organizations like OER Commons and Curriki and UNESCO, and possibly even by the United States federal government. Did you know that the Hewlett Foundation actually has a logic model for the development of open educational resources, which they now apply to every organization who comes to them for requests to fund education projects?

There’s the problem of open source software suitable for use by kids, which is being attacked by organizations like Sugar Labs and the KDE Education Project and GCompris and Squeak — all of whom have successfully deployed software that is now being used by lots and lots of kids. None of these projects are perfect, but all are continually improving.

Guess what? OLPC was *bad* at these things. That’s why they have, quite sensibly, left those problems for other organizations to solve. OLPC is now, and has always been, a single piece of a very large puzzle. The shrill cries that “OLPC HAS FORGOTTEN TEH KIDZ!!!!” are at best, unhelpful, and at worst, ridiculous.

So while all of the other organizations in the world work on the other sticky open education problems, let OLPC focus on the one thing they’ve clearly demonstrated an aptitude for: innovation to make better and cheaper hardware that is built specifically for the needs of young kids.

When you try to be everything to everybody, you end up being nothing and nobody. OLPC has learned that lesson, and I, for one, am delighted.

Thank you, Sebastian.

Sometimes the only thing you can say is “thank you”, because no matter how many more words you string together, you can’t get any closer to the true sentiment.

So thank you, Sebastian, for your gift, and for your friendship. And congrats on the Wired writeup, too. Be sure to point that out to all your new friends at Olin. 😉

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.

LOL Slashdot

Poor Nicholas. He can say something that is completely true, and get pilloried for it.

What Nicholas said, from TFA: “But what we did…was we had Sugar do the power management, we had Sugar do the wireless management — it became sort of an omelet. The Bios talked directly with Sugar, so Sugar became a bit of a mess. It should have been much cleaner, like the way they offer [it] on a stick now.”

Slashdot headline: Negroponte Sees Sugar As OLPC’s Biggest Mistake.

NO NO NO WRONG JUST TOTALLY WRONG. STUPID STUPID WRONG STUPID LAZY RTFA HIVEMIND SLASHDOT. FAIL!!! WRONG!!!

In what he actually said, Nicholas is exactly right.

What should have happened: OLPC should have worked to get system-level changes into the upstream Linux kernel / X / other projects, and Sugar should have been a desktop environment sitting on top.

What actually happened: OLPC forked its own distro and called the whole thing “Sugar”, pushed a ton of XO-specific changes in this distro, and wasted a lot of engineering cycles fighting to maintain a fork. This mistake was a crucial and painful mistake — one that we have fought to remedy in the context of Fedora 10 and Fedora 11. Two release cycles of nothing but pushing XO-specific code upstream, everywhere we find it.

I’ve certainly had my disagreements with Nicholas in the past — I still think it’s a shame how much community goodwill OLPC squandered by failing to be sufficiently transparent — but let’s not put words in the man’s mouth. Saying “the way we did Sugar was a big mistake” is a completely different thing from saying “Sugar was a big mistake”.

4th grade math: an update

As with all new projects, uptake is slow but steady. The mailing list traffic looks pretty good for its first month of life; we’ve got a few people who are working on various math-related activities; there are nibbles of interest.

Pulling all of this interest into a coordinated effort will be a continually ongoing exercise.

The next real milestone, I think, is to really flesh out the Math4 teams. Putting together a few strong teams that consist of at least one developer and one teacher will really help move us forward.

Another important goal for me personally is to ramp up my recruiting efforts — which means refining the pitch and finding as many opportunities as possible to make the pitch to interested people. There are only so many hours in the day, and I’m pulled in a ton of different directions, but pitching the vision is probably the most important activity I can be engaged in right now. Which means that my time for hacking Mongo is somewhat curtailed. Alas. I suck as a coder anyway. 🙂

Anyway. There’s lots of efforts out there to “help kids” using free software. I sincerely believe that helping to fill out the 4th grade math curriculum is one of the most immediately actionable things we can do as a community. Tell your friends — especially your teacher friends. Join the fight.

Still looking for professors: tell your friends!

Red Hat wants professors to participate in open source projects for a week this summer, and we’re willing to put our money where our mouth is.

We are accepting applications for this program right now. There have been some nibbles, but no formal applications yet.

The deadline for professors to apply is Friday, April 3rd, 2009. If you know any professors who would like to participate in an open source project for a week this summer, please tell them about this program. And if you have any questions, feel free to ask me.

That is all. 🙂

Mongo 0.000001 is in git.

Yaaay! Now I can pretend I’m a developer!

The code is a straight up hack of Mines of Elderlore, as I talk about in more detail here.

So. The code is here. And there’s a bunch of TODOs, which I’ll be working on in whatever spare time I have.

Patches welcome. For real! Now I can say that and actually mean it!

Hello, friends from TeachingOpenSource!

Chris Tyler, you are the man.

Now we’ve got a great bit of infrastructure for educators who are trying to teach open source to their students. What are we going to do with it?

Funny, I just spent a day with friends in Chattanooga at SIGSCE. A room full of professors and industry folks, all of whom care about exposing students to open source. We had some amazing discussions. My agenda was to find out why, exactly, more professors aren’t already engaging their students in open source. Some big obstacles, and some ideas about what we might be able to do about them:

1. Tenure. Wow, is this a big one. The way tenure works at universities really makes it difficult for junior professors to engage in any open source activities at all, and I’ve heard enough excited professors hammer this point, again and again, over and over, that it’s starting to sink in. We really need to figure out how to help profs solve this problem.

Some ideas here, briefly. One, create an academic-oriented open source conference with peer-reviewed, juried papers. Two, create an academic-oriented open source journal with peer-reviewed, juried papers. Three, work to convince professors that “peers” in computer science don’t have to be professors — that when Alan Cox says “yes, this paper at OLS is good,” it should have as much clout as the opinion of any professor. Four, focus on bringing research money to the actual creation of open source projects; nothing sells tenure boards like cash in the university’s hands.

2. Having bite-sized projects. This is a huge problem. Every time a professor thinks “gee, I’d like to find a project suitable to have my kids work on” and then goes to Sourceforge to find this project, a kitten dies and a professor loses his/her mind.

This is actually a very broad problem. Every sizeable open source project faces this problem — the problem of identifying on-ramp mini-projects that (a) are not so critical that they will harm the project if they Do It Wrong, (b) are small enough to be easily handled in several weekends of hard work, and (c) have artifacts like, oh, use cases — artifacts that professors need because they’re trying to teach this stuff.

Google Summer of Code does the open source community the great favor of *forcing* open source projects to articulate these kinds of mini-projects. For every project that Google approves, they turn down two. (More or less.) Figuring out how to leverage this work so that professors can pick up the projects that Google leaves on the table could be *tremendously* useful — and Leslie is thinking about it, so that’s good. 🙂

3. Having course materials. Lots of professors are doing lots of good stuff, but it’s spread out all over creation. Identifying all the CC-licensed CS curriculum stuff in the world and aggregating it somewhere would be great. Like, say, at teachingopensource.org. That would be awesome.

So. A productive couple of days, and lots of good ideas. Now comes the hard work of turning these ideas into reality — but the establishment of TeachingOpenSource.org is an important step down this road.

4gm: Getting down to it

Having presented fourth grade maths as a rallying cry, I suppose I shouldn’t be surprised to discover that Karlie and David have taken me up on it — to spectacular effect. David has XOs at the ready to hand out to the faithful, and Karlie has convinced a professor in Rochester to connect students to the project.

Guess it’s time to figure out what that project looks like, in a bit more detail than we’ve heretofore offered.

First order of business, though: if the notion of creating Sugar activities that connect directly to a larger educational framework and offer content, activity and skill assessment, all in self-contained modules that can be used for self-directed and self-paced learning, then join the Sugar mailing list for fourth grade maths.

Now that we’ve got that out of the way: what should we be *doing*, exactly?

Let me tell you what I’m doing, and why.

* * *

I’m working on a Sugar activity I call “Dungeons of Mongo”.

See, I’m a sucker for Rogue-like dungeon games. Always have been. Dungeons of Mongo will be a fork of a game called “Mines of Elderlore,” which is a Python-based Rogue-like. I’m just getting started, and it’s slow going, because for one thing I don’t have nearly as much time as I’d like, and for another, I don’t know Python nearly as well as I’d like.

So what’s the point of this fork, then, anyway? Simple. Unlike MOE, Mongo will have an educational twist (albeit an admittedly corny one): you fight monsters with knowledge. Aw, yeah! BRING THE KNOWLEDGE! “You dare to attack the domain of the Fraction Troll, puny weakling human child? Well, riddle me this: in the fraction 3/4, what is the DENOMINATOR? 4, you say? Ack, that’s correct! Fie, I am stricken! Woe unto me, now I die!”

Brilliant, right? I know! Okay, maybe not. But it’s a start. One thing I do like about the dungeon metaphor is that it’s got that immersive, exploratory element to it — which is why I played so much Rogue and Nethack and Larn when I was younger. Sure, it’s no Second Life or WoW, but it hardly needs to be — and to run on a cheap netbook, couldn’t be anyway.

Somehow, I’ve got to fit the following four elements into this activity.

1. Content. One can imagine the Six Tomes of Fractions. (“What’s a tome? Oh, it’s a fancy word for book? Cool.”) Each tome has content that teaches a lesson, and each tome builds on the lessons taught in previous tomes. Maybe it’s words, maybe it’s pictures, maybe it even spins off an Ogg player — but I’m sure we will start simple. This is obviously where we’ll need the most help from teachers.

2. Drill. Practice, practice. Level grinding in an RPG can be pretty boring, but you do it because you want to see what comes next. What’s the next monster? What’s the next treasure? What cool thing is waiting on the next level? You’ve just got to know, so you fight enough monsters to get to that next level — and if you’re anything like me, you stay up until 3am to do it. Why shouldn’t drilling math concepts work the same way?

3. Assessment. In the end, does the kid know what 3/4 + 3/8 is, and does he know how to get there? In the classroom, that’s what tests tell us. Now, the thing about a pen-and-paper test in the classroom is that you give the same test to 25 kids exactly once, and the overhead of creating that test, administering that test, and grading that test is what takes a significant chunk of any teacher’s time. Doing it repeatedly is all but impossible, so if a kid falls behind, there’s no time to help him catch back up. But for certain classes of tests — especially math tests — the questions can be infinitely variable, administered by the Boss monster, and instantly graded pass/fail. If you slay the Big Boss at the end, you win! And if you don’t understand how fractions work, the Boss kills you, and you start over. What kid wants that?

4. Alignment. Remember: all of this stuff should align with a useful curriculum framework, or educators won’t have any incentive to use it. We’ve chosen to work with a derivative of the Massachusetts 4th grade math framework, so dungeon level one could be all about 4.N.1 and 4.N.2, and dungeon level two could handle 4.N.3 and 4.N.4, and so on.

5. Customizability. Ultimately, Mongo should be a simple game to model some simple ideas. If they are good ideas, then people will either customize Mongo or build their own games with similar ideas. If we do it right, it should be a trivial matter to plug in different content, different drills, and different assessments. Of course, because all content and code is open source — that’s the point, after all — people are free to rip off these ideas and move forward with them. And boy, do I hope that people do exactly that.

Needless to say, patches welcome. I’ve got a hosting request in the pipeline with fedorahosted.org to host Mongo; as soon as that goes through, I will upload what I’ve got so far. (Which, fair warning, isn’t much.)

A couple of other wrinkles I’m thinking about:

* I don’t know nearly enough about Moodle, but I should. The quiz data formats are especially interesting. Standards make life easier for everyone, and it would be nice to be able to take content from Moodle, or any LMS, and drop it into Mongo. My first targeted question format for Mongo will, in fact, be the Aiken format used by Moodle for simplified multiple choice questions. Human readable, easily parsed, somewhat brittle. I can live with that for now.

* I haven’t even bothered to Sugarize my work on Mongo yet, and because I haven’t tried to write a Sugar activity in, oh, two years, I don’t even know where I’d start. I hope that the instructions for Sugarizing a simple Pygame-based activity are clear and easy to follow. And if they aren’t, that’s obviously a worthy project for someone to undertake.

Anyway. That’s what I’m working on.

* * *

Now, what should *other people* be working on? There are basically two options. Option 1: help me with Dungeons of Mongo. Option 2: start another activity project aimed at fourth grade math, maybe with a completely different approach.

Notably, Mongo does not yet align directly with any of the fourth grade math framework objectives. The questions and content, for now, are placeholders. Someone could certainly work the content side in parallel.

If some enterprising people want to start another project, that’s great. The principles should be the same: modular activities that encapsulate content, drill and assessment, that allow a self-directed learner to demonstrate mastery of a particular unit of knowledge that is aligned to the 4gm (that’s my acronym for fourth grade math) curriculum framework. With a strong preference for Python, since that’s the heart of the Sugar principle of hackability. Python activities can be brought up in Pippy right now. Java applets can’t, and neither can Flash activities.

Whatever you do, potential contributor, don’t overthink it. It doesn’t have to be perfect. Working code and loose consensus: that’s what moves open source software projects forward. Let’s get out there and screw something up. It is very dark, and if we don’t move forward, we are all likely to be eaten by grues.

(Don’t forget to join the list, where will be talking more about this in detail, and soon.)