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.

People
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
English.

My comment,
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?

Welcome, POSSCON attendees! This blog post is the virtual home of the talk Sebastian Dziallas and I (Mel Chua) did on Thursday afternoon, titled Curious Artifacts: Making FOSS Materials Make Sense To Learners. Our talk materials were, in large part, created with the audience.

The goal of the talk was to get audience members to actually look at live open source projects and start analyzing how those projects might fit into a high school or college classroom. When you look at a project, what cool things grab you, and what sort of little annoyances irk you? How can we turn them into the sorts of mini-project-opportunities students can tackle, and how do we build materials and scaffolding around those tasks that can be used as scaffolding – worksheets, reading, discussion prompts, homework assignments, grading rubrics?

This is a big job – so the trick was that our POSSCON talk started on Thursday… and was the kickoff to a conversation we continued online. Our intrepid audience volunteer Kevin came up and modeled the beginning of a first-contribution conversation using the original bounty Sebastian posted on Tuesday night, then the crowd split into teams and attacked printouts of FOSS artifacts with red and blue pens and highlighters. And smiley face stickers. Always gotta have the smiley face stickers. The audience critiques are available here (pdf).

Here’s the flyer that was handed out during the talk in lieu of slides (available in pdf and odt format for remixing) to guide participants through some of the tools, terminology, and cultural quirks they’d be encountering as they looked through the material to critique.

One big analogy used throughout the talk was open source as a cultural immersion experience similar to study abroad. This theme was used for the beginning and end. Some key points made:

• Study abroad is not just about taking the same math class in Paris that you could take back in Wisconsin. It’s about the experience of being in Paris – language, culture, transit system, food – math class is almost incidental. It’s the same way for open source. Students need to watch, appreciate, be prepared for, and make time for things outside their course material in order to really benefit from the experience.
• You’ll be in an unfamiliar environment. Simple things will be awkward at first – ordering a glass of water, fixing a simple bug. Keep going – yes, you could order water in English, but you’re in China so you can learn how to do it in Mandarin! It does get much, much easier after the first time or two.
• The point is to get out and experience the culture. Immerse yourself. Don’t just hang out with other expats or foreign students. Whenever possible, bring your students into the real world, real conversations, real materials… the point isn’t memorizing all the Italian verb conjugations perfectly, but to communicate with someone in Italian, no matter how broken. You’ll learn through conversation, so get out there and talk!

If you were at our POSSCON talk and want to add materials – comments, pictures, thoughts, anything – to this post, leave a comment.

Thanks for listening!

–Mel and Sebastian

Some pictures from the talk courtesy of Zenith Chua (thanks, Mom!)

Our brave audience volunteer Kevin explains his critique of Bug #180 in the Fedora QA trac.

An audience review of the Fedora Design team's meeting logs and bounties. I believe smiley face stickers were involved.

Verdict: Sugar on a Stick's websites contain way too many unexplained acronyms. We should do something about that.

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 government
Open data
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
Online/digital activism
Remix/mashup culture
Transformative works fandom, including fan fiction, fan art, and fan vidding
Maker/DIY community
Hacker spaces
Coworking

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 have used and promoted open source software for as long as I have been aware of its existence. I talk the talk, and I have met with success when ‘selling’ open source software solutions to my employers. But I must admit, I have not really been walking the walk… the extent (to date) of my open source ‘walking’ has been logging a few dozen bugs for various projects, a couple of minor documentation updates, and a couple work weeks of forum postings and mailing list responses. Not terrible, but I know I can do better… so, my resolution is to cut down on my internet browsing, and fill it with mailing list/IRC/Forum participation, documentation updates, QA, and coding for a few open source projects that are important to me. I plan to document my experiences with some of these projects, and offer any insight that I can to help others who are interested in getting involved open source. I’m planning to get much more involved in Habari (PHP – powering this blog) and GeoServer (Java – I use GeoServer in my usual geo-spatial stack). Because I have different levels of comfort in these technologies, and because the projects are run very differently, these two projects will offer a great way to look at some of the diversity that is possible in open source participation…

That’s where I am at the end of 2010. I’m taking baby steps here, and aiming to be an active participant in these efforts with submitted code, bugs, and documentation updates during 2011. Future posts on getting started in open source will likely compare my experience of similar activities, and how they proceed in the two distinct projects. I hope this way of dispensing my experiences will offer easy ingestion for users interested in different projects, as well as users with distinct skill sets. Hopefully the variances between the two projects will allow a good deal of data for each step along the way. Stay tuned for a ‘Getting started in open source participation’ article on exactly what I’m doing to get my foot in the door for these projects, and a little bit more about what I’m expecting in this effort.

