Topic: Open source

So I may have my beef with with the software as freedom,¹ none the less I think we can learn some pretty interesting things about freedom and politics from thinking about what open source means. In this vein recently, I’ve been thinking more about the economics of open source, and as I’m prone to an interest in creative business models that find interesting ways to generate income in unique and special ways. Here’s some thoughts on the “politics/economy of work in open source.”

On some deep level open source software resists the traditional scarcity economic model. There is no property, intellectual or otherwise, that you can exchange for money in a way resembling the normal way. With that option off of the table the open source community has to come up with other ways of doing business, and because scarcity (in another sense) is the mother of creativity, what folks in the open source world do to make a living is pretty interesting.

There are a few of major ways that people in the open source community make money:

1. Software-as-Service: Rather than sell people software, companies sell service agreements. This is nifty, because it lets groups of people get support for open source, it’s cheaper for users than buying software and service contracts, and also it means that service based businesses are smaller, because it’s more efficient to run a smaller company, and because anyone with the right skills can provide the services and not just the copyright holder for the OS. So customers get a more tailored experiences. The con, is that the better software is, the less people need support for it.

2. Custom programing. Basically individual programers consult with users to develop custom solutions around people’s needs, using open source tools. Ideally some of what people write gets contributed back into the repositories (as libraries/tools), and this is particularly suited to very modular/adpatable projects like drupal or debian

3. Certification. A company/programer reviews the components and develops an independent release of an open source product that they’ve certified. The best example of this is the RedHat certified linux versus Fedora Core. Which is mostly useful in the “enterprise world.”

4. Service Software. This is a mashup of other models, and I think it better to lead with examples: Wikimedia/Wikipedia/Wikia and DabbleDB andsmalltalk/seaside. Basically, a company uses an open source product to develop a service which generates income via subscriptions, advertising, and donations, which supports developers who contribute to the core project.

The most interesting effect that all of these models (but most clearly in the first two) have is that money isn’t being exchanged for “a thing,” but rather for work.

Which when you think about it, after we remove a few layers of mystification around “intellectual property,” the only thing that’s truly scarce is labor. Folks in the open source movement have had to realize this, and I think the ripple effect of this could be really profound. More important than even the “open access” to source code.

Twenty years ago (or more) having open source code was really rather important, but even then and more so now, open source code wasn’t a great benefit to most users. The number of linux users who’ve ever looked at the kernel source is probably pretty small. Thus I think it’s not a stretch to say that the ideology of open source (as opposed to free software) is as much about pushing further a different way of thinking about work and “ownership,” as it is about “freedom” or some more specific technological goal.

Thoughts? Reactions?

Aside from doing semi-perverse things with my email retrieval system, one of my most recent technical/digital obsessions has been with a X11-based window manager called awesome. It’s a tiling window manager, and it’s designed to decrease reliance on the mouse for most computer interaction/system navigation purposes.

Unless you’re in the choir, your first question is probably “What’s a tiling window manager?” Basically the idea is that awesome takes your entire screen and divides all of it into windows that are a lot like the windows that OS X, Windows, GNOME, and KDE users are the same. Awesome also has the possibility for what it calls “tags,” but which are akin to virtual desktops (and I think of as slates) which make it possible to have a great number of windows open and accessible which maximizes screen efficiency and multi-tasking while minimizing distractions and squinting.

The second question you might have, given the prevalence of the mouse-pointer paradigm in computing lo these 30 years, why would you want a system that’s not dependent on the mouse? Long time readers of the ‘blag might remember some blogging I did earlier this year about the second coming of the command line interface. The basic idea is that the more you can avoid switching between the mouse and the keyboard, the more efficient you can be. Keystrokes take fractions of seconds, mouse clicks take many seconds, and this adds up. The more complex idea is that text-based environments tend to be more scriptable than GUIs and coded more efficiently with less mess in between you and your data/task. After all, coding visual effects into your text/word processing application is probably a sign that someone is doing their job horribly wrong.

One of my largest complaints about using GNOME is that it’s terribly inefficient with regards to how it uses screen space. Maybe this is the symptom of using a laptop and not having a lot of space to go around, but most applications don’t need a menu bar at they top of every window, and a status bar at the bottom of every window, and a nice 5 pixel border. I want to use my computer to read and write words, not look at window padding (I suppose I should gripe about GNOME at some point, this is an entry onto itself.) Awesome fixes this problem.

