Pointing out my Dissertation

Okay, no time to prepare an appropriate build up for writing about the main concluding points of my dissertation so I will just drop the heavy stuff now and then try to follow up with some of the smaller points later on. There are two main points I will write about today and I will try to make the result as clear and concise as possible, but taming that 200 page beast is not easy. So please bear with me.

1. In FOSS, ownership has been redefined and is closely related to knowledge.

Let’s start with a claim that is common among the FOSS movement: with proprietary software, the user is only licensed to use the software. He or she cannot see how it actually works, let alone alter it or redistribute it. As a result, users don’t actually own what they buy, ownership is reserved exclusively for companies that develop and provide the software. In opposition to that, free and open source software licenses supposedly let anyone own the software by denying the restrictions to source code availability, modification or redistribution. If you want something more than my sweeping description, you can hear it from Stephen Fry himself:

This is where it usually ends, but this is also where I actually start. How can we talk about ownership if the rights traditionally associated with it are purposefully reversed by the copyleft or liberal licenses? Don’t be afraid, I will not argue that FOSS is some kind of communism. Instead, I will argue that in FOSS, ownership is not defined by legal agreements or licenses (this is not to say they are not important! They need to be in place in order to constitute an environment in which they don’t matter — how nicely paradoxical), but by knowledge intensive practices.

We get into a situation, where reading, modifying and redistributing source code (the exercise of basic ownership rights) is not restricted by license or a legal agreement. Anyone can contribute, right? But on the other hand, we can see that only a narrow group of people actually participate long term on the practices associated with ownership rights. Are those people the new “owners” of the source code? And if so, what qualifies them to such position?

The new owners are the ones who have been able to overcome the so-called entry barrier and worked to establish their position among the development team. To overcome the barrier, they had to develop knowledge of everything that goes into the software development practice: tools (text editors, version control systems, build systems, etc.), environment (libraries or other dependencies, similar/competing software, etc.) and the codebase itself. This is nothing trivial, in fact, Chris Granger once wrote that enjoying programming with all its complexities is a kind of masochism. In any case, it represents a substantial investment of effort exerted over a long period of time, typically by solving piecemal tasks.

In this sense, ownership is earned by overcoming the barrier. Those who succeed in overcoming it continually practice the rights originally associated with ownership. But by following this line of argumentation, we redefine what ownership is. It is no longer exclusive, it can be performed by multiple actors at the same time, but due to the entry barrier, it is still differentiating. This is why some companies are able to make profit out of software that is, together with its source code, freely available — because they employ developers that hold knowledge allowing them to overcome the barrier and practice the rights of redefined ownership.

2. Knowledge does not immaterially operate upon itself.

After reading through the first point, it seems that knowledge is the single most important “thing” in software development. Sure, pointing out the importance of knowledge is hardly anything new — social scientists have been working with the claim that knowledge is the most important production resource since the late 1960s. More recently, this claim resurfaced as an assumption in the enthusiastic anticipations of what digital technologies can offer, spearheaded by the utopistic visions of planet-wide systems of collective intelligence. These visions are most often associated with the work of a French philosopher Pierre Lévy, but there are also others that relate the concept of collective intelligence with images of “harnessing crowds” or “creating a prosperous world at peace”. But what does this have to do with software development? Just consider this excerpt from Eric Raymond’s essay The Cathedral and the Bazaar:

That is, that while coding remains an essentially solitary activity, the really great hacks come from harnessing the attention and brainpower of entire communities.

In Raymond’s essay as in visions of collective intelligence, the good thing comes from “harnessing” many individual minds. But there does not seem to be much elaboration on how this “harnessing” takes place, we just glue minds together with some sort of technology. And it doesn’t matter much what technology it is because it’s changing all the time anyway. This tendency does not avoid even the most prominent sociologists, in fact, it seems to culminate in a peculiar claim made by Manuel Castells in his monumental, three volume work on the information age:

For the first time in history, the human mind is a direct productive force, not just a decisive element of the production system.

But what’s wrong with that? After all, isn’t mind where knowledge resides? Well, sort of. My argument is that with mind, you only get half of the equation. The second part are information (data existing outside of mind) with which the mind interacts to produce knowledge. In software development, information can take many shapes: source code of a developed program, interface of an existing one, logs, backtraces, bug reports, and the list goes on… Essentially, all of the things that add to the complexity of software development and constitute the barrier to entry I wrote about in the previous point.