I’m very much looking forward to reading these posts, and have encouraged Nicholas to tag them so they’ll show up on Planet TOS – he’s a keen writer with the ability to reflect on his mental processes while learning something as a novice, which is something that will be incredibly valuable for any open source project trying to get insights into how the participation process looks like from the newbie side, and also to newcomers looking to read about the thoughts of someone going through the process they’re about to launch into.

I hope that more newcomers join Nicholas in writing down their thoughts as they begin their own FOSS journeys. It’s actually the sort of thinking and contribution that we typically lack the most – and something that experienced contributors cannot do. I have some of my own thoughts in this blog from several years ago when I began actively contributing to open source, but they’re faded and fuzzy and I
wish I’d done more (I was confident that nobody would care, but as it turns out, I wish I had written more down).

Too often we’re only publicly reflective only when we’re confident and experienced with something – so I applaud (and admire!) the courage being demonstrated here. Good luck, Nicholas – please keep writing, and let us know if we can help you with your adventures in any way.

Sugar is too hard to download and install. Walter was recently surprised to hear (during an interview) that even “advanced users” (I’m assuming he meant the computer-savvy who were new to Sugar in particular) had difficulty with our installation instructions, so he went and did something about it.

Walter’s new revision draft is meant to be an improvement over the current Downloads page (last edited August 21, 2010).

I offered to try and drum up some testing to see if this is actually an improvement, and what remaining rough edges need to be sanded off. The catch is that most of us can’t help with this directly, since we probably already have Sugar running on our machine and are used to getting around the current install instructions to make it work. Therefore! Here’s what you can do to help.

If you’re a Sugar old-timer and can figure out the new install instructions with no trouble:

Congratulations, you’ve learned how to work around our existing documentation! Find yourself some newcomers and sit down with them and work through instructions below in person – remember to send things to the iaep list so we can all learn from it!

And remember, when they’re looking at the page, don’t say anything – don’t take the keyboard from them, don’t do things for them, don’t interrupt them. They’re doing very important work – the work of telling us exactly where the shortcomings in our documentation are. When they point them out, help them by fixing the documentation together and then allowing them to continue proceeding by themselves.

If you’re new to Sugar or think the install instructions are hard to understand:

You are exactly the kind of person whose help we need. See, most of us have been using Sugar so long we’ve forgotten what it’s like to be a new user puzzled by install instructions – we’ve lost the ability to improve them because we’ve gotten too used to how difficult they are to understand. Here’s what we’d love help with.

1. Check out the proposed redesign for the download/install page.
2. Try to get Sugar running – whatever platform you have, whatever means you’d like to use. Do not ask for help yet, even if you’re getting stuck. We’re trying to find out whether the instructions on that page – and linked from that page – are sufficient to enable folks to get through the installation on their own.
3. If you do get stuck, write down (or take a screenshot and circle) everything you can think of about what’s confusing about the page, what you had to take a guess at, and as much as you can describe about where and why you’re stuck. This is incredibly valuable feedback that only you can give – you’re showing us how our documentation can be improved, pointing out things we don’t realize we ought to fix – until you come along and tell us. (If you manage to make it through to the end, this sort of feedback on how it could have been better is valuable anyway – but you can also skip to step 5).
4. Now that you have these notes written up, take them and send them in an email to the it’s an education project mailing list (iaep at lists dot sugarlabs dot org). If you cc me (mel at sugarlabs dot org) on the email, I’ll make sure your feedback gets looked at and brought to the right people.
5. After you send that email, someone should come along and help you finish the installation. When you have Sugar working on your machine, if you can drop us a line again (on the iaep mailing list, and cc me) so we know you were taken care of and that things are working for you now, we’d very much appreciate knowing that you’re all set.

Thank you!

TOS is a community of practice of people who teach open source community participation in an academic context. It’s not a teaching or research institution, a company or nonprofit, a software project, or a professional society, though many of its members belong to one or more of these, and we make use of their structures in order to accomplish our goals.

Our primary deliverable as a community is academic source (this term feels a bit awkward to me – perhaps there’s a better existing one from the teaching world?) – artifacts that assist the transfer of the ability to teach open source community participation in an academic context. Things like workshops, syllabi, curricular materials, handouts, etc. are tools to accomplish our goal, which is a human-to-human transmission of teaching, rather than the end-all-be-all themselves.

Several parts fit into this:

• Conferences and events in both the FOSS and academic worlds as public spaces, gatherings where we can swap this knowledge. Individual institutions, to some extent, will always be black-boxes and more private spaces; that’s okay.
• POSSE as an on-ramp into the community; you don’t have to attend POSSE to join the TOS community by any means, but if you’re interested yet don’t know how to start, it’s a good way to get up to speed.
• Infrastructure to support digital communication within and between institutions, both hosting and maintaining it within the institution-neutral space of TOS, and helping those who want to set it up within their own institutions.
• Grants to assist with all three of the above.

Open question: what value does the TOS community create for each of its participants? (In other words, why are you here, and what does your school/company/project gain from your participation?)

That’s it – I’d love feedback and thoughts on this.

We spent most of our time on the next big urgent milestone: getting testable Sugar 0.90 images out the door for upstream Sugar QA. This isn’t an official SoaS release, but since SoaS is an easy way to get an instance of Sugar up and running, it’s great for testing, and since we’re going to include the 0.90 release of Sugar anyway, Simon has asked us to include it in our test builds by a certain date so it can be used to test the Sugar environment itself. By “certain date,” I mean that the 0.90 Beta release is this Wednesday; here’s what has to happen preferably before then. (For the Fedora folks in the audience, SoaS is a Fedora Spin.)

1. Simon updates the sugar, sugar-toolkit, sugar-datastore, sugar-presence-service, sugar-artwork, telepathy-gabble and telepathy-salut packages in Fedora to the correct code versions.
2. Mel gets 3 people to test these packages and give them karma in Fedora’s system, which will put them in the stable repositories. I’ll be writing instructions on how to do this shortly.
3. Simon or Peter or someone takes the next daily build and makes sure it boots, then announces the test image.

What this means for you, o reader: if you run Fedora (or can run Fedora in a VM, or can follow written instructions on how to do exactly this), you (yes, you!) can help us with 0.90 testing this week. We’re going to have instructions for this coming out once the code is ready to be tested; it should take less than 2 hours (hopefully less than 1) to do your setup and testing from start to finish, and you won’t need any prior experience. We’ll be using the same test setup for Sugar in the future, too.

The catch is that because we’re under intense time pressure to meet release deadlines, the time between when we can say “we’re ready! We need help!” and when we need the testing finished by is going to be VERY short. So this is a heads-up letting folks know this call is going to be coming.

Stay tuned for more QA news in Sugar land! (dun dun DUNN!)

This blog post written under more sleep deprivation than is probably good for me. I’m going to go to bed now so I’ll be more useful in the morning.

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.

1. ssh into the box you have an account on – for instance, Sugar Labs folks can use sunjammer (aka people.sugarlabs.org) by requesting an account at http://wiki.sugarlabs.org/go/Sysadmin/Shell_account_request
.

2. Run these commands (comments in parentheses).

screen

(a dialog will pop up, hit return to kill it)

irssi

(you’ll get a mostly blank screen, with a stripe across the bottom with the
time and a number [1] in brackets – that’s the window list – and then a line
below that with [(status)] in it, which is the description of the window that
you’re in, and the place you type the rest of the commands.)

/connect irc.freenode.net

(and then, if you want, /msg nickserv identify <password> to sign in.)

/set autolog on

(it’ll start storing things in ~/irclogs in self-explanatory filenames)

/join #sugar

(and whatever other channels you may want to be in)

(You’ll notice that every channel you join opens up another window – the first
channel will be in window 2, the next in window 3, and so forth. Use ctrl-p
(previous) and ctrl-n (next) to switch between windows, or alt-NUMBER to jump
to the NUMBERth window.)

(You’ll also notice that the numbers for each window light up in different
colors when someone joins/leaves a channel (blue), talks in a channel (white),
or calls your name in a channel (pink).)

(All the normal IRC commands work as expected, and so does tab-completion.)

(a note on /whois: if you have a PM window open for that person, the whois
information will appear in the PM window. Otherwise, it will appear in window
1.)

3. When you want to stop, do

/away <away message>

and then detatch from screen, which is

CTRL-a, d

(ctrl-a followed by d)

which will dump you in your normal sunjammer shell outside of screen.

Or you can just kill the terminal by typing

~.

or whatever.

When you log in again, restart the screen session with

screen -raAd

…and you’ll be back. If you then type

/away

…you’ll see all the messages sent to your nick in the meantime in window 1,
and you’ll be set to not-away.

4. More docs at http://www.irssi.org/documentation/startup
and http://quadpoint.org/articles/irssi
.

I mostly find irssi useful for being always-on all the time and having backlogs
of conversations that have happened while I’m away. It also means that anywhere
I have ssh, I have IRC.