I’m not jumping in to Awesome full time, but I am starting to use it more and learn about it’s subtleties, and hopefully I’ll be able to contribute to the documentation of the project (it needs something at any rate). For a long time I’ve flirted with Linux, but haven’t ever really felt that it offered something that I couldn’t get with OS X, and this changes that pretty significantly.

One of the things that I need to do first is explore Linux equivalents to my remaining OS X-only apps. The most crucial is the news reader, I’m a big fan of NetNewsWire, and I’ve never used a news reader which can top it. As it turns out, between vim and Cream, I’m pretty set in the text editor department (though I need to port over the most important of my scripts and snippets to vim), and although Adium is a port of Pidgin, using Pidgin is painful by comparison, particularly in awesome.

But I have time. I’m doing this becasue it’s interesting interested and weirdly enough, it’s kind of fun.

That’s my story and I’m sticking to it, I’ll be posting more on the subject as I learn more.

This is the post I promised a few days ago about my linux/BSD/etc. quandary.

I have an old computer that is a handmedown from some friends who moved out of town and had (good for them!) bought an iMac. It’s 2001 vintage PC, branded HP. Say, 512 megs of ram, and a 1.8 ghz Pentium 4. In fact, it’s a pretty spiffy machine, for it’s day. I often think of PCs as being uniformly lackluster, but the truth is that I never had an overcharged machine. For instance, this PC has firewire. Firewire! I’m not sure that they’re putting firewire in PCs these days.

In any case, while the computer isn’t ultra spiffy by today’s standards, it’s not bad. Well, it’s not bad aside from the fact that Windows has… done what Windows does best: break, and crumble under the pressure of every day use. I mean the people I know (ok person) I know that uses windows with any consistency reinstalls the operating system with a degree of regularity that I find almost maddening (Hi C.!).

Anyway, I think if I install a more… lightweight operating system, something unix-y. And this post is half, me thinking out loud, and half me asking you all for help and opinions on the subject.

I might be able to put this computer to serious work doing something around here. One distinct possibility is that I’ll get it ready for my mother to use as her home computer, running mostly web things--email, surfing, IM--and what not. Also being able to run a few things in Wine might help her workflow out. That strikes me as being the perfect use for a straight up ubuntu install. I’ve also thought about Xubuntu, because it seems like it’s pretty suited to this kind of thing (reviving an older computer that doesn’t need to do any serious heavy lifting.)

