A big part of researching and teaching about the open source way is being able to tell illustrative stories to bring home the reasons why you want to implement the principles. So the handbook has a chapter devoted to that, “Great stories to tell“. I’d like to keep doing more there.

One idea is to have a regular (twice-a-month) audiocast discussion about current events in the world and look at them with the lens of the open source way.

Ideally these would be stories beyond software and technology. There is so much transparency going on in the world, so many open collaborations, and so many stories of people doing things “just like they do in open source software.” That is what opensource.com is filled with.

So I need a partner, and some occasional guests.

A partner who can:

• Get on the mic with me a few times a month to discuss extemporaneously about current events and the open source way.
• Bely the extemporaneous nature by doing a bit of preparation with me – picking show topics, preparing links.
• Be willing to do the entire project the open source way – from tooling to how we make decisions for the show. The open source way doesn’t mean we give up control, but we do increase transparency to full.
• Grow the show with me and others’ help, including a point in the (near?) future where we do the initial recording live while engaging with a live audience.

Guests who can:

• Bring an informed opinion, backed up by facts, on the subject of applying the open source way to a domain of expertise or interest.
• Have stories to tell that go beyond just techology.
• Be willing to work on the show in the open source way, too.

Are you that person? Know of the right person?

About me, if you don’t know me:

• I can be very, very loquacious.
• I can be funny, but am (as is typical) much funnier with certain people than others. Being funny together for the show would be just awesome.
• I tend to talk too fast especially when I get passionate, but I’m a fairly good listener.
• I have a secret desire to be on the air.

I had a talk to give, “Decentralized Collaboration with Open Source Tools: Technical and Cultural Implementation“, which thankfully Robyn Bergeron is giving on Sunday, and I’m sure it will be at least three times more interesting than if I did it. (This was one I inherited from Mel and Sebastian when they couldn’t attend.)

This year I planned to give two workshops … and scrapping those is a big disappointment, but I will re-imagine them for next year.

The first workshop was a half-day mini-Professors Open Source Summer Experience (POSSE) focused on Sugar and the XO laptop. Save that one for next year!

The second was a half-day workshop, “How to teach the open source way“. I have a new idea for all my talk proposals this year, and for SCALE I wanted to try it as a workshop. The goal is to turn a round-table discussion about the open source way (including an introduction to the handbook) in to something more. For a 3+ hour workshop, the first hour is sharing experiences, learning about different viewpoints in the room, and capturing information. The second and following hours are hands-on the wiki and mailing list, adding content from the session (video segments shot live, stories written, chapters edited), creating new threads on the mailing list, etc.

Anyway, that’s my rocking idea – I proposed something like that for OSCON, for the Linux Foundation Collaboration Summit, and I’m going to propose something like that for everything this year. Even with 40 minutes or an hour, if I come in with an active plan I bet I can get people doing stuff in that timeframe that benefits everyone’s knowledge while benefiting the project.

*sigh* See you all next time.

If you’ve redistributed that website banner in any way, you must read on.

When we got the final banner for the website from the creative team at Red Hat, I wrote back asking for assurance that the components of the banner were freely reusable and redistributable so we could put the work under the CC BY SA 3.0 Unported license with the rest of the content. This idea naturally covers the fonts used – they must be free fonts or the whole image is not redistributable and remixable.

Today I was clearing out some old email and discovered a reply from the creative team to my request from March of 2010, with a new banner SVG file attached. The original banner, which was in use until just a short bit ago on theopensourceway.org, was using the non-free Interstate font. This new banner, now in use, uses the free and open Liberation font.

So I’ve updated the source files in the project’s git repository and I’ve updated the website itself.

Now the only concern is if anyone else has actually redistributed this banner under the expectation that it was OK to do so.

