Can Professors Teach Open Source?

No readers like this yet.
Flying textbooks

Opensource.com

At teachingopensource.org, we think so, and we wrote a book to help.  The following excerpt comes from the Foreword of our new textbook, Practical Open Source Software Exploration, which is licensed under Creative Commons BY-SA-3.0.  It's a book that works like an open source software project.  In other words: patches welcome.



In March 2006, David A. Patterson wrote an article entitled "Computer science education in the 21st century." David A. Patterson was, at the time, the president of the Association for Computer Machinery, the world's largest educational and scientific computing society.  In his article -- which, sadly, you cannot read unless you are an ACM member -- he advocated for fundamental changes to how computer science is taught. One of the changes for which he advocated: the inclusion of open source software development courses in the standard undergraduate computer science curriculum.

One might think that such a clarion call, made by someone of such obvious influence, would generate a groundswell of enthusiasm. When the president of the ACM proclaims that it is "time to teach open source development," the world of academia must certainly follow, yes?

It's a little more complicated than that.

We've spent a lot of time over the past few years talking to computer science professors. Mostly we've asked lots of questions -- actually, the same ones over and over.

  1. Do you use open source software in your classes? (Increasingly.)
  2. Are your students interested in open source? (Increasingly.)
  3. Do you or your students participate in open source software? (Rarely.)
  4. Do you teach open source development practices? (Almost never.)


For these last two, the follow-up question is, invariably, "why not?"

And the answer is, invariably, "because it's hard."

There are good reasons why professors don't teach the practice of open source. It's easy for open source advocates to explain away these reasons. At a certain point, though, one must accept the idea that most professors are well-intentioned, but bound by circumstances that make it frustratingly difficult to introduce students to open source development.

So why bother?

The answer is simple: the skills required to succeed in an open source software project are the exact same skills required to succeed in any large software project. The biggest difference is that, with just a bit of guidance, anyone can build their software skills in the open source world.

We hope that this textbook helps provide that guidance to a whole generation of students who want to learn how to become better software engineers, the open source way.

Tags
User profile image.
Greg DeKoenigsberg is the Vice President of Community for Ansible, where he leads the company's relationship with the broader open source community. Greg brings to Ansible over a decade of open source product and community leadership, with the majority of this time spent building and leading communities for open source leader Red Hat.

13 Comments

Boy, do I wish I had this guide when I was a freshman in college!! This is awesome. I do have a little nit, though... :)
<cite>
4. Getting the <strong>Code</strong>, by Greg DeKoenigsberg and Mel Chua
5. Building the <strong>Code</strong>, by Greg DeKoenigsberg
6. Debugging the <strong>Code</strong>, by Greg DeKoenigsberg
7. Fixing the <strong>Code</strong>, by Jeff Sheltren
8. Explaining the <strong>Code</strong>: the Art of Documentation, by Karsten Wade
</cite>

We need a chapter or chapters on open source <strong>design</strong> too, don't you think? ;-)

There's a <a href="http://flosshci.org">FLOSS HCI workshop</a> next week at ACM's CHI conference in Atlanta. I put together <a href="http://mairin.wordpress.com/2010/04/06/contributing-to-free-open-source-software-as-a-designer/">a case study</a> (with tons of help from Mel :) ) on some of the issues and suggestions for designers in open source communities for it - do you think it could be a good start?

While it's a specific goal of the meta-work <em><a href="http://theopensourceway.org/wiki">The Open Source Way</a></em> to go beyond code, the <em><a href="http://teachingopensource.org/index.php/Textbook_Release_0.8">Practical Open Source Software Exploration</a></em> textbook has to start somewhere for a specific student audience. While many audiences are under-served, it is to me one of the saddest shames that people studying <em>computer science</em> aren't learning about participating in open source. That's why I was satisfied with the initial scope and release.

I come to this agreeing and having worked in similar circles with Máirín on getting open source projects to think beyond "code is king". As one of the editors of <em>Practical Open Source Software Exploration</em>, I know it won't be as easy to remix the current content for a non-coding audience. However, it can be done, and it should be done. In fact, I think the title itself lends room for inclusion of parts (groups of chapters) dealing with non-coding parts of FOSS projects.

