This first checklist, Organizing a community – checklist, is derived directly from the chapter, How to loosely organize a community. It is focused on the first work that needs to be done to get a community started and ready for sustainability. I’m sure it is incomplete, which is why I’m putting it out there in hopes that those of you-and-I who care will comment here … or on the project mailing list … or even come do some fixes on the page yourself.

Two caveats:

1. This might be done better somewhere else. If it is freed and opened enough that I can include it, I would like to. At the very least, a link on the references page would be good.
2. This checklist is for any type of community interested in emulating the success of free software and following the open source way. As such, it is a generic checklist and does not dive in to specifics that matter to any one domain. Such as software development. So, for example, don’t tell me that I missed the “licensing” section. Not all communities have copyright works to license. What is a general way to handle that question? Let’s put that in the book.

To start that off, I am doing what I can to improve the roadmap page, just finished pushing out the communications plan parts that I can commit to, and have started a discussion on the mailing list about the roadmap and comms plan.

What I want to drive toward next (and very soon!) is a release schedule. I really do want to chop down and pulp up some trees (or use all post-consumer grey paper) to put out some actual handbooks you can hold. But that requires more of the content to just be there. (I don’t really want to print with any ‘example needed‘ sections.)

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.

The modern seed exchange movement has a lot of history and current value:

• Keep seeds available that may disappear – cultural heritage.
• Sharing of culture in food.
• Maintain or increase biodiversity.
  • Compared to certain hybrid seeds that require going back to the seed manufacturer every year, who may have patented the seed.  Be aware that if you get the genes from those seeds crossed in to your open pollinated plants, you may get sued – and lose. (references needed)
  • Very comparable to other open v. closed systems – software, music, herb/pharma, etc.

Open pollination and hand pollination (controlled) have a long history.  One increases biodiversity through evolution – shared genes and selective breeding by environment or humans.  The other is about unlocking the secrets of the genes, increasing our food supply and diversity in sustainable ways, and caring for the ecology.

Humans are wordy people, and the effects of a word that contains “mort” in it is to be focused on death.  A postmortem is an autopsy – it can only be conducted on something after it is dead.  That’s the very definition of the word.  In using it, we talk about the body of our work while implying death. Not healthy!

I get that it has a popular usage, but why follow the trend and refer to our release process as death?  It’s not even a lifecycle, it’s many lifecycles.  It’s an ecosystem. Fedora is a living project with a regular rhythm.  The only death we see are ideas, both good and bad, before their time, or just in time, or long overdue.

Some alternatives to postmortem:

• Post-analysis
• Release review
• Post-game analysis (sports metaphor)
• Sanity check
• Pause for the cause
• Happy hour
• Post-release analysis
• Release feedback
• Post-release loopback
• After the fact
• Hindsight meeting
• Safety check
• Loopback review

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.)

My sense is that Publican is in good shape for groups to adopt and extend.¹  For example, there was a recent discussion in a MeeGo developer list about what tool to use for end-user help on the device console.  The first version of this help documentation for device users is going to be written using RoboHelp, a proprietary platform that has long been used for this type of capability.  (The thread does a good job of explaining the reasoning.  From my perspective, Intel and Nokia are showing thinking that is evolved and learned from the old days, such as when Red Hat Linux became RHEL and Fedora.  It shows they are learning how to use the open source way.  I’ve met and had discussions with various community facing folks from Intel and Nokia over the last few years, and they were listening and talking the open source way.  Interesting to see how others handle the experience.)

It seems like a good extension of Publican to handle this sort of help output, and if the MeeGo community coughs up a Perl hacker it can probably create the functionality relatively quickly.  Publican has been designed by the Red Hat Engineering Services team to support a need to deliver source documents + translated strings as multiple target outputs.  I’m sure it can be made to match the i18n requirements of the MeeGo documentation folks.  (I just learned that Publican has an EPUB output format, no reason it can’t be easily extended to a ‘help’ format.)

In the MeeGo thread, Dave Neary says,

