Posts that are olpc-ish
First: I’m working on a list of FOSS hackers who’ve gone back to school to study FOSS in some way; do you know of any? Please let me know in the comments. They needn’t be coders; designers, documenters, etc. are also totally welcome, as are contributors to open content and hardware projects — for instance, a very active Wikipedian who goes to graduate school to study the collaboration practices of Wikipedia.)
Seb Benthall’s post about academic vs open culture reminded me that I’d like to track my fellow FOSS-to-academia migrants somewhere. Seb and myself are members of a fairly short tradition that includes folks like Martin Krafft (Debian developer to CS/Sociology PhD) and Mako Hill (Debian developer and Ubuntu hacker to interdisciplinary PhD student and Berkman Center researcher).
If you think about it, there’s no way the tradition can be anything like short. Undergraduate degrees tend to focus on “study to be able to do” for a broad area rather than a more focused “study of” a particular topic, so I’m mainly looking at grad students and those who’ve gotten their graduate degrees. To enter graduate school, you typically need an undergraduate degree — which means you’re likely at least in your early twenties. That’s how old the Free Software and Open Source movements are themselves.
It’s not that we’re the first generation of grad students to grow up in FOSS culture — that distinction belongs to people now in their mid-thirties to early forties, who were college-aged in the mid-90′s when the FOSS world was ramping up for the firs time. But we’re the first ones to enter grad school at a time when FOSS culture was widespread enough to be considered a legitimate topic of study by open-minded advisors; in a prior day, we might have studied CS, math, education, or any number of things with “proper” topics as our primary research focus, with open source remaining a devoted side hobby mostly separate from our “real academic work.”
It’s a good time and place in history to be. Plenty of opportunities to find and make — and we’re hackers, so we’re used to finding and making our own way through a chaotic world. Perfect.
I finished my first lit review today. Or rather, I should say “I finished the first dot release of the pre-alpha version of my first lit review today,” because I look at this and know that it’s nowhere near where I want it. Then again, “where I want it to be” is at the start of my dissertation about… oh, 3-5 years from now. All things considered, it’s not bad for someone’s first real attempt at independently scouting out scholarly sources.
From the introduction:
This is a preliminary and extremely incomplete literature review surveying the current academic scholarship on open source and education. It can be summarized in three words: there’s not much. I’ll begin… by discussing what I am not looking at… I am not looking at the use of open source software in educational contexts… open source as an IT solution. Nor am I looking at open source with a focus on content licensing… open source as an information access solution.
Instead, I am concerned with an analysis of what sorts of practices and processes for learning are exhibited in open source communities themselves and how these practices might be made transferable back to the classroom. In other words, I see open source as a way of operating learning communities: radically cross-functional, collaboratively constructed realtime transparency.
Aaaaand here’s the whole dang thing, below. Why push now? Well, after a certain point, I decided to stop agonizing over it and release early and often because hey, maybe what I need are some other eyeballs to kick me out of the mental ruts I’ve gotten into. Also, I finished writing it and turned it in 20 minutes ago (which may explain why the quality of the writing degrades considerably in the last 3 paragraphs). It’s been a rough week. Month. Semester, really.
Literature review: the open source way and education (alpha)
Essentially, I spent my entire first semester of grad school finding that nobody’s really done research on my topic of choice (engineering education happening in open source communities) before – which is both awesome (because that means I get to do it) and depressing (because WHY AM I ALL BY MYSELF OUT HERE I DON’T KNOW WHAT I’M DOING). And now I’m standing here unsure of what to do next; I want to read some of these more deeply, talk about them with people, have folks tell me where I’m wrong and why, get into debates over a bunch of these ideas, throw them off the wall, bounce them off other people’s heads…
And so I fling this out to you, my friends. Thoughts? I apologize that this is not in comic book form – it was a little harder to get away with that for a lit review… but I’ll keep trying.
Via Sumana, a post by Amir Elisha Aharoni on the paradox of localization:
who don’t know English strongly prefer to use software in a language
they know… People who do know
English often prefer to use software in English even if it is available
in their native language. The two most frequent explanations for that
is that the translation is bad and that people who want to use computers
should learn English anyway. The problem is that for various reasons
lots of people will never learn English even if it would be mandatory in
schools and useful for business. They will have to suffer the bad
translations and will have no way to fix it.
So this is the paradox – to fix localization bugs, someone must
notice them, and to notice them, more people who know English must use
localized software, but people who know English rarely use localized
software… Even people
who know English well should use software in their language… especially
if it’s translated badly, because they are the only ones who can report
bugs in the translation or fix the bugs themselves…
I am glad to say that i convinced most people to whom i spoke about
it at Wikimania to at least try to use Firefox in their native language
and taught them where to report bugs about it. I also challenged them to
write at least one article in the Wikipedia in their own language, such
as Hindi, Telugu or Kannada – as useful as the English Wikipedia is to
the world, Telugu Wikipedia is much more useful who speak Telugu, but no
summarized: can the software be hacked to make this easy for
multilingual users to contribute to? Imagine being asked to opt-in for occasionally
having the application start up in (or switch into) another language
you know — for instance, “every 25th time you log into this website,
you’ll see it in Hindi” — with a reminder shown during those
language-switching times thanking you for aiding with translation
quality and giving you a direct link to report translation problems?
Because sometimes the problem is just a little too much friction;
switching the language of an application takes 5 too many mouse-clicks
to be thoughtlessly easy, and the vast majority of users don’t wake up
in the morning and think “you know, I could contribute to the localization of the software on my computer!” The lazier people can be and still help you, the more likely they’ll be to do it.
Which applications, or which types of applications, would be easiest to do this with?
Passing on a message from the Ada Initiative, a group doing what I personally believe to be incredibly important work on gender representation in free and open source software, content, and culture – precisely the things the Fedora Project is working towards the rapid advancement of. The survey really does take less than 5 minutes; regardless of your gender, please give it a shot!
The Ada Initiative is a newly-formed organisation which aims to support and promote women in open technology and culture. We’ve just launched our first annual census — a broad survey of open technology and culture participants — to find out more about what projects and communities people are involved in, and how they feel about women’s inclusion and representation in the field.
We use the term “open technology and culture” to refer to a wide range of activities and communities based around free/open licenses, and other forms of open, decentralised, and grassroots participation in technology and related fields. This includes:
Open source/free software
Open source hardware
Open geodata and maps
Open standards and formats
Open educational initiatives (open access journals, open source curricula, etc)
Open/decentralised social networking (including Diaspora, StatusNet, etc)
Creative Commons and free culture
Wikipedia and other wikis
Open crisis response and humanitarian projects
Barcamps and unconferences
Transformative works fandom, including fan fiction, fan art, and fan vidding
If you’re involved in any of the above areas, we’d like to get to know who you are, what you’re working on, and your thoughts on how women are doing in your community. We welcome participation by people of any gender, although we are particularly interested in women’s responses.
The survey only takes about five minutes, and can be found at https://www.surveymonkey.com/s/adacensus2011-email.
I found this mailing list conversation snippet to be very insightful, and wanted to share it.
Scott: “Open to critique” isn’t quite the same as “responsive to critique”. From an outside perspective, it seems that frequently SugarLabs is just not listening to people who offer contrary opinions. This is better than flaming them, but maybe not as good as it could be. For an end-of-year report, I’d like to see instances enumerated where SugarLabs actually internalized some outside critique and responded in a positive way — some concrete change made to the UI, or Sugar, or to process. That would be more convincing that simply stating, “we are now open to critique”.
Bernie: We’re definitely intimidating to non-technical people. At least, this is what I sensed at the Realness Summit. OLE also seems to be doing a better job at connecting with educators. I’m not completely sure what corrective actions should be. We might need to do some work on the wiki, maybe add web forums, which non-geeks tend to prefer…
Scott: I suspect that the answer to this problem does not involve installing additional software.
Later in the day, Jeff and I were having this conversation on #teachingopensource.
Jeff: Is IRC really a barrier to entry? maybe I have simply been using it too long, but it seems immediately recognizable to me. I think one barrier might be the attitudes that crop up. Even with emoticons, sometimes it’s hard to discern intent. Hard enough in email, but sometimes devastating in real time.
Mel: Actually, yes. I had a really, really hard time figuring out IRC. First, figuring out that it existed and I had to use it. Then how to get it, how to set the software up. Then what the heck networks and channels and whatnot were – and why channels? my IM paradigm was “you have a buddy list and you ping people individually.” So “chatrooms are the default!” wasn’t hard to understand once I realized it, but it took a while to realize because I wasn’t looking for it.
And then “oh man, who are all these people? I am nervous about pinging them, will they yell at me?” And then all the /commands I had to remember. It was so bewildering and terrifying and new and it was being used as a way to present new information to me at the same time, sort of like… taking your first calculus class in… Mandarin, if you’ve also just started studying Mandarin as a foreign language. You can’t concentrate much on the calculus because you’re going “zomg it’s in CHINESE.”
It’s hard to remember how hard things can be, especially when you’re surrounded by a community of people who are the ones who self-selected and made it past that hardness. By definition, if you’ve gotten into FOSS, the current participation mechanisms worked for you… so why fix them?
Because we want others to join us.
The email I sent my team today as a “what did Mel do?” update:
00:18 * mchua has had a great day.
00:19 < mchua> When college professors start high-fiving each other across the classroom like excited kids because they got a button to work on a Sugar Activity, and then head out for ice cream, it is a Good Day.
I’m too behind/tired to be more verbose – turns out it’s difficult to simultaneously teach at and document a POSSE (probably due to that blasted 3 hours of driving per day – will hopefully do better next week). But betwen Friday noon and Sunday at 6 when the RIT one starts, I’ll spew logs from this one.
Big idea: Sometimes, you’ve just got to dive in and work on the code… together.
Skill: Making contributions to an open source project “in the wild.” (In this case, the Measure Activity.)
Of the three, the notes for the last one are the most interesting – the notes for maddog’s talk are essentially a paraphrased (brief) transcript of his 1.5 hour presentation on “how FOSS teaches you twice.”
Some of you may have noticed some new faces around the Sugar community – we (Walter Bender, Peter Robinson, and I) are hanging out with a group of professors (mostly from the Worcester area) who are in town this week for POSSE (Professors’ Open Source Summer Experience), a workshop for learning how to get their students involved contributing to open source projects. (In this case, Sugar, with Fedora as a dev platform.)
They’ve been learning to hack Sugar all week, and are in fact in #sugar at this very moment tinkering away on the Measure Activity. Their feeds haven’t yet been added to Planet Sugar Labs (those requests are still pending), but you can read some of their (great!) reflections so far on Planet TOS.
So if you have a moment, pop in and say hello to:
- Peter Froehlich (Johns Hopkins) – pgf
- Karl Wurst (Worcester State College) – kwurst
- Nadimpalli Mahadev (Fitchburg State College) – Mahadev
- Kristina Striegnitz (Union College, Schenectady, NY) – kis
- Jerry Breecher (Clark University, Worcester MA) – diamond
- Mihaela Sabin (University of New Hampshire) – mihaela
- Gary Pollice (Worcester Polytechnic Institute) – gpollice
- Aparna Mahadev (Worcester State College) – aparna
Next week we’ll have another – slightly larger – batch from RIT doing the same thing, with myself, Chris Tyler, and Luke Macken focusing more on how to make Fedora a better environment for running/deploying/developing Sugar – if you have any thoughts in this direction, please send comments our way! (Things we’ve come up with so far: general Python development stuff, liveusb-creator hacks, SVG rendering working strangely in different recent versions of Fedora… we need to turn this into a proper ticket queue. Ideas welcome! What are the little annoyances you always wanted to fix? We’ll do our best to take them on.)
With yet another (Fedora and SoaS) release cycle coming up, one of the things we can do to prepare for the future is to look at the past and try to learn from both the intentional and inadvertent things we’ve done before. With that in mind, the Sugar on a Stick team has put together a release history for v.3 Mirabelle, recapping the main decisions/events and rationale of the past 6 months.
Sugar Labs folks interested in a peek behind the scenes may find it fascinating reading, but we think Fedora folks curious about what the spins process looks like from the “other side” and Teaching Open Source folks looking for examples of reflective learning may also benefit from a quick skim. We had many triumphs and learned many lessons (often the hard way) – some excerpts are below.
On becoming a Fedora Spin
Before SoaS was a spin, it was a Fedora Remix – which means that bit-wise, the product looked the same, but the technical work that needed to happen to generate it was all done manually and without external resources and support, so it happened spasmodically and slowly and with a great number of sleepless nights.
Becoming a Fedora Spin gave us access to Fedora’s engineering, marketing, and QA resources, which dramatically improved the sustainability and scaleability of our release engineering processes. For instance, .iso files stopped being produced by the “Sebastian manually builds them every time” process, and started being automatically generated for testing by Fedora build servers. We gained some instant automation of the infrastructure we need anyway, without any more work or maintenance on our part, so we could focus on things like… making Activities work, the stuff that’s actually unique to Sugar.
The January 8, 2010 SoaS planning meeting led to the decision to apply for spin status. Looking at the January mailing list archives, we didn’t explain the significance of the spin decision very well then, which may have led to communication disconnects down the line that made Activity development and Marketing more difficult. In particular, we did not make it clear enough that we were now tied to the Fedora release cycle, and what that meant.
On accidentally making life difficult for Activity developers
Two of our upstreams (Fedora and ASLO) basically collided when they combined, and didn’t realize that collision was coming, because we didn’t track dependencies between them… part of the problem was that we didn’t know who was responsible for keeping track of that aspect of communication, so everyone assumed it was someone else and nobody did it.
The Activities confusion manifests itself in the small number of “supported” activities in the v3 release. Marketing was then confronted with the sudden removal/noninclusion of activities from the release – again, this is something that could have been prevented with a working feature process.
Major accomplishments this release cycle
- We have a team!
- We have a release schedule!
- We started using the Fedora Spins process and engineering resources, which made release engineering much smoother.
- We started driving communications to public channels – notably the SoaS mailing list – so things are more transparent.
- Multiple people have commit access to each repository that needs to be handled, so there are no single-person bottlenecks remaining.
- We shifted to a time-based release cycle, meaning we had a target release date set early in the process rather than our prior “it seems ready… now-ish?” method.
There’s more available at the full recap – we’re still a pretty fledgling project and new to introducing many of these processes (and still building our scaffolding!) so if you have thoughts/comments/suggestions/advice on how we could improve, please let us know via comments here, the soas mailing list, or pinging pbrobinson (Peter), sdziallas (Sebastian), or mchua (Mel) on IRC (we’re often in #sugar on irc.freenode.net).
Planning for the 4th release (the codename for this release is yet to
be chosen – suggestions for this welcome, too!) begins on Monday, June
7, at our weekly IRC meeting. And of course, if you’re interested in helping with the next release, please join us!
Dear students involved in Fedora, Sugar Labs, OLPC, and/or any other open source project:
Please take a minute to explain to people with fancy titles why you are awesome.
That is all. I hope to see some of you in Boston in April spreadin’ the good news.
My cousin Audrey (kindergarten, age 6) just submitted her first ticket to an open source project. It’s in the Sugar Labs trac instance as a request for a “clear all” button in the Physics Activity.
This raises some interesting questions. How do we handle feedback from children? In this case, Audrey has an older person (me) who can transcribe and submit her dictation (technically, it’s under my account because she’s not old enough to make one herself, I believe you need to be 13) and help be a mediator between her and the development community. I live with her – in fact, I’m sitting next to her in the kitchen while her mom cooks dinner right now – so it was very easy for me to ask her parents for permission. Do we need to sign something? What are the limitations on what we can do? What would I have had to do if she hadn’t been a cousin that I live with?
Once the legal stuff is all out of the way – what do we want to do with this kind of feedback? How do we teach children how to submit good bug reports? How do we stay responsive to them every step of the way? (I have a short attention span, but even my lack of patience has a longer timeout than Audrey’s…) Do we want to spend our bandwidth being responsive to this kind of feedback – over and above other kinds of work we could be doing? How can we help kids help themselves more?
On that last note, here’s what I’m looking for in terms of help with this ticket.
Audrey has an older sister named Melanie, who is 14 and a freshman in high school. 2 summers ago she taught herself some python and pygame to make a language-learning flashcard program when she was studying Spanish. She’s now looking to make her first code contribution to an upstream open source project, and is wondering if someone would be willing to sit down on IRC with her (nick: mkim – already lurking in GIMP and Fedora Design/Art channels) over the winter break and walk her through checking out the code (she knows what version control is, but has only used SVN before), searching through it to find the right stuff to modify, submitting a patch, and generally walking through the whole “how do you become a code contributor once you know how to code?” process.
Now, I could do this, but it’d be the blind leading the blind – my pygame knowledge can be described as “rudimentary” at best, and I’d rather have her guided by someone who already knows how to do Sugar code development. She needs a better teacher than me to guide her through this project. Would anyone be interested in taking a few hours some evening or weekend and working with her on this?