Welcome graduates of POSSE SA!

Actually, South Africa is a big place; perhaps there will be more POSSEs there, in which case, we’ll have to call you Classic POSSE SA, or something like that. Mind you, you’ll always be special. But really, I digress. Already.

Take 2.

As you look to involve your students in the world of open source (and, indeed, as you explore it further yourself), use the tools you’ve been introduced to so we can stay in touch. Not so much because those who came before think we have all the answers, but because we’re hoping you can contribute to and improve the explorations we’re making already. And, for that matter, TOS can, we hope, serve as a space where we can support each-other as we try and engage in explorations that encourage our students to reach beyond their comfort zones as they begin exploring the world of decentralized collaboration under the aegis of free and open communities of practice.

So again, welcome!

During the summer of 2009, I had the good fortune of taking part in the Red Hat POSSE programme, meeting a bunch of excellent open source peeps, and getting a sense for how I might introduce more of my students to the world of open source contribution. This last spring, my colleague and I introduced 40 first-year students to the Fedora project. This semester, I’d like to introduce y’all to a few more.

This semester I will be leading eight intrepid students in an exploration of interface design and development at Allegheny College. Your open source project (or a small part of a larger project) could benefit greatly from these students, if you’re interested.

HOW YOU CAN HELP

I want developers/managers from “projects” that have a GUI. I say “projects” because you might be the lead on, say, a network settings dialog box that is part of Fedora. You need to be of the mindset that your GUI could always be better, but you never seem to have the time to sit down and do heuristic evaluations, sit users and do interaction testing, and so on. If we work with you, you also have to commit to being timely in responding to the students—most likely on your developer mailing lists—because we can’t wait for two weeks to go by in a 14-week semester while we’re waiting to hear back from you. (I’m not talking about 5-minute response times, but if you can’t reply to email from people trying to make your project better within 24-48 hours, please don’t respond.)

Basically, we ask that your community be reasonably responsive, and we’ll be doing all the work.

WHAT WE WILL DO FOR YOU

Macintosh Plus

Small teams of students will, throughout the semester, engage one or more of these projects as budding interface designers. They have no prior experience in this regard, but will be engaging material on lo-fi prototyping, usability, the psychology of interface design, and so on. We will be discussing this material (which we will try and do in as open a manner as possible) and directly applying what we learn to the interfaces that are part of your project.

The students will work within your community, using your tools (mailing lists, wikis, etc.). I do not expect them to implement their designs, although some of them may be capable of doing so, and they might even do it. This, however, will not be a requirement of the course. (Not everyone in the course is capable.) If their work is good, and you like what you see, we only ask that you give their efforts serious consideration for implementation… we’re working with you because we don’t want to be doing interface design and testing in the abstract, but instead we want to add value to real projects through our efforts.

SOUND GOOD TO YOU?

If it does, please drop me an email (mjadud at allegheny dot edu). If you’d like to talk to me on the phone, I’m happy to chat—92JADUDM92 is my Google Voice number, which… well, it’s new to me, so we’ll see what happens.

I don’t (yet) have the course website up, but it will probably live here when it goes live

I’ll have to write a longer post later, but I thought I’d just mention that OSCON is a great conference. Our presentation went well, and we’ve had a lot of great conversations with people about all kinds of things in the open source world.

More later… for now, it’s time to head out the door.

(Related, our parallel programming environment for the Arduino is now available on Ubuntu, Windows, and Mac. Hooray for packaging! And, I need someone to help me work through how to do proper source packages for some of the complexities I’m facing on the Fedora/Ubuntu side. Packaging compilers is not a lot of fun…)

One of our third-year students is giving a talk about two of his passions today: Tea and Twitter.

Pat Canella ’11 will present a talk titled “Twitter and Tea” at 4:30 p.m. on Wednesday, March 17 in Alden 101. The talk will focus on Canella’s own experience with the tea community, on Twitter and other “Web 2.0″ tools. Refreshments will be served. The talk is sponsored by the Association for Computing Machinery at Allegheny. All are welcome to attend.

What started as an exploration of an idea in our Junior Seminar became a talk that he’ll be delivering to a much wider audience. And rightfully so—Pat has been exploring tea through a number of media (Twitter, blogs, etc.), so this should be good.