It has been said that a good interface should be invisible, but that does not mean that it is not there and that someone did not design it to be functional with regard to cognitive processes. But what do we get when we place all of the emphasis on mind? An image of actors freely moving through space and swarming around problems they deem important — all of this in a very frictionless manner (what can be more frictionless than a mind directly producing something?). These images are present in social scientific concepts (self-organization, spontaneous order) and in FOSS culture (flock, anyone?) alike.

FlockIn FOSS, the image is further supported by the existence of the so-called drive-by patches, which are often highlighted more than the work of core developers (see, for example here or here). It seems that the work of the heavily involved contributors is taken for granted and is often made invisible, presumably because it does not fit in with the public image that FOSS has — the one of unlimited possibilities of frictionless movement. Because they invested so heavily into their knowledge of particular technologies, maintainers or core developers tend to stay with projects for long periods of time, spending their working hours on integrating all the drive-by patches into something useful. Should they try to switch to a different project, their movement would probably be anything but frictionless (even though with seasoned developers, a large part of learning tools and environment would probably fall off).

Here we are again with all the complexities constituting the entry barriers. If you consider knowledge to be the most important productive force and mind to be pretty much the only thing that determines it, then you end up with images of constantly reconfiguring fluid associations, which, however, are unable to grasp the solidity and stability that are also inherently present in FOSS development projects. On the other hand, by taking into consideration the environment with which the minds interact (tools, dependencies, libraries, source code, etc.), we can acknowledge also the limiting role of knowledge — that it constitutes a barrier which places individuals who overcome it on an advantageous position. And as a result, we are able to account better for the stability of FOSS projects’ cores.

And that’s it! If you have any thoughts or comments, if you think that I’m outrageously wrong or totally right, please let me know.

Advertisements

Nano as a Focus Oriented Editor

One of my previous blog posts dealt with using Markdown for writing. Once its clear what markup to write in, another question pops up: which of the humongous number of text editors to choose? I’ve been sniffing around for an editor that fits me for quite some time now and I feel like I’ve tried them all: Gedit, Geany, Notepad++, Moe, Vi, Vim, Emacs, Sublime, Brackets, Atom, Light Table… and Nano.

nano

Obviously not all, but still. I find it somehow paradoxical that after all the spoiling from editors that are feature packed to the roof, I ended up with Nano. And with ended up I mean: I haven’t changed my editor for a while, I’m quite happy about the setup, I’m able to work efficiently and when I try a different editor, I’m naturally drawn back.

With all those shiny next generation editors around, why choose an editor whose history reaches to 1990s and which can be operated only from the command line? Well, because Nano helps me to solve these problems quickly and easily:

 

 

  1. Focus. This has been a major problem for me. No matter how good your editor is, if you get distracted by the web browser lurking in the background, you still don’t get much done. This is why I turned to command-line editors in the first place. Having a full screen terminal, or being on a separate tty really helps to channel the attention. And if some distractions still remain, you can go as far as slapping your old useless PC with a headless system and unplugging it from the network. Still feel like in the need of a new simplistic focus oriented editor?

  2. Keyboard utilization. Being a command line editor, you can rest assured that Nano won’t force you to constantly oscillate between keyboard and mouse. And it gets even better, there are keyboard shortcuts for all actions using the alphanumeric keys. This will surely please all the touch typing keyboard ninjas out there. I know it makes me happy.

  3. Custom syntax highlighting. Need one? Know regular expressions? No problem then. Just write the rules into the .nanorc file and you’re done. This comes really handy for me as I use the Pandoc’s version of Markdown, which is usually not well supported by the out-of-the-box syntax highlighting in other editors. Here’s the custom syntax highlighting I use:


syntax "markdown" ".txt$" ".md$" ".markdown$"
# Emphasis
color magenta "[^]_"
color magenta "*[^*]
*"
# Strong emphasis
color brightmagenta "**[^*]**"
color brightmagenta "[_]*"
# Underline headers
color yellow "^====(=
)"
color yellow "^----(-)"
# Hash headers
color yellow "^#.
"
# Inline HTML tags
color brightblue start=""
# Inline footnotes
color green start="\^[" end="]"
# References
color brightgreen "@([a-z]|[0-9])+"
# Links
color blue "[.](.)"
# Code spans
color cyan "[^]*`"
# Quotations, lists, horizontal lines, newlines and footnote marks
color brightblue "^> "
color brightblue "^- "
color brightblue "^* "
color brightblue "^[1-9][0-9]?[0-9]?. "
color brightblue "^---"
color brightblue "\$"
color brightblue "[\^[1-9][0-9]?[0-9]?]"
color brightblue "[\^]"
# Todo
color ,red "TODO"
# Trailing whitespace
color ,red " +$"

