I’ve been having a difficult time getting organized and starting the big work on the next edition of the textbook. However, my recent calls for help have gained a fair amount of attention and multiple really good offers, so we are clearly underway again.

My goals in calling for this first sprint are to:

1. Start a writing rhythm for the team;
2. Take care of some administrivia (decide upon weekly work times, order of work, etc.)
3. Get some initial writing done that may still help the Teaching Open Source professors who are using parts of this textbook this school semester.

See you on IRC bright and early (for me) on Monday!  (This weekend is the end of daylight savings in most of North America.)

Do you want to help us write the next version of the first textbook that teaches open source participation?

We need writers, editors, reviewers, and researchers to find or create content on:

• Testing code in FOSS communities.
• Working in open communities.
• Different types of open source community cultures.
• Open communities and diversity.
• Licensing FOSS  code.
• Threats and risk analysis of FOSS as a technology choice.
• FOSS business models.
• Determining program requirements.
• Designing FOSS programs.

Join the mailing list and let us know what you are interested in, or you can email me directly.

Note: The textbook Practical Open Source Software Exploration is licensed under the CC BY SA 3.0 Unported.  We are very interested in reusing and modifying existing content that is compatibly licensed.  This is especially true if we can use the content as an active downstream.

Tl;dnr version follows …

Earlier this year we released the first usable version of a textbook, “Practical Open Source Software Exploration”.  This book fills a need that we hear about repeatedly from educators — there is no other standard textbook that teaches how to actually participate in a free and open source software (FOSS) project.

Although that first release, 0.8., had some problems, it was pretty solid in terms of having practical material for students to work through to check out code, build code, debug code, submit a patch, and write collaborative documentation.

However, in a meeting earlier this year with Tim Budd and Carlos Jensen of Oregon State University, Dr. Budd noted there was really only enough material in the book to teach a few weeks of classes.  It was so practice heavy that a student, unless they ran in to technical problems, could go through the material relatively quickly.  The book was extremely short on the other material a class needs — the theoretical side.  It was missing material on the history, culture, types of communities, diversity, licensing, business models, and so forth.

Working with the professors who are using or planning to use the textbook, we figured out what the new chapters needed to be.  Much of the material for those chapters probably exists already, some may be under a CC license we can use, so I’m hoping a good portion of this chapter work will be reusing and rewriting existing materials as a downstream.

We cooked up a poster and information packet you can read, use, and pass around.  It’s mainly about getting people to the main POSSE Cali page, then to apply.

Otherwise, we are looking for attendees.  If you know any educators or good networkers around education, please pass on the information.  We need to get more people, it makes it better for all involved.

We’re having the West Coast’s first POSSE this 5 to 9 July in Mountain View.  I’ll be there as an instructor, as well as Alolita Sharma from the OSI, and my colleague and POSSE co-founder Mel Chua.  If you come, you’ll learn about how to become productively lost, which is the key to navigating myriad free and open source software projects.

While you are thinking on that, think about these three reasons POSSE is attracting so much interest:

1. POSSE doesn’t solve all problems that academics face, but it works really well in a particular area.  If you plan to teach a class that includes open source development, or are even considering it, POSSE is the workshop for you.
2. The POSSE curriculum is very broad and applicable from the largest and most prestigious four-year research schools to two-year community colleges or even advanced science high schools.  This is because, like learning to ride a bike on city streets, we all need the same basic skills and experiences.
3. Being an alum of the class provides you hooks in to the POSSE community, which is at the crossroads that the Teaching Open Source project has been slowly occupying over the last few years.  This crossroads is where community leadership from the open source and academic communities are learning from each other and creating programs such as POSSE and the new textbook Practical Open Source Software Exploration: How to be Productively Lost, the Open Source Way.

Attendance is free, and you have to cover your own travel, meals, and lodging — one reason we do these regionally is to get a larger local draw so that more POSSE events can be held in the region as academics spread the word over time.

If you are in California this July and want to learn how to teach your students by working with codebases and collaborations from the real world, we invite you to join us and apply for POSSE California.  POSSE focuses on teaching educators how to be participants in open source projects, from tools to social rules.  This is done by actually contributing to a free and open source (FOSS) project during the course of the week long class.  The course is taught by instructors from Red Hat and the Open Source Initiative.  To learn more about the program, read the main POSSE page.

• Practical Open Source Software Exploration: How to Be Productively Lost, the Open Source Way is a textbook aimed at classrooms, as well as useful for self-learners.  Educators can remix the content, customize it for an environment, and even do all that live with students.
• A K12 Educator’s Guide to Open Source Software is an updated list of free and open source software and resources that K12 teachers can use immediately in the classroom and on any operating system.  The PDF from Máirín’s blog post is focused on design tools, such as for vector illustrating and bitmap painting and image manipulation.¹
• The Open Source Way:  Creating and nurturing communities of contributors is a handbook you can use, remix, and contribute to.