The concurrency.cc logo

I am excited to announce the release of Plumbing, software and documentation to support artists and makers in the programming of low-cost, open-hardware
platforms like the Arduino. The Plumbing libraries are a collection of parallel components written in occam-pi , a small language with a long history.

Last summer, we decided that it was time to bring six years of work regarding runtimes for parallel languages to the Arduino, a popular open platform for exploring the of art, electronics, and computing. In doing so, we decided that documentation would be critical in this effort. Documentation became a focus because we decided as a team that users matter. In designing and documenting Plumbing, we kept our focus on the students, artists, and makers who might do something amazing with our tools.

I think we’ve taken some substantial risks. Many people have contributed many thousands of hours of development time in our software (to say nothing of the years invested in occam-pi), and we will soon be releasing hardware as part of this effort as well. For me, the most substantial is the commitment to publishing our book, Plumbing for the Arduino, under a Creative Commons BY-SA license. That means that anyone can modify, distribute, and sell our work, as long as you give us credit.

Giving our book away is substantial because publishing is part of how academics are evaluated and keep their jobs. By giving away our book, we must now convince our respective institutions that publishing under the Creative Commons will force us to produce a better product (on an ongoing basis) than editorial review would, as well as reach more readers than if we found a publisher (who would then claim copyright over our creation). Or, we must find a publisher who is interested in helping develop and market our text while allowing it to continue to be available under a free and open license. (If you know one, please have them drop me a note to me at matt at concurrency dot cc.)

concurrency.cc and the materials made available from that site have been in development for years. I’m glad to finally see everything settling in place so people can easily download and explore the tools we have spent so many years working on. If you do, let me know how things go. (We’ll have mailing lists up soon, I promise… but for now my job as a professor calls, and it’s going to be a busy few days…)

Thanks to Dave Humphrey, GDK, and the rest of the POSSE crew. For months the encouragement to just release! has been kicking around my head. That message helped keep us on track as we reworked build systems, wrote text, built websites, and generally did all that stuff that no one thinks about when bringing a project together.

And we’ll get a Fedora RPM done as soon as we can. (In the meantime, you can build from source like the rest of us.)

I gave an introduction in Technology and Activism the other day to the Creative Commons. In that introduction, we (briefly) explored two thought problems:

[ music ] How long until you can own every song ever written? My first question had to do with music. If $60 buys a 500GB hard drive, you can put one year of non-repeating music on it. (I’m using the song Seasons of Love from the musical Rent to drive my calculation regarding the number of minutes in a year.) How long until hard drives can casually/affordably hold all music ever recorded? I put it to the students that they will likely see that day come within the next 10 years, at which point the way we consume music will certainly change.

The second though problem is much more interesting to me, however.

[ textbooks ] How much do you spend per semester on books? A quick poll of the class showed that the majority of the students spend between $250 and $300 per semester. Lets look at this picture:

201001280707.jpg

A publisher gives me a book for free. I like it. I assign it to all of my students. They then buy it, sometimes paying $120 or more for a single text (Physics, Math, Psychology, Biology, Chemistry, Computer Science… we all have runaway textbook prices that are crushing our students.) They send $300 every semester to the publishers. It is simple to see why publishers want DRM: they don’t want kill the cow that lays geese that lay golden eggs.

At a college of 2000 students, that means students are spending

$1,200,000

per semester on books. The college has no direct control over this cost, and there is no incentive for faculty to keep costs low for the students. I managed to offer both of my courses this semester using only Creative Commons licensed texts… but there aren’t a lot of those I can choose from.

The thought game became this: why haven’t small colleges come together and established a free press? They could hire an editor or two, some typesetters and indexers, and then commission books and short monographs and release them into the Creative Commons. Authors taking part could be rewarded better than any publisher could ever pay for this kind of material, and the impact on the educational world would be huge.

the ipad arrives

201001280716.jpg

The iPad isn’t a revolutionary game-changer, but no doubt Apple did some things right with its design. It does web and video well, and it is possible to pay on a month-by-month basis for connectivity to 3G networks. (Nice if you’re going on a trip and just want roaming wireless for a month.) And while $500 sounds expensive, think about it this way:

$500 is $50/semester for device and insurance.

If an institution commits to ebooks—meaning, all the faculty agree that they will commit to finding electronic texts to teach their subjects—we can slash student book fees drastically. We raise the floor, meaning they have a mandatory $50/semester technology fee. However, we then have 2000 students with a wireless slate that can display video, play audio, surf the web (campus WiFi), display PDF, Google Docs, read email… the list goes on and on. To me, it seems like a very compelling vision.

In terms of the device, I don’t really care if it is the Apple iPad or not. If Steve wants to send me one to use and evaluate, he’s welcome to. I’m a Mac owner, have a Touch, and think this could be an excellent device. But I also know that Mary Lou Jensen has developed some incredible technology at Pixel Qi, and an Android- or Linux-based device could do everything I’m suggesting just as well. So, put simply, it is currently an exciting time for devices that are bridging the gap from laptop to slate.

Peter Klein over at Organizations and Markets wonders aloud:

It’s easy to come up with examples of organizations run by jerks that failed, but do we have systematic empirical evidence that nice-guy firms finish first? Do the marginal costs of costs of placing rude, self-centered people in management positions outweigh the marginal benefits?

It is likely that Peter is already familiar with Robert Sutton’s The No Asshole Rule. If he isn’t, either 1. he’s forgotten what it is like to be a hazed and harassed junior member of the faculty, or 2. he hasn’t read it. In my experience, “assholes” (a technical term from Sutton’s text, which generally means what you think it means) are capable of slowing down a department or organization (by blocking forward progress on all manner of issues) and are happy to use their position to abuse or otherwise demean anyone who they view as less than themselves.

There is no value in an institution to people like this. His example of a “self-described Law school asshole,” drawn from Mendelsohn’s own reflection (PDF link) does not match Sutton’s definition:

University of Pennsylvania 3L Steve Mendelsohn (writing in 1990) tells his fellow students: “You know who we are. We’re the ones who always have our hands up in class volunteering to answer the professor’s questions, or ready to ask one of our own at seemingly any and every opportunity. Everytime you hear one of our names called, you groan and turn to the person next to you and slowly shake your head from side to side.”

This is not an asshole. This is an engaged student. Being passionate and engaged in ones subject of study is exactly what I want my students to do. I don’t want passive consumers of information in my classroom—which, it sounds like, is what the culture of law schools encourages. I want critical questions, I want debate, I want a room full of critical thinkers who use the time we have together in the classroom for more than consuming information that I pass on to them. When I want to do that, I create a video and point my students at it. It’s far more effective than giving lectures over and over.

People who are driven, who know there is a better way, and who work hard to achieve that even when it means shaking up the status quo—those people are not assholes. They’re innovators. Catalysts. Activists. They’re the people who make things happen in this world. The problem is, for someone who is passive, and just wants to leave well enough alone, the innovator is an asshole.

In short, I respectfully disagree with Klein’s terminology. Only in an industrial-age classroom, where the fount of all knowledge lives at the front, dictating from yellowing notes written before the beard was greying… only there can an engaged and passionate student be labeled an “asshole.”

Update, slightly later: Peter’s question is about organizations, not classrooms. I got distracted by his example. I doubt that “productivity,” “creativity,” or any other way of measuring the value of an employee necessarily correlates with whether they treat their colleagues poorly. (Highly productive people want to see others be the same; only assholes want to make sure that they are recognized as the local expert/value proposition within an organization.) I would be interested in seeing any research that demonstrates that middle managers or those throughout an organization who abuse their power, and therefore their colleagues (passively or actively), add substantial value to the workplace.

All boats rise with the tide. If my colleague is excellent, it makes my workplace better and my institution more successful, and I have a better chance of demonstrating my own excellence as well. Only those insecure in their person need to put others down or hold them back in order to define who they are.

In the preface to The Art of Computer Programming (1969), Knuth wrote the following:

100103-knuth-preface.png

I would posit that the vast majority of students who complete an introduction to Computer Science (often heavily focused on introducing the practice of programming) would not say that they felt they had been exposed to an aesthetic experience much like composing poetry or music.