Im (sic) my dream world, there would be a web application with a wiki-like interface, which would be a view to docbook sources, where changes were sent to a submission queue rather than being immediately displayed, where a maintainer could review and modify/reject/accept proposed changes, and anyone could view the review queue to see what the status for their proposed patch was. I don’t know of any such application

Dave, I think those components exist and only need a little bit of glue to work for you.  Publican plus an SCM on the back-end with Beacon running as a WebUI wysiwyg front-end.  In the summer of 2009 Satya wrote code that extended Beacon to support a subset of DocBook that the Fedora Docs Team identified as most used inline and block tags.  You plug Beacon in to a CMS as an editor to handle a writing/editing/l10n/publishing workflow.  (I think the CMS needs to handle the check-in/check-out with the SCM on the back-end, making the XML files available for edit, and probably adding a commit button in the chain so files can be saved as they are worked on without triggering a nonsense commit.)

We’re working on implementing Zikula in some CMS roles for Fedora, and I hope to see us adopting the Beacon editor there as a choice for writers.  This is going to be a whole new effort, and I’m waiting on the first Zikula instance, Fedora Insight, to be running before rallying more support via the SIG.

• 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.

So I thought about doing a post on Lana, even though our paths have barely crossed.  She’s a great writer, she brings passion and dedication to technical writing, and is an excellent advocate for FOSS documentation.  Aside from being one of the writers on the stellar Red Hat content team, Lana has been recognized as a top FOSS writer.

She also wrote a post today that was sort of an Ada Lovelace Day tribute.  It was about the Unicorn Law.

From Ada Lovelace Day 2010: Unicorns -

Often, when a woman joins an all-male technical environment, they will look at her strangely. They might try and pretend that she’s a bloke, that she’s just ‘one of the boys’. They might ignore her. They might make a few distasteful jokes and then get on with the job. But mostly, what happens is that a woman is noticed.

Had my own cross with the Unicorn Law recently.  The law states, “If you are a woman in Open Source, you will eventually give a talk about being a woman in Open Source.”  I didn’t learn about this law until after I had agreed to have my daughters talk at SCALE 8x about … being girls in open source.  *sigh*  It was a great experience for them, and I’m sure mainly good will come from it, but the whole realization that I had pointed them out as unicorns without even realizing it was disturbing.

Today I’m feeling that same way about writing this post.  I wanted to write something, I decided I wanted to write about Lana Brindley because she is a woman in FOSS computing and works in a field near and dear to me.  She seems to have come to her writer’s passion honestly and serendipitously.  Reading about her life, I realize in many cases I could substitute myself in to her story, it has so many similarities, all the way up to seeing pictures of her plans to build a chook shed in her backyard where she gardens, grows, and consumes slow food.  (Hey!  Just like us! We have a chook shed, too, although we Yanks call it a chicken coop, and some of our hens prefer to lay outdoors. We have an urban farm with underground restaurants and pop-up events.  Small world.)

I’m not sure if Lana meant the irony in writing about unicorns today, most likely she did.  It has made my writing experience today all the more ironic.  It’s nearly Midnight here in California, my last chance to either finish this post or throw it away.  I set out wanting to give tribute to a colleague whose work has helped and inspired me, and now I’m feeling as if I’m also calling out her as an Other in just writing this!

Anyway, I’m confused, but that’s just me, I’m a newbie geekfeminist, this is not entirely an Ada Lovelace Day tribute, and thanks Lana for the words and wisdom.

This has been on my mind for a while, and in a discussion with Mel after she did the same thing, I realized it was time to fish or cut bait.

The bottom line is, I don’t know what value my content can bring beyond what it’s done for me already, and I’ll never know unless I assign the rights so that others can reuse or build on my work.  I am specifically not using the no-commercial use (NC) variant of the CC license; most of my reasoning is inline with this article from freedomdefined.org.

If there any bad actors who would use the free content license in away against my interests or preferences, I have to figure that i) they would do it anyway and regardless of my licensing, and ii) who am I so paranoid of?

Seriously, when you have a choice to spread peace, love, and understanding or fear, hatred, and doubt … choose love.