This week, Dr. Tim Budd at Oregon State University (and member of the Teaching Open Source community) began using the textbook for a class introducing FOSS programming and contributing.  We’re looking forward to getting feedback from the students.

Being a 0.8 release, it has a few bugs (formatting, mainly, but also some links in one chapter); I’m planning a 0.8.1 update over the next few days.  (The build broke while I was doing the final push out the door, so we had to ship what was published as 0.8 for students to start using.)  As a collaborative writing project, each of us focused on one or more chapters, and cross-edited for each other.  Greg DeKoenigsberg is lead writer and editor, and writing/editing was also done by Chris Tyler, Matt Jadud, Jeff Sheltren, Max Spevack, Mel Chua, and myself.  (I wrote/remixed the chapter on documentation, “Explaining the Code“, with source from Mel Chua and Lana Brindley. You can view the history of the wiki source/upstream for an idea of how it evolved.)  Jared Smith helped me with the wiki2xml conversion.  We used the ‘mw-render’ command from the ‘python-mwlib’ package, using the techniques we created for Fedora Project Docs Team.  (Thanks Paul for getting that package fixed in the nick of time.) It still needed manual clean-up for the final 0.8, but the automagic conversion does the heavy-lifting and gave something we could build with after only a little clean-up.  I converted all that to a Publican-based book, including creating a new branding package ‘publican-teachingopensource‘ using ‘publican create_brand’.  Working with Publican was a total pleasure.  It has matured nicely as a toolchain and is available for other Linux distros and other operating systems. I thank it for a good source package that I’ll be submitting as my first Fedora package.  (More on Publican in another post.)

Where Wikipedia is a useful information source and starting place for deeper exploration beyond it’s reference-focused world, there is so much more that can be done with it to help teach the open source way.

In fact, you can teach all of the basics of joining a collaborative free and open source software community without ever getting more technical than how to get an account and edit a wiki page.

Here’s the process I would follow, in a US-based classroom.  You can adopt to fit in your environment.  This is applicable to all age levels – I’d encourage six-year-olds to define a good Summary log message and click the Save page button.  A good reference is the Wikipedia article on creating your first article.

1. Use Wikipedia as a tool for learning the open source way by extending your use as a research tool.  In other words, let the work be topic driven and associated with your other lessons.  For this procedure, consider the example of a class studying their local watershed.  When researching with the students, use Wikipedia as a resource to understand the larger elements of the topic, such as what a drainage basin is, how topology affects the local watershed, what hydrology is, and what are the laws about protecting watersheds and wetlands.
2. The first thing you can simply draw attention to is that the page for “Watershed” on Wikipedia is a disambiguation page.  It’s purpose is to guide you to other pages because the term you were looking for is ambiguous in usage, that is, it has multiple meanings that each have a separate Wikipedia article about them.  You can point out that this is a collaboratively done page.  Both the history page and the discussion page are rich with information about who wrote the page, when it was done, and snippets of why it was done.  (This is where a good guide to Wikipedia for participants is useful, to help the teacher learn more about what history and discussion pages, for example, are for, how they work, why they matter, etc.)
3. As you proceed through research using Wikipedia, look for and explain these items to the students:
   1. Red links – these are pages that do not exist yet, meaning there is information to link outward to from the article you are reading, but that Wikipedia page doesn’t exist yet.
   2. Mistakes, such as typos, spelling, and grammatical errors.
   3. Unclear or overly complicated writing.
4. The first contribution from the class is likely to come from finding and fixing mistakes or helping improve writing:
   1. When a mistake is spotted, do something about it right away.  Login as your user (read more below), note for the class that you are logged in with different links in the upper right corner, and click [edit].  Make the fix to the page, and when saving include a short but detailed Summary such as:  “Fixed spelling of a few words and corrected punctuation mistakes, all spotted by students in my 2010 6th grade science class at Branciforte Middle School, Santa Cruz, CA.”  When you save this message, it is logged with the edit and that information, which is retained forever.  Twenty years from now, your students can look up the work you did together on Wikipedia long after they have discarded the work they brought home from class.
   2. For helping to improve writing, you want to defer the committing of changes to the live page to the people who write and maintain the page regularly.  This is one of the purposes of the discussion page that each article in Wikipedia has.  Use that link and edit the resulting page.  For example, to add a new section to the [[Talk:Hydrology]] page, click on new section and fill out the form.  Give it a sensible subject, such as “Fix for confusing paragraph in the history section.”  In the body of the form include an explanation of the problem (why it is confusing), a fix (your rewritten-with-the-students’-help draft), and your signature (four-tilde characters ~~~~ are used to sign and datestamp automatically.) Save this new section. Main writers of the page will return and read your new section, comment on it or make the fix, and so forth.  When they are done with it, they likely move it to an archive page.  Check back with our students to see progress on your discussion topic.