Then it's fairly straightforward to identify a subset on the wiki and make different books based on the same content, for different audiences. The greater the quantity and quality of chapters in the pool, the more student audiences can be reached with the textbook.

A way to go from here would be:

<ol>
<li>Create a new design-focused textbook landing page on the Teaching Open Source wiki.</li>
<li>Create a table of contents for the first version of the book, looking to reuse existing chapters from the other book.</li>
<li>Where the title of a chapter conflicts with the design focus, try to work with the upstream chapter author to fix this. For example, could we rename all the chapters to e.g. "Explaining the Source" for the documentation chapter? Does that make sense to a design audience?</li>
<li>Where the chapter title doesn't work, just create a new container chapter and use the MediaWiki include mechanism to pull in content.</li>
<li>Around here slot in the design-specific chapters we do have already, such as massaging the case study you reference.</li>
<li>With that half-day or day's work we can get some percentage of the textbook already underway or nearly done, and have an idea of how much work there is to do.</li>
<li>Start recruiting writers, then write the needed content.</li>
</ol>
If you like this idea, perhaps offer it as a challenge to Fedora Design Team and to other design communities you know. I volunteer to help with the MediaWiki wrangling, gardening, and understanding of the content for remixing. (It helps me in my goal to write a "how-to-remix this book" appendix.) We can do the conversion to DocBook and get the pretty Fedora branding (or whatever brand) in PDF, HTML, and Epub formats.

because open src is more like viral activity than anything start from architectural understanding

i mean if the professor is infected, then he can infect his student more easily

while actually, most of them are immune to open src
because it's hard to teach sth that only valid for several days/months
instead, only theories or even super old architectural understanding could lead to long term memory

that's why it's hard to bring open src to academia
maybe 30 yrs later.....when open src is proven moving objects
XD

then we may have angular/circular development feels like some physics lessons

XD

The vibrant dynamics of open source poses a problem to universities to include open source into the undergraduate course. The ever changing nature of open source require constant up-gradation, and hence is the major distraction of professors/tutors. Meanwhile, a general nature of human, to oppose change, also prevents the academics to go for it. Though there have been some progresses on this, mostly in developing countries where open source has been started to be believed as the only way to go. Even though it's a long way for open source to get included in the university.

But not as true as academics would have us believe. The nature of particular open source projects are often changing -- but open source methodology itself is actually quite well-developed. It's just that no one has bothered to describe it to academics in a suitably academic way. That's our task, and we can't give up just because it's hard. (And make no mistake, it is hard.)

but open src-ers already know how to join the community and develop....
seldom open src-ers were told to do sth...*x*
they just go to code and discuss PRO-ACTIVELY
they don't wait for a degree or master for doing anything

they are the REAL MEN (incl. WOMEN)

...because my first experience trying to get involved in an established, well-known open source project was so unpleasant, I didn't try again until five years later. It was that bad.

If I had a guide like this at the time.... I wouldn't have been so discouraged and lost all of that time!

that's "open src-ism" already
u may join by interest
or u may not join
or u may join by forking a project ... leads to your own interest

that's not a problem
that's the way it's going

just try to figure out how u interact with the community and how it feeds back

it does not fix or limit anything into a "box"
open src itself is like liquid

free-form and eventually reaches its well-form
when it breaks, it means it will go into another free-well-form

feels like water drops and leads to waves

that's part of modern viral marketing would like to intimate...

From my limited academic experience in the North West, I have come to three possible reasons why Open Source is not taught even though professionally the tools and skills will be a main stay in the graduates profession. <a href="http://seniorenhandys.blog.de">Emilie</a>

I think not only they can, but they should be teaching open source methods and practices. And I think they could be teaching within open source communities.

There are alot of soft skills involved in interacting with an open source community that are professional real-life skills. They can, as Honey suggests, tough it out and learn it on their own... But why can't we integrate this into formal education?

Graduates are often left to do this exact thing: after they leave school, they finally start developing the 'real' skills they need.

Bringing students into the <em>wild</em> of open source during their education can reap great benefits for them. They can find like-minds, make professional connections for work, make personal connections for support- and find their way in the world.

There are many are skills and abilities that can be developed, beyond the code.

