Twisting the bytes

Some time ago, I read a paragraph on the book “Producing Open Source Software“, by Karl Fogel, explaining the need to write down conventions and agreements that have become essential for daily life in an open source community. In this way, people joining your community at a later point can quickly grasp its folklore and tacit rules (not only techincal rules, but also for social interaction).

Since the book is licensed under CC-BY-SA 3.0, I can post the following excerpt to illustrate the above point:

Don’t try to be comprehensive. No document can capture everything people need to know about participating in a project. Many of the conventions a project evolves remain forever unspoken, never mentioned explicitly, yet adhered to by all. Other things are simply too obvious to be mentioned, and would only distract from important but non-obvious material. For example, there’s no point writing guidelines like “Be polite and respectful to others on the mailing lists, and don’t start flame wars,” or “Write clean, readable bug-free code.” Of course these things are desirable, but since there’s no conceivable universe in which they might not be desirable, they are not worth mentioning. If people are being rude on the mailing list, or writing buggy code, they’re not going to stop just because the project guidelines said to

Well, I completely agree with this point of view. However, over the past years FLOSS has become quite popular among a broader audience. And we have to acknowledge that some of these new participants may not have this very simple, but fundamental perspective in mind, for multiple reasons. There have always been many examples of this kind, since human relationships are complex and frequently not as precise as we would need them to be in the digital world, without direct face-to-face interaction. But there was a general perception about a growing number of cases were good manner and politeness were flagrantly obviated, and not only in open source communities, but also in other open coumminites around free knowledge production.

That’s why this recent post on Jono Bacon’s blog quickly got my attention. Jono is the Ubuntu community manager, and he’s quite respected for his extensive experience in this role. He’s also the author of the authoritative book about Community management, “The Art of Community“. Once a year, he also hosts the Community Leadership Summit. I think these are strong arguments for taking his word for this. I really love this part:

I love to have a good debate, and I am never afraid to shake hands and say “let’s just agree to disagree” or calmly not participate.

In fact, a growing number of participants in debates (not only in virtual communities, but also in live debates, let alone TV shows) think that the ultimate goal is to completely convince the other interlocutors who don’t share their own point of view. However, the most positive side of debates is actually to exchange different points of view. Of course, there are key differences, depending on the topic. Sometimes, you discuss really technical stuff, and there are quite clear arguments in favor of a certain solution (for efficiency reasons, development guidelines, readability, maintainability, compatibility, etc.). But some other times, the arguments just express opinions on a certain issue, and there may be different points of view.

One way or the other, I think that this call for respect in open communities is really in place, right now. And thus I fully support its aim. Please, help to spread the word and preserve the healthy spirit of open collaboration around free knowledge.

Over the past 4 years, I’ve been an avid consumer of open content, mainly images and text licensed under CC-BY-SA (my favourite license ever). 90% of times, I collect it to prepare slides and other learning materials for university courses, training sessions, lectures or conferences (the other 10% is just for fun, since I love photography and I release all my works under CC-BY-SA). I think we still have a long way to go to faciliate the search, creation and reuse of open content. And now, I have a great opportunity to share my experience with other people and learn other points of view.

Starting tomorrow till Friday Nov. 5, I’ll be in Barcelona attending Mozilla Drumbeat Festival 2010. I admit I have high expecations on this unconference/festival or whatever name you give to an event that will bring together ~400 persons around OER and the Web. You can check the program here. The Festival has been designed as a forum to foster participation and quick interaction (maybe, it reminds me our great Open Space sessions in WikiSym, but on a larger scale)

Some of the sessions I plan to attend will cover different perspectives of a very important topic: how people create and reuse open content on the Web. In this line, we have for instance a session on “How to encourage content reuse”, another one exploring how to build better platforms to find open content (“Pathways to open content”) and finally, a brainstorming session about “The next big thing in OER”. Thus, I’ve been thinking about these issues, what they have in common and how we can solve any problems that open content creators and users may find. This is my attept to summarize my thoughts, so far.

From my personal experience, and according to comments from other colleagues, there are 3 main issues impacting open content reuse:

1. Understanding which license to choose: We have many different licenses to choose for our content. However, many people still feel ok licensing their work under a Non-Commercial clause. While it’s true that this is a positive step towards openess, I think we also need to remind why licenses including NC clauses are not compliant with the Open Knowledge Definition.
2. Searching for open conent: Still today, almost a decade after CC was created, it is still a pain in the neck to find open content on the web. Well, I don’t mean it’s difficult to find any open content or good open content (just visit Wikimedia Commons and let me know what you think). I mean it’s very time-consuming to find the open content you need for a certain cituation (exercise: find an image depicting a fire flame, with decent quality, not including a candle, lincensed under CC-BY-SA. How much time did it take you?).
3. Using and storing open content: Finally, you found that great image for your slides. OK, you save it on a local folder, you include the image and link the original author (if needed), and you include a licensing comment. You’re done. Now, say that 3 months after that, you need again some images you already downloaded. You go to your local folder and… you don’t remember neither the author nor the license for most of them (if not all). You need to open the file where you used them to search for that info, or you search the web again (and pray for the search results to remain unaltered over the past 3 months). Sometimes, you end up including a long string on the file name to record this info, but that’s not very handy to tidy your stuff, right?

What we find here is the absence of a standarized, seamless support for embedding critical information in open content files (specially author info and license type). What if your favourite text processor or presentations software already tracks for you the author and license info and includes a footnote automatically? What if you can automatically create a table of licenses and authors in LaTeX? And my favourite ones: file managers. How about opening a local folder with Dolphin (or Nautilus, or Gwenview…), right click on your mouse and select “arrange files by author and license type”? They could also present a small note with that info on mouse rollover.

In summary, the root of all these issues (educating your users, finding open content on the web and leveraging the use of open content in academia and other contexts) is the lack of a standarized support to embed open content relevant info in multimedia files. Pierre Far, who’s leading the session on “Pathways to open content”, suggested a possible solution: XMP. This is an example solution for standard support to include information of file contents in the file header. It also supports many different types of multimedia files (including making use of EXIF heders we photographers love in JPEG files). But there may be others. I don’t mind what we finally choose, as long as everyone agree to use the same standard.

Conclusion: if we aspire to get real support from end-users to open content, we must help them offering seamless suspport to perform daily tasks required in the new workflow (dealing with licenses and author info). With this apparently simple step, we would shoot down all problems above with a very simple but effective move. Time for other people to jump in the discussion, and stadards masters to start thinking about this.

Looking forward to meeting you in Barcelona!