5. Once a class has witnessed the power of editing a wiki, and had the pleasure of showing the change to friends and family, they are ready for the next level, which is creating a new page.  This is where the red links come in, which are put there by other authors of Wikipedia partially as reminders, and partially as an invitation to write the page yourself.  For example, the [[Hydrology]] page has a prominent red link at the top to [[water chemistry]].  Following that link gives you an empty page ready to fill.
   1. A good first goal is to create a nice stub page with a basic definition of the article topic, and a reference to back-up the definition.
   2. To be safe and sane, you’re going to actually build the initial page in [[User:Yourusername/Water chemistry]], then rename it to [[Water chemsitry]] when is is ready.
   3. Start by copying the structure, categories, and so forth from the page source of the [[Hydrology]] page, viewable together by clicking edit for the whole page.  Empty the content, rename sections, and make it a template ready to fill with information about water chemistry.
   4. Find out the markup to put in the page that notes it is a stub page, a draft, and needs references.
   5. This is an opportunity to show research beyond Wikipedia, since the original information sources must be found to use for populating and referring on the new Wikipedia page.
6. Once a new page (article) has been created, and shown widely, the class is ready for considering several new ways to participate:
   1. Continue to watch and work on the articles the class created as article maintainers.
   2. Write up a new Wikipedia article (more than a stub).  For example, if there are unique properties to your local, named watershed and no corresponding Wikipedia article, you may think it is notable and should have an article.  Divide the class into small groups and have them research and write each section of the new page.  References are important, etc.  Essentially, this is a written report but the report becomes a Wikipedia article.
   3. Define and work on a set of articles.  For example, your local watershed may be part of a larger watershed system in your state.  An entire class semester could be spent researching and writing a series of articles to cover the larger watershed system and the individual components of it.

Teachers need a Wikipedia account, with a user profile at [[wiki/User:Username]].  You can make all the changes in Wikipedia on behalf of your students to provide anonymity to individuals and put the aggregate class work under a single copyight holder. The profile should keep track of the general information about the class(es) the teacher has contributed from, such as “Alan Parsons Project Middle School 6th Grade Science”.  This is part of showing other Wikipedia people who you are and what you intend to do so that you have their support as you continue using Wikipedia as a lesson in the open source way.  It also helps create the record of the class’ work, for example, when students are applying to schools later and want to show the work they did.

This is a very short guide to this idea, really just a starting point.  I could see this being a longer document, including step-by-step for the teachers on joining and learning about how to contribute to Wikipedia.  Let me know if it helps, how it could be improved, or if there is another free content work covering this content I could support instead.  Or should it be a Wikipedia article …?

• Use MediaWiki for writing long works and want to see how it is to convert to DocBook XML.
• Want to know more about using DocBook XML and the Publican publishing toolchain.
• Enjoy watching people edit XML like mad.

We’ll meet Friday 26 March starting at 1400 UTC in #teachingopensource on irc.freenode.net (or WebUI at http://webchat.freenode.net/?channels=teachingopensource) and continue through the weekend until done.  Full schedule and participation details are on the Teaching Open Source wiki.

As part of the work of giving college/university-level educators the experiences and tools they need to effectively teach participation in free/open source software projects, we’ve been working on a textbook.

http://teachingopensource.org/index.php/Textbook_Roadmap

The textbook, “Practical Open Source Software Engineering”, is releasing a first functional version, 0.8, this coming Monday 29 March.  The goal is to see it in use in at least one classroom this spring, which we’ve been discussing on the Teaching Open Source mailing list.

Taught by a Terrible Disease

This interested me for several reasons.

• We are all going to have phases in life where we are disabled, either in comparison to the rest of the world or by our own definition.   It’s cool seeing how people creatively use technology to not only re-enable but to improve their interactions and experiences.
• As a remote team member for the last 10 years, I appreciate seeing how people are able to do their work from remote.  In this story, we read of how the professor’s teaching has improved by being remote from her class.
• Open source methodologies provides a way for massive improvements in accessibility through various hackability efforts, such as the Open Prosthetics Project.

Sometimes the only way to show educators is by immersing them in collaborative experiences where they learn personally the value of open participation, such as POSSE.  It makes them better able to help their students become open participants when the students see the learning and modelling from the instructor.