For more information on how to set up the nanorc config file, see this page.

Okay, maybe I turned this post into an advertisement for Nano. Luckily, it’s free and that should drive the accusations away :) To balance this, I will add one thing that I miss in Nano and that is snippet support. But, there is a workaround for this, just follow these steps:

  1. For each snippet you want to have, create a text file that contains only it.

  2. Put them in a folder, and open your other files from within that folder (it will make this folder the default one Nano looks into when opening new files).

  3. This step applies only if you have enabled the support for multiple buffers: Once you have opened a file you want to edit, hit alt-F to tell Nano that the contents of files you choose to open should be inserted into the current buffer (this setting lasts until you quit Nano or until you hit alt-F again).

  4. Now if you need one of the snippets, hit ctrl-R to open a file, type the first few letters of the file which contains the desired snippet, complete it with Tab and hit Enter.

And that’s it, now you have the snippet at cursor position. It’s not perfect, there are no placeholders for cursor positions, but well… for Markdown with occasional HTML comments? Good enough.

Okay, enough rambling from me. To the machines!

Recent Changes in Pitivi User Documentation

I feel like the basic (re)writing of Pitivi user docs is done so I thought I should take a while to describe the current state of the docs and point to further tasks that need to be done. When I started, nekohayo gave me his to-do list that he kept specifically for docs, which helped me to get going. For the first commit, the choice was clear: add Pitivi’s license to the manual’s license page. As close to a one-liner as you can get. Soon, I got into the flow and as a result, the user manual now looks a little more complete. Of course there are some remaining issues I haven’t had time to cover yet. These are mostly tracked in bugzilla.

Also, screenshots should be updated in the manual, but I was postponing this intentionally for two reasons. First, there might be some slight UI changes on the way to 1.0 and second, it is not a big deal since the gnome docs team recommends (because of the difficulties this poses for docs translation) to use only one screenshot — that of the main window overview. So the screenshot is just waiting for the right time to be switched.

More interestingly, I have an experimental branch containing a troubleshooting page. I know that the Pitivi developers work hard to clear all issues that would possibly need troubleshooting, but in the meantime, I thought this page could provide some guidance. You can look at the branch in my Github repository. Any thoughts or comments are appreciated!

An efficient way to convert Markdown to a Word readable format

In my previous post I pointed to some of the advantages Markdown has for writing. However, sooner or later you arrive in a situation where you need your text in the .doc / .docx / .odt format. Obviously, you google how to convert it and you end up with the good old Pandoc. This program works great for converting almost any type of documents. But recently I discovered that there is more to it than just:

pandoc -o output_file.odt input_file.md

Here are two ways to spice it up. First, use the --smart argument which ensures that straight quotes are converted to curly quotes, two dashes to an en-dash etc. In other words, Pandoc will attempt to produce a typographically correct output. Similarly, the --normalize argument removes repeated spaces and makes other corrections.

Second, you can use the --reference-odt or --reference-docx arguments, depending on which format you want do convert into. This points Pandoc to a reference file whose styles should be applied to the converted text. It allows you to pre-define the formatting of headings, paragraphs and other parts of text so that you don’t have to do this manually after every conversion. All in all you would use:

pandoc --smart --normalize --reference-odt=file.odt -o output_file.odt input_file.md

Using plain text for writing gets a lot easier. You just need to define the styles once and Pandoc will take care of the rest for you. No wonder Pandoc is presented on its homepage as a swiss army knife for working with documents. You can even tell it to generate table of contents based on headings used in the text. The options are vast, just look into the manual man pandoc.

There are few more things I would like to note:

  • The Pandoc manual says that for best results, the style reference files should be generated by Pandoc in the first place.

  • Pandoc recognizes multimarkdown footnotes (for syntax, search for footnotes here) and converts them correctly, yay!

  • If you need to quickly convert Markdown to HTML or PDF, you can always use Dillinger, an online conversion tool.

  • There is also one other way to make the conversion without Pandoc, though I suspect there are less options than are offered by Pandoc.

Baby steps

It is quite some time since I entered the open-source world. It’s years, long years actually. I first installed linux when I was at high school (wow, Dapper Drake is old!) and since then I was slowly picking up the tools and mindset to do things the open-source way.