The second thing I’m thinking of doing with this computer is to find some way of getting it to work (including boot up and all) without needing a keyboard/video/etc. So basically a server set up. I figure it would be the most efficient to be able to access it over the network from the computer that I actually use on a day to day basis. Mostly I’d use it for things like file serving, and backup, but maybe bit torrent and the like as well. Ubuntu would probably work ok for this (and I did grab a copy of the server version as well, if I want to try this. I also thought that trying to run FreeBSD might be sort of fun. I mean: a shell is a shell (I hear freeBSD doesn’t come stock with bash, sigh.) and you know that might be fun. And if I don’t get into graduate school, having unix experience, might be productive.

So I guess, your thoughts on Ubuntu flavors, or I suppose other linux distributions, and also, on FreeBSD if anyone out there in Internet land has experience, it would be great to hear from you on that.

Talk to you soon!

Onward and Upward!

When I started this little “series” on open-source knitting, I said that it had a lot of connections to other projects and ideas that I’ve worked with with relation to Station Keeping and the hypertext/writing posts, and this post--which address technological (ie. file systems) organizational concerns and collaborative organization--I think dovetails nicely with the more “general interest” aspects of this series. Additionally, when I started the series, I set out a number of goals that I hoped to address as part of this series. This essay addresses the last of these goals, the “Technological methods of attending to such a(n open knitting) project.” The total list of goals is:

• Is there a layer of information that goes into knitting design and documentation that isn’t typically exposed in “closed”/conventional publications? (that would be equivalent in role to source code)?
• The role of editors and communities and the sometimes very “conventional” development models that “open” projects use.
• The way GPL/GFDL knitting projects can be used commercially.
• Technological methods of attending to such a project.

One of the biggest challenges that I think faces new collaborative projects, is that when you’re planning it out you say “we need to end up with a project that accomplishes x, y and z,” and you spend all your time/energy building toward your end goal, and forget the smaller things that have to be in place first. If you’re writing a book, and you spend all of your initial planning time organizing how the historical forces that produce the climax line up, and then you sit down to write and your characters aren’t really fleshed out, and you end up with a hundred pages of exposition that no one wants to read, or the feeling that you have to do even more planning, despite the fact that you have thousands of words of notes written out. Now this works out when it’s just you writing the book, because you can toss out the hundred pages once you know your characters and write a real beginning, but in a collaborative project (of any sort I suspect), if your initial work is too focused on the work that will happen a year hence, and not focused on what will happen now, even if people are wild about contributing to the project, they won’t have a clue about how to participate, and the project will almost certainly flop.

It seems that the initial planning of a project should avoid setting up a firm structure for the entire life of a project, but rather strive to set up a firm basis and framework that would allow the project to develop on its own particularly in the beginning. In the book example above, spend time developing where your your are at the beginning of the story, know something about where they are, and also know where they’re going, but let the little details fall into place later. In a software situation, make sure that you have a database structure that you can live with before you start designing the interface in ernest. In a sweater, know your gage, yarn and intended size before you start stressing out over how to incorporate the shaping into the measurement. There are of course exceptions to these rules, and really great ways to break the rules, but when you’re working in a group situation, unless all your developers are working from the same page, it’s really difficult to maintain energy and keep things all together.

So lets try and import these ideas into a discussion of what an (but clearly, not the only,) open source knitting project would look like:

• A single OSK project shouldn’t try and collect everything about knitting, for starters this pushes us back to an encyclopedia model, and I don’t think that’s what we need. Particularly in knitting, there’s too much variation and you’d spend as much time deciding on “canonical” versions and not enough time enjoying the diversity. Furthermore, I think there are probably too many different kinds that it could work as a single coherent project.
• Avoid talking about techniques too much: While most knitters mostly knit the same way, there’s a lot of difference of opinion in terms of how to accomplish various kinds of knitting operations. While there probably is a need for a collection of these kinds of techniques, and I think Elizabeth Zimmerman made a great argument for the idea that while knitters are always developing new techniques (and should receive credit for this development,) the techniques themselves are probably always already in the public domain because given knitting’s history it is hard to imagine that we are the first to “invent” something (hence Elizabeth’s use of “unvention.") What’s more, with resources like Mary Thomas' Book of Knitting techniques, or Montse Stanley’s Knitter’s Handbook and the Schoolhouse Press Glossory that there isn’t a lot of room for improvement, beyond a collection of contributions. In other words, since open source succeeds at combining energy and efforts of a lot of people, the projects need to be ones where multiple perspectives and abilities would create a better gestalt. A technique handbook, in contrast might benefit from many perspectives, but probably wouldn’t benefit from any sort of group process.
• An OSK project should track version development: In the software world version tracking systems are used to make sure that changes in code are tracked as the project progresses, so that changes can always be reversed if the “old way” works better than the new way. Also this kind of software allows you to create “branches” so that you can work on bleeding edge feature/content development (so called “nightly builds”), and “release polishing” so that your finished projects are clean, clear and functional. In writing terms, this means that you can edit/polish the text without impinging upon your drafting. Which is incredibly helpful when working in a group setting. Versioning systems are also very atomic and keep track of differences (diffs), and work to keep track of and organize the most recent version of every file, even if more than one person is editing it.
• An OSK project should create and foster community development: This is perhaps a bit too obvious; however, I think it should also be said that community needs to have a space that’s separate from the project (make it possible for people to talk, outside of the actual project files.) Taking wikipedia as an example, while wikipedians can talk on the “talk/discussion pages,” it’s my perception that most of wikipedia’s community happens on IRC channels. While its not “a part” of wikipedia in the conventional way, I’m sure that wikipedia depends on those IRC channels to keep the community functioning.
• Separate workspace with display space: I think this point is part of my larger objection to using an idealized wiki model for development, where the entire website that the “public” (casual user) sees is the same as what the “core” (developers) are working on. This means that the “product,” is always rough and incomplete, and I think in an odd way it pushes developers to work on larger rather than small parts of the project¹. Ideally, I think these sorts of projects would work better when you have ten developers contributing one part each to ten projects, rather than ten developers contributing one whole project, or something along those lines.

I also had an organizational tree that I was going to seek some feedback on, but I think that’s safe to live in the notebook for a while longer. I think it’s clear by now, if any of you are still with me, that I’m planning on doing something with this project, but I think there’s more to develop, clearly, so while I think I’m mostly done milling over and presenting the theory, there’s plenty of work left to be done on developing and establishing such a project, so if any of you are interested in this idea, of an Open Source-Knitting project, I’d really like to hear from you.

Cheers, tycho