Thanks for your response, it mirrors some of my thinking after reading <a href="https://opensource.com/education/10/4/can-professors-teach-open-source#comment-1271">Honey Mak's comments</a>. Because of the wild and natural roots of open source software, many of the pioneers there have that hardy, do-it-yourself attitude that doesn't understand people who are not like that. Those of us who followed these first pioneers have an affinity for that attitude, yet that attitude can be a barrier to a sizeable portion of the population of potential contributors.

> They can, as Honey suggests, tough it out and learn it on their
> own... But why can't we integrate this into formal education?

Singling this point out because it's about something that has been on my mind for the last few years. My friend and colleague <a href="http://blog.melchua.com/">Mel Chua</a> talks about "invisible segfaults" in community. Just as a bug in code might cause the software to silently break and quit, a bug in community interactions can cause that in an individual. Every time someone looks at a community with an eye to participate, and is repulsed either directly, indirecetly, because of an unintended barrier, by hitting an -ism (sexism, ageism, racism, newbieism, etc.), or just about anything, and if that person then goes away without anyone knowing why (or that they were even there and left), it's an invisible segfault.

Sadly, people seem wired to resist seeing, understanding, and changing the conditions that cause the community invisible segfault. Sexism is a good example of a tought problem, because it is more ingrained and less obvious to those being sexist than other discrimination, and many of us are sexist "without meaning it." In reality, it's about how we make people feel unwelcome by identifying and acting differently based on real or perceived differences between people. If I start talking in a fake/parody accent to mimic every person who comes to talk to me about my open source project, it is pretty clear that i) I'm not Robin Williams and it's not remotely funny, and ii) maybe I'm a bit racist or at least culturally clueless. But if I start talking to every woman or young/old person as if they don't understand technology, as if they are an object and not a person, as if they don't belong because they aren't one of the guys-like-me, people don't perceive that as inappropriate (not-Robin Williams) and sexist. Well, some people do, but just as many others don't, and they give the <a href="http://geekfeminism.wikia.com/wiki/Category:Excuses_for_sexist_incidents">usual list of arguments</a>.

It's an obligation of everyone to make our free and open world a welcoming and safe location for those who stop by. We'll find more of them stick around.

we have a BIG...super BIG open src community...feels like entire human population in the world...

"the world" in this case = open src community
but we have different people from different nations...
we have some values that we understood and universal
but we have some differences too

it's not necessary to integrate personal values deeply into project building...though that could be little bit tricky in words....

but it's free to fork...
it's great that if someone really leads the way...
but if not, then you will be your own lead...if you are tough enough...then you reach it...if you are not tough enough...that may find yourself actually not quite really interested in the topic...feels like the great Edison making the very 1st lamp?...today's open src development is way far easier...

open src just works like daily life....you will buy something from stall A...you will buy another thing from stall B...you won't just look for everything in one single place....

what open src brings is real freedom...you can make it commercial and stick with it...when someone doesn't like it...then just make another stuff...

if take this mechanism a little bit more optimistic, any open src activity is actually trying to bring a better world....unless just stealing from the src and never contributes...

because through open src development, actually a social model is being built as well...different circles for different topics, AND different specialists and different open src "schools" or triangular stepping stone model for "community career" building as well....

From my limited academic experience in the North West, I have come to three possible reasons why Open Source is not taught even though professionally the tools and skills will be a main stay in the graduates profession.

1) MS kick backs - Free or mostly free software to use. To me this is not a very good reason since MySql and Linux, etc. are all free as well. But I suspect part of the MS deal is that the schools needed software outside of the classroom training products are subsidized as well so long as the school uses MS products throughout without much other emphasis.

2) In my experience and especially in the state I live, many professionals that know and use Open Source professionally do not have four year degree's let alone masters. Universities do not want experienced professionals, they want academic professionals so they won't hire the ones with the knowledge.

3) Because of numbers 1 & 2, the only qualified professors that are/can be hired by the Universities are trained and experienced with MS based software only and have limited exposure/experience with Open Source software. Therefore, they do not know or feel comfortable enough teaching with or about Open Source outside of the traditional sound bites.

I realize I could be wrong and that my exposure to this is limited to one location and one institutions policies but I can't help but think there is some relevance and similarity beyond the one institution I attended.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.