First things first, I had to take a command line 1.01 since I constantly needed to do things like reset my network card, update grub to catch up on my latest distro-hopping endeavor or set up the cool looking conky I just found on the web. Some copy pasting of commands I found on the forums usually did the trick. It was a hassle but it was well worth it. Nowdays, I work with command-line programs like git, grep, pandoc or wget on a daily basis and they are great. Yum!

Second, tinkering with various settings got me to recognize the powers of plain text. I got all my writing settled around Markdown now (Markdown FTW!), but it was a looong way, baby! Naturally, the starting point was using some kind of word alternative, be it open, libre or abi. My first attempt at utilizing plain text was with Latex. It felt really good to see my texts ending up looking professional, but after some time, it got tiring to deal constantly with the incompatibility with what everyone around me was using or with the process of setting it up (with all the specifics for my native language). And above all that, I’m really not a fan of the hyphenation enforcement which ruins the reliability of fulltext search for my texts.

I turned to HTML, a language that seemed that it can meet any of my needs. It didn’t take much time to realize that it wasn’t such an obviously good choice. Although it was nice that I could load the HTML document directly to MS Word or LO Writer whenever I needed to, it was really an overkill solution since I needed to annotate my texts with a lot more (and longer) tags. Certainly, there are more lightweight solutions which don’t distract from writing that much.

So guess what followed when I learned on Gradhacker that Markdown in its simplicity (actually, it is Multimarkdown but still) can handle footnotes. I checked that pandoc could process it and from there it was green lights all the way. It’s really universal. The github repo tracking my dissertation freaked out a little from the commits converting my files to Markdown but that’s it. Now I am living my happily ever after and it seems I will stick to this one at least for a while but I know that my learning isn’t over.

I started writing user documentation for the Pitivi video editor several months ago and it just never stops. I learned to manage git remotes, branching, interactive rebase, cherry-picking etc. The git thingies took some time but the Mallard markup was easy to pick up. And I practice my writing skills, especially for clarity. Recently, I also spent some time at figuring out regular expressions with some nice results for my research. Can’t wait what will be next.

Attention, Attention! This is the First Post

In a first post, I thought that I should properly introduce myself, my background and all the reasons that I have to do what I do as a sociologist studying technology development. But maybe next time. It seems the best way to explain myself is to jump directly into what is going on with me as a sociologist in the wild (pun intended).

I spent most of this week in Vienna on a conference called European Meetings on Cybernetics and Systems Research. There, I had the pleasure of being a co-chair of the Symposium on Sustainability, Ethics and the Cyberspace. It is not surprising that one of the focal points common to many contributions to the symposium was the issue of privacy and surveillance. Judith Simon, one of the authors participating in this symposium gave an interesting TED talk on the agency of things in today’s world and on the practice of epistemic hacking as a form resistence to surveillance. Definitely worth checking out.

In my talk, I focused on how open-source software development can be seen as a practice of knowledge production and on what distinguishes it from science, another form of knowledge production that has been claimed to be similar in certain ways to open-source. On top of that, I utilized some of the observations I made when writing documentation for the Pitivi video editor. Given the transparent environment of an open-source project, it seems that attention and its allocation plays vital role in what will result from the development process.

In the acedemic world, this isn’t exactly something new. Already in 1997, Michael Goldhaber came with the idea of attention economy, an economy in which attention is considered the single most important resource. As is the case with most of the manifestos proposing a completely new outlook on the world around us, Goldhaber went as far as to insist that the new attention economy will soon replace the old one based on money. This can be seen as an over-exaggeration, but today, one can see that what is taking place on the internet is a case in point.

And how does this apply to open-source software development? I guess that to the people having experience with this form of work, the importance of attention (and the decisions where to spend it) also isn’t something new. But things get interesting when we take a step back and ask the following questions: Are there shared ways to allocate attention in open-source projects? Are there established norms and common practices for that? Can tools and platforms used in the projects be considered as standards of channeling attention?

Based on these questions we can try to make comparisons of attention allocation e.g. between small and big projects, successful and discontinued, community and sponsored, you name it. But that is getting ahead of ourselves. What is important is not simply pronouncing that attention is somewhat important in open-source software development and be done with it, but to show how exactly this is happening and where are the differences among particular cases that could have the potential to explain their variability. This is the problem that I want to tackle with my dissertation thesis.