I made an honest mistake in that I am not very good at distinguishing between fonts, so I didn’t recognize that this was a non-free font. I also made the sloppy mistake of not seeing the follow-up from the designers, who did the right thing by all of us. While I’m sure I had the rights to use Interstate under Red Hat’s license, I probably didn’t have the rights to redistribute the image for remixing and further redistribution. It’s not that the file contains the actual font itself, just sixteen English letters of it in a scalable-vector graphic (SVG) file. I’m sorry and hope it causes no further troubles.

If you think you might have redistributed that banner or remixed then redistributed any images based on that banner, please contact me (directly via email or in the comments below.) I want to make sure you get the updated source files and that we follow-up with anyone else who might have the incorrect images in use.

Mark did some magic to stream a video of the proceedings,  so I was able to watch and lightly participate from remote.  Lightly because, as I predicted, the experience of being in the room was more magnetic to everyone than the video feed out/chat coming in. I expected this, since telepresence is often an audience situation unless it is a centerpiece of the meeting.

Since I was mostly just listening, I took what notes I could around the occasional stream drop, then posted them back to the CLS West wiki:

• The CLS West wiki page for the session with all notes merged
• The formal CLS West EtherPad instance
• The EtherPad instance I actually used to take notes from the video feed
• First section of video stream
• Second section of video stream
• Third section of video stream
• Fourth section of video stream

(I’m not going to embed any of the video because Ustream’s advertising spots are aggressive, so I wanted to give a warning before you get to the video.)

Of the two hosts, I know Bradley Kuhn from around the way and more recently as part of the larger group of voices discussing software freedom all over identi.ca.  As a latecomer to this new oggcast and not having heard their previous show, this was my first time listening to Karen Sandler (@kaz on identi.ca).  The two hosts have a good repartee, it’s clear why they enjoy doing this together, and they bring excellent information and insight to their topics, which mainly cover policy, legal, and related issues in the FLOSS (free/libre and open source software) world.  Sandler is the general counsel at the Software Freedom Law Center, and Kuhn is the Executive Director of the Software Freedom Conservancy.  So, it is literally listening to two experts in the field on FLOSS and its legal aspects discuss interesting and relevant topics.

Another reason I was inspired to write this post is in reaction to the latest show, where they discuss the issues and reasons around copyright assignment to appropriate non-profit organizations.  In their discussion around copyright assignment, Sandler had some strong points to make about how useful it can be in cases where code needs to be relicensed.  (To be clear, I understand their preference is, if copyright is assigned it should be to a non-profit organization, such as the Software Freedom Conservancy, that in turn makes contractual promises not to license the software non-free in the future.)

This topic sparked interest in me because of my own experiences relicensing the Fedora Project’s documentation from the deprecated OPL to the CC BY SA 3.0 Unported license in 2009.  In the post I wrote on the subject, “Why relicense Fedora documentation and wiki content“, I discuss clause 2(a) in the Fedora Contributor License Agreement (CLA), which I started referring to as “the nuclear option“, that allowed the project to sub-license contributions to the project under an equivalent or freer license.  Since the content we wanted to relicense (sub-license) was all new contributions (as opposed to content from an upstream), it was clearly something that could be sub-licensed under the CLA.

Without repeating all of the reasoning involved, it boiled down to this:

1. We achieved a wide consensus from the community that they wanted the relicensing;
2. We obtained permission to relicense from all substantive copyright owners (i.e., people who wrote the long guides not just short wiki pages) – even though they all had signed the CLA we considered it crucial that we have actual consensus to even proceed;
3. We didn’t bother to contact wiki authors/editors individually, but we did multiple loud announcements to give people a chance to know, understand, and make reasonable objections – it’s important not to surprise folks;
4. We used the nuclear option with great reluctance and only after effectively gaining the approval of the community.

This situation was necessary because the OPL we were using effectively put the Fedora Project on a content island, unable to interact with the growing body of freed content under the Creative Commons licenses.  The work coincided with the start of a review by Fedora Legal of the CLA overall, which has resulted in work to replace it with a simpler agreement that relies upon the acceptable FLOSS licenses and doesn’t assign these sort of additional legal rights to the Fedora Project.

So, the FaiFcast put me in mind of this situation where copyright assignment wasn’t involved, a different provision in the CLA was able to save us countless hours of work, and yet we were reluctant to use that provision and subsequently removed it from the next generation agreement.

Yet there is still a clause that seems to provide some protection against having to track down thousands of contributors in a future relicensing scenario:

The Fedora Project Board may, by public announcement, subsequently designate an additional or alternative default license for a given category of Contribution (a “Later Default License”). A Later Default License shall be chosen from the appropriate categorical sublist of Acceptable Licenses For Fedora.

Once a Later Default License has been designated, Your Unlicensed Contribution shall also be licensed to the Fedora Community under that Later Default License. Such designation shall not affect the continuing applicability of the Current Default License to Your Contribution.

Read the entire proposed agreement to understand all of the special terms, especially the very narrow definition of “Contribution”.  The goal, as I understand it, is to ensure continued freedom for contributed code or content by relying upon a simple agreement between the project and the contributor to use a permissive license now and forever.

If you are going to be at OSB10, I’m talking Wednesday 02 June from 1:30 – 2:15pm in Broadway.  I arrive Tuesday morning and am back out Thursday by Lunch, so a nice long window to talk free and open topics.

There appears to be a trend on this list where a random user just posts an inflammatory email with “ACME SOFTWARE IS RUBBISH”. Now, if the maintainer of that software is scanning the email list, bear in mind he (or she) has likely spent a significant amount of time and energy getting the software into the state you see it now. They probably spend evenings and weekend closing duplicate bugs and fixing trivial typos that people notice. If you title an email with such rubbish then the maintainer is simply going to ignore it or spam it. I’ll explain why:

The way open source software works is you get the software for free. If you don’t like it, you get your money back. If you want an additional feature, or a bug fixing really fast you either pay a Linux company like Red Hat or Suse some money and they assign a developer to work on it. If it’s a big feature it’s going to cost lots of money.

The other way is to join the software mailing list, and suggest the new feature, and “sell” it to the maintainer.

Believe me, this works.  It may be easier to do it yourself if you are a programmer.  But if you are a normal mortal like the rest of us, you have to get creative and find ways to get it done anyway.  If you aren’t going to pay someone, you have to make it compelling for them to work on it, and it really helps when you contribute something back to the effort.

Free/open source software (FOSS) has a way to do that.  Ordinary users have the power to affect change that matters to them in the software they use.

Wield the power wisely.

Tip one, ask questions and make arguments in a nice and respectful manner.

I’m thinking there needs to be an appendix or section or something in The Open Source Way about how to interact with a community to get things done.  That is arguably the scope for the entire book, but perhaps a good story or two would help illustrate.

As one good story of how an organization has learned from community interaction mistakes and turned that learning in to valuable contributor creating and scaling, check out Dr. Dan Frye’s keynote from the Linux Foundation Collaboration Summit.

That git repository is now available on Fedora Hosted:

https://fedorahosted.org/tosw/browser

You can follow our guidelines on how to get the source and how to build it, or if you want to contribute you can use this to-do list:

• Start by joining and talking on the mailing list.
• You need a Fedora account (FAS).
• Read Contributing to The Open Source Way and Converting to DocBook XML.
• Read Using git repository for detailed information.
• To get commit access, start by talking on list and submitting patches.

Short-cut available. If any existing committer knows you and your work, that committer can sponsor you immediately for a wiki account and access to the git repository.

On an unrelated point, I was finally able to build a favicon.ico from the SVG I got from Josh Gajownik, Red Hat stellar brand design lead.  Along with the clean site design, we finally have a look for The Open Source Way that I can hopefully translate to a Publican brand package.  We also seem to have a universal preference for two important acronyms:

• tosw – the open source way — lowercase usage refers to the community-defined methodology.
• TOSW – The Open Source Way — uppercase usage refers to the community-created book (wiki + rendered builds.)

Thus, keep your eyes out for the `publican-TOSW` package I’ll be working on.

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