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.

The Illumos announcement, aired last August 3, may be the soap of this Summer. But it can also be the starting point of a story that will leave a memorable footprint in open source software. And that is not because of the project itself, which is cool. It is not because it shows some interesting advantages of open source software business models.

Above all (and if everything stays the same), we will remember this affair due to the huge opportunity Oracle is missing in this precise moment. Oracle is missing a healthy project, OpenSolaris, with a committed community of users and developers around the world, in one of the most critical market segments at this moment: high performance operating system platforms. What a blunder…

Read more…

No, this is not just a play on words. So far, I’ve collected some background examples to illustrate this apparent contradiction: public data on the Internet may be not so public. To be more precise, data privacy rights and other interests from some companies can play a major role in this problem.

As a researcher on open on-line communities (and open here is a synonym of publicly accessible virtual groups), this is a key concern for me. Likewise, it should be important for many other colleagues in this field, and the myriad of companies collecting and mining huge data sets on a daily basis. Let me show you some examples.

On March 26-27 I attended the CPOV conference in Amsterdam, organized by the Institute of Network Cultures. In the same session, Stuart Geiger presented an overview of the influence of Wikipedia bots in the editorial work of the community. One example quickly got my attention: HagermanBot. This bot was created to look for unsigned comments on Wikipedia talk pages, then automatically insert the signature of the corresponding author next to them. The bot raised a strong controversy among users, since many of them thought that the guideline of signing comments on talk pages was just that, a recommendation, not a rule to be enforced. Some could be embarrased by login names displayed next to comments. Wait a minute: isn’t that information public? Yes, of course it is. Just click on the history tab and you get the revision history page, tracking all comments and their corresponding authors. Read more…

As a resarcher focused on quantitative anlyses of on-line communities, I need to keep up-to-date on the field. I have to read papers and articles, written by other colleagues and scholars on related topics. I must search for new methods and algorithms to cut out execution times, and finish before the next deadline. I have to evaluate new tools that let me create new graphs or compute new analyses. And I have to review many papers in different conferences, presenting results in this area. In this context, I’m still surprised by finding the same problem, over and over again.

When I started to study Wikipedia, 4 years ago, I was puzzled by the lack of reproducibility in most (but not all) of the papers and analyses I could find at that time. No source code available. Few implementation details. Little discussion on how to set up a similar environment and replicate the analysis. If you were lucky, you could access some evaluation version of a new cool tool, just to discover that it was deadly limited. Forget about the code. Try and do it yourself, if you can. That’s why, since the very beginning, one of the main goals of my PhD. was to publish an alternative, open source software tool to analyze any language version of Wikipedia. Read more…