This next term, I hope to work on developing a new course at Allegheny titled (tentatively) Digital Creativity. This course could serve as a pre-intro to the major, or introduce non-majors to the beauty of programming and computing, providing a collaborative, cross-disciplinary, and creative grounding in computational thinking using tangible, physical artifacts that students can relate to directly.

Omer passed on this picture:

P1000065.JPG

That is a concurrency.cc Arduino-compatible board fired up and ready to go. As you can see, the vias aren’t really lined up that well, which may account for some intermittent USB-to-serial weirdness that he is chasing down at the moment.

Awesome job, Omer! If all goes well, I think we’ll have around 40 to 50 students at Allegheny building their own computers next semester in courses I’m teaching or co-teaching, another handful at Kent, and who knows… perhaps I’ll find another place to bring these into my students’ experience next term.

I remain hopeful that our final boards will be purple, and that the ability to expressly direct parallel code for an affordable embedded platform like the Arduino will be of use to many. One step at a time, though: we need to get revisions done on our existing book chapters, write the next five we have outlined, get Windows and Linux distributions done… it seems like a lot, but we’ll get there.

I’ll have to write a longer reflection at some point, but the long and short is that I’m very excited to see our project coming together on multiple fronts for distribution: robust software, source-to-binary builds, hardware that showcases our tools, and a text that provides structure and guidance for non-programmers to get into hardware exploration one small step at a time. When you start a project like this, you want all of these things from the start… but sometimes, it takes lots of small steps, side explorations, and unsure starts to get you to where you want to go.

Operation: Stick Figure Army is a project that will provide tools for converting 2D imagery (as typically found in many introductory computing texts) into 2.5D representations: physical tiles with raised and textured surfaces that represent one or more diagrams from a text. This lets us explore, as a group, image processing, 3D printing, and the process of creating usable software for a target class of user.

The project is being carried out by two students at Allegheny and one student at TCNJ. Sara and Stephanie (Allegheny) have spent this semester learning Python and basics of image manipulation, recently posted their experiences while exploring Blender’s Python API (so we can automate the process of 3D object generation), and are beginning construction of their Cupcake CNC 3D printer. Cory (TCNJ) has also begun looking at Python, and is (at the moment) providing critical reflections on what it is like to be a blind student of computing.

His most recent post on the project blog, How to cope with the design phase?, explores the notion of visual representations in computing. I found his reflections interesting for two reasons. First, it reminded me of a paper by Marian Petre and Alan Blackwell titled Mental Imagery in Program Design and Visual Programming (PDF) (International Journal of Human-Computer Studies, 1999 (51) p7-30). They explore the role of visualization and visual language in expert programmers, and while the paper is too rich to summarize concisely, I’ll pull most of a paragraph from the conclusion here:

There has been a great deal of confusion in the visual languages community about the relationship between mental representations of a design and the programming notation. As noted by Green, Petre & Bellamy (1991), the superlativist position (claiming that visual languages always improve performance in programming tasks) is not justified by experimental evidence. Blackwell (1996a) has analysed the variety of beliefs among visual language researchers about the cognitive effects of using different notations. These tend to range far beyond the practical benefits of the notation or the programming paradigm, but their statements about mental representations bear little resemblance to our findings in the present studies.

Put simply, we tend to get all hot and bothered about visual tools, but research doesn’t imply that this is always a Good Thing.
The second aspect of Cory’s post that I thought was important to reflect back was the importance of verbal communication in software design and development. Whether it is aural or written, being able to express ideas about the design and implementation of software is critical to students of computing today. In some circles, this comes out in the context effective communication and collaboration in teams (Begel/Simon, Struggles of new college graduates in their first software development job (PDF), ACM SIGCSE 2008). Regardless of whether it is a software team at Microsoft or a distributed, community-driven effort surrounding open source software, the overwhelming majority of our communication and collaboration regarding software developing is written/verbal, not visual. That is, we’re not shipping pictures back-and-forth 24/7—we’re chatting on mailing lists, IRC, and blogs to get things done.
I think these ideas say a lot about where we are failing in terms of computing education today, but that will have to be the subject of another post. For now, I found Cory’s words thought-provoking, and wanted to reflect a little bit on what he had to say.