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 and smalltalk/seaside. Basically, a company uses an open source product to develop a service which generates income via subscriptions/advertising/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?

I read the following phrase on my travels this past week: “we’ll just have to wait till the SEO does it’s thing.” This is sort of a typical phrase that gets throw around on the “commercial internet,” and it wasn’t out of place. Indeed, I think all the readers of the article probably understood what the author was trying to convey. But it struck me as sort of odd. Here’s why:

It’s a completely empty statement. SEO (Search Engine Optimization) refers to the collection of techniques that are used to “raise” a given web page’s ranking in search results. Because there isn’t a hell of a lot of competition in this market, basically this amounts to trying to “game” Google.

Which… is sort of a loosing proposition. Google’s algorithms (or the key components) are top secret, and what we do know about how google arranges searches is that the more pages link to a given page, the more favorably Google’s algorithm’s view that pages, this lets Google’s search results reflect a sort of emergent semantic organization of the world wide web. This means that when we search google, more often than not, we’re mostly searching the most interreferential pages on the internet.

It’s true that there are a lot of sites that don’t have a lot of “juice” in Google, and that’s really frustrating for people who create websites, but Google’s domination of the internet-search marketplace is due largely to the quality of results that this reference-based system plays.

And in light of this, I hope it’s pretty obvious that SEO is mostly a crock of shit. You can’t game Google, and more to the point you don’t want to. Though I think the prevalence of SEO an interesting admission for the “commercial internet” that traditional advertising-based marketing models has utterly failed on the internet.

To my mind the ideological parent of SEO was “search engine submission” services, which would preparedly “submit” your website to search engines so that people could find your site. For a fee, usually. Clearly this didn’t work, because the return was so diffuse, and because no one really wants to use a search tool where the results are based on “submissions” which are paid for by the content producers. There’s a reason why most of us use Google and not AltaVista, AskJeeves, Excite, Lycos, Infoseek, and so forth.

Now having said that there are some things that you can do to encourage your site’s ranking in google (ie. get people to link to you on their sites,) I’d call this “good writing,” or “effective communication,” or “best practices,” not “SEO” but you know whatever works. Here’s what I think really works.

1. Be interesting, and have something to say. No one wants to read a website that’s boring. That’s why my readership is so low but if you can’t make the attempt, no amount of good mojo is going to help your site.
2. Post regularly. Really regularly. This resonates with this idea, the way to get good at doing 1., and make sure that people keep reading your site (and linking to you) is to provide dynamic and fresh content.
3. If you’re a company, write not only about what you do and your clients, but also about what your clients are interested in. This might mean talking about and linking to your competitors, don’t worry, rising tides raise all boats.
4. Participate in real life conversations. Most people learn about new websites via word of mouth connections formed in unusual contexts. There’s a reason why most of the leaders of the independent web (bloggers) are either: in New York City, San Francisco, or have been going to SXSWi since the beginning. (There’s also a minority of L.A. based bloggers). Talk to people, talk about your work, and talk to the other people who are creating content.
5. Write emails. This is the second stage of what starts in 4. Digital networking connections rest mostly on one-on-one email correspondences, and listserv conversations, despite all sorts of next wave technology like twitter, facebook, and linked in. Getting really good at writing quick, meaningful emails and staying on top of your correspondence is requisite.
6. Top load your content and titles. This falls under the category of good practice, and it mirrors the way newspaper columns are structured. Give as much information away as soon as possible, put all the details at the end, and write in a style that’s simple and designed to be easily and quickly read. There’s a lot out on the internet, and the the less time you take to make a specific point/joke/insight, the better.
7. Provide full RSS feeds, and don’t put things behind “cut/fold” tags so that people have to click through to “read more.” The former is good sense, and represents reaching out to other content producers (the people who read your site,) and the later is just good sense.¹ Other content producers are the people who have the real power over your search engine ranking, and making your content accessible is the first step in getting the content read.
8. Use a site design which maximizes readability and visibility, so that people can–you know–read your content, rather than marvel at your superior design capabilities.

Basically write a good site, network well, and don’t waste your time on snake oil and chants. /end.

Ok, I have two things to ask/pose/announce, which only seems fitting after writing something about how blog posts should be more singularly focused. Figures.

Part One: Switching to Linux

So, I’ve mentioned “the great linux switching of 2008″ a few times, but never really explained it. Here’s a proper exploration:

I’m finally begining to feel the pinch of not having a desktop computer. Don’t get me wrong, I really love my laptop, and will likely still use it a lot. My issue, is that I want more screen space than I’m really willing to pay for in a laptop (and a better keyboard), and I want to be able to dig a little deeper into the open source world for various reasons. And I’ve realized that the cost of building a multi-screen desktop isn’t going to be particularly prohibitive. So it seems like the right thing to do.

I started out the linux journey running ubuntu (hardy) and it was ok, but not great. Then I spent most of the week plaiyng around with gentoo linux and toying with the idea of other distrobutions like ArchLinux, say. And the end result was that while ubuntu was frustrating from time to time, it would work. I mean really work. So having learned my lesson–which I think is the most valuable product important re: the linux community of this process–I’m back to using ubuntu, and it’s working better than ever.

Part Two: Editor Dependence

As part of the “Great Linux Switch of ‘08,”¹ I’ve been spending a lot of time working in a virtual machine instalation of linux (first ubuntu, now gentoo) to practice the setup and get a slate of configuration files all ready for the machine when I finally order the real hardware. Going into this, I knew that the hardest part of the transition to linux was going to be the text editor part. Which wasn’t insignifigant given that, I write a lot of text and I’m a devotee of the OS X only “TextMate.”

In my linux useage I’ve been using vim a lot, and I’ve written about my vim trials for some time here, in various ways. Including, my comment to twitter that “vim isn’t something that people ever learn, as much as give up on.” Having said that, I think I’ve got mostly got a hang of it it. I need to get highlighting for Markdown and a few other things nailed out. And there are a lot of things that I don’t quite know how to do, but I’m getting there. The other thing that I’ve recognized myself doing is using more than one editor, or at least multiple variants of .

I mean, we use plain text files because they’re standard and just about every editor can read them. Isn’t it ironic then, that I/we grow so dependent on specific programs? Despite irony, it’s true for pretty good reasons.[^comfort] In anycase, for a lot of drafting and blogging writing, I’ve been using cream, a modern interface/configuration of vim that basically acts like you’d expect an editor written in the last twenty-thirty years to act.² And I’ve even been using standard gui-vim (gvim) for some things, and it’s not all bad.

Having reported this, I can’t decide if:

1. I haven’t found the linux editing enviroment nirvana.
2. I’m maturing in my geekyness/editor use and am become more in touch with/accepting of mostly standard configurations.

What do you all use/like? Thoughts

This is the first post I’ve written in a long time that wasn’t about open source/technology stuff. Not that I’m not still fascinating (or cranking out blog entries about that,) but it’s fun to tred on other ground for a while. This post grows out of some very abstract thinking I’ve been doing inrelation work about the nature of blogging.

First off there’s the divide between journaling and blogging. Though the distinction is pretty clear cut, in practice the lines blur. Journaling include posts/blogs that recount your own experiences and events, more or less as they happen. Blogging in contrast are posts that explore ideas and events around the author(s) expereince. And blogs are chronological so they look like journals and sometimes include “personal notes” posts, while journals will sometimes/often include the authors thoughts on a subject outside of the authors experience. So it’s a muddy playing field from the get go, but I think it’s useful to think about what makes a successful blog, because it’s more of what I have been doing here , and it may be easierer to quantify than what makes an successful journal.

I’d like to put out 4 general theories for your consideration about “blogging that works:”¹

1. Posts should generally explore ideas, concepts, events, and other texts. But mostly ideas.

2. Posts should explore one idea/concept, and only one idea/concept. If you want to write more complex essays, figure out a way to write articles for a more tratditionally formated publication (such things exist on the web).

3. Blogs are highly referential texts. Blogs which don’t include links to other blogs, and/or don’t include quoted text I think miss some of the point of what makes the web so great.

4. Blog posts need to be short. (Guilty as charged!) Blogs are meant to be read in concert with other blogs, and time is scarce. Also attention is scarce. And really if you’re only talking about one idea, getting it into ~400 words is hard, but it’s something to aim for.

That’s what I have. Any ideas on your end? Speaking of under 400 words, I’ll be done now, with none to spare!

Ok, this is going to be a quick post, I swear.

Truth is I do most of my blogging in TextMate using the amazing blogging bundle. Basically it means that if I use the right template (which looks a lot like an email header, really), I can hit three keys and a few seconds later the post appears here on tychoish.

Right.

As part of tycho’s great march torwards linux, I’m looking for something to fill this niche in my workflow.

So basically does anyone know of/know how hard it would be to write a script that takes posts written in a specific format (to specify title, categories, tags, etc) and send them via xml-rpc to a given blog.

Command line only is fine/preferable, and really I think the blogging.rb file in the TextMate bundle would probably make for a good core to write a script around, and I’m mostly interested in being able to send posts, editing as I archive posts on my machine, and I don’t mind the web interface for editing. Getting the sending done would be mighty nice.

This might make more sense if you’ve used the blogging bundle, as I think about it. Basically, the files when you pust get a Post: id field, which if you post a file with that ID a second time, is treated as an edit.

So in short:

• Simple text-based file format.
• Easy, non-editor specific posting commands.
• Multiple Blog support (again the TM bundle does this.)

Yeah, that’s about it. Thoughts?

Last month I told you all about this funky new way way I’ve been downloading email, using the git version control system, rather than traditional POP or IMAP. I wanted to write a post with an update to how this system works and how I’ve changed the system and how I think I will change the system.

Everything I said in the last post is still most true to be honest, though I did tweak it a bit in response to the comments, to make sure there aren’t performance related issues. It’s not perfect. Here’s the biggest problem:

In git, pushing to a non-bare repository is tedious, and potentially troublesome. Pushing to bare repositories are in contrast, much simplier. Indeed most of my stress–and the complication–in the initial solution was bound up in this fact. Bare repositories are basically the versioned database parts of a git repository without the files, which is ideal for a server where you’re pushing commits/data to. The reason why pushing to non-bare repoistories is hard is becasue when you push to a non-bare the files aren’t updated (on the theory that someone might be using them, and there might be uncommited changes.)

The reason why I’d need to do this? The “origin” repository, which in all other situations would be a bare repository, needs to have an “index” (files) becasue all of the mail lands on the server (as files) in the origin repository.

The obvious solution to this is to keep a second remote repository, and this how ikiwki solves the problem for ikiwiki wiki’s stored in git repositories. So here’s a description of how this new system would work:

1. Email arrives on the server and procmail begins to filer it delivering it to:
2. ..a git repository called ~/mail which is a clone of ~/domain.com/git/mail.git/.
3. I keep a clone of domain.com/git/mail.git/ on all of my computers/workstations/shell accounts.

Here’s how the sync sequence goes. Though I could probably wire something up with git hooks (is there even a pre-pull hook?), I’m not sure that that gains us anything in particular for this setup, so I’ll just assume that v.2 of git-mail will work the same as v.1, and live in a shell script that:

1. Pull from domain.com/git/mail.git/
2. Commit all local changes. (involves removing deleted files and adding new files, git’ll handle the renames impicitly).
3. Push local changes to domain.com/git/mail.git/
4. ssh into the server. and have ~/mail/ pull from ~/domain.com/git/mail.git/ commit all changes push to~/domain.com/git/mail.git/
5. Pull from domain.com/git/mail.git/

Basically the idea is:

• Always pull from the bare/”root”/centralized repository, commit any local changes and then push to the local repository.
• Even though this system, like most git systems, in truth, have a centralized repository, all of the “children” repositories are equivelent, even though one repository is special because it’s where new data enters the system. This, as my previous attempt has shown, isn’t strictly speaking, necessary, but it does make things better.
• Given all this, if I needed to start using fetchmail locally for some reason to check a pop account, I could without needing to worry about syncing problems. It makes sense for mail to “enter” on the server/centralized for semi-obvious reasons, but it’s not a requirement by any means.

The problem is that you have to keep two copies of all your mail folders plus the history (which becasue of delta storage and compression isn’t as much as you’d think) on your server, and I haven’t tested things, so I’m not sure how it fares on the time. On the one hand there’s more disk time involved in the new setup, on the second hand there’s more chatter between the machines in the old setup, so I don’t know how it works interms of speed, but from where I’m sitting, it cannot be worse than IMAP. Can’t be.

So I have a new quandry. I have one computer (a nice, pretty new MacBook Black, that does everything I want and then some.) and I have two lives. No not like that, but my computer is both the place where my paying work gets done, and it’s the site of much of my creative output happens. Now, keeping work and play separate is a challenge for many people, even when who have different tools, but it’s a particular challenge in my enviroment.

My biggest concern is that if I’m constantly aware of what’s happening in my work email box, I feel like I’m always working, and it makes it hard to concentrate on writing these blog posts. And the inverse is true too: if I get a message to a non-work related listserv it’s hard to let that linger when I’m working.

Now arguably the solution to this would be to have two different email accounts and systems. Except that I use mutt, and procmail and my favorite text editor to write email and I really would have a hard time abiding by another solution. Also adding the need to check another email box wouldn’t really fix my problem, because there’s a chance that I could miss something crucial in real life if I unplugged from one email or the other. So the two accounts solution is basically out of the question.

I just need a simple way to control my “context” (in the Getting Things Done terminology) vis a vis my email box. So here’s what I cooked up. I should disclaim that I use the mutt-ng build of mutt which includes a sidebar in the mutt interface.

Basically what you need to do is have two different .muttrc files (where your settings live), one for “work” and one for “play” (I called it “standard”) But rather than have two possibly divergent files, here’s what I’ve done.

Split your .muttrc into two parts. The first includes everything that includes refrences to mailboxs. Those lines look like this: mailboxes =<mailboxname>. In a second file put everything esle.

Name the everthing else file .muttrc_core and put it either in your mail folder or in your home dirrectory. Duplicate the mailbox folder so there are two copies, and edit each one to suit. You probably want your drafts/sent/inbox folders in both contexts, but not your work mailboxes or your hobby listservs. Lets name the files, .mailboxes_work and .mailbox_standard, and put them in the same place as the “core” file.

Now here comes the trickery. In $HOME/.muttrc put the following:

# All the good Mutt settings
source /path/to/.muttrc_core
# which mailboxeses to list in the sidebar
source /path/to/.mailboxes_standard

And in a file named .muttrc_work

# All the good Mutt settings
source /path/to/.muttrc_core
# which mailboxeses to list in the sidebar
source /path/to/.mailboxes_work

Now, the trickery, open up your .bash_profile or .bashrc (which ever you use…)

alias muttw='mutt -F /path/to/.muttrc_work'

And you’re done. Now you have to intentionally open up your work email, so you don’t feel like you’re always on call, but you get the delightfullness of only having to worry about one email account, particularly if you’re good about choosing which email boxes go in which folders, and about using procmail to filter out most of your email in the right ways.

You might also imagine how you could use a similar fix to control how you address email based on work/home context, or even estabilish different commands for various key bindings based on context, and the best part is that al all of your core settings stay the same and are centrally located in one place. How nifty is that?

In my post/rant about IM clients, I mentioned that I was running a Ubuntu instalation in a VM instance on my MacBook. I am in fact, not crazy, and I’d even go so far as to recomend this experience for most other people. Here’s why:

First off, virtual machines let you save state in snapshots. So, as a general practice make a backup snapshot when you get your computer set up (which you save for safe keeping), and then again at regular intervals (every week, say), and then a third one just in case before you change any setting that might screw things up. That way, if things get really bad, you have a known good setup, something working that’s no more than 7 days out of date, and protection against botching your system in an upgrade. This isn’t as backing up your data, (which you should also do) but it’s important to do anyway.

The second great thing about virtual machines is that they let you sandbox the operating system. But you like your operating system sans sand? Me too. Conventually we run our operating systems “on the metal” and our operating system is in charge managing all the hardware interactions, but in virtualized instances the VM software does all this for you, and the “guest” operating system runs in an isolated enviroment. What this means is that you can move a virtual machine from one computer to another (mine’s 6.3 gigabytes, I could put it on a flash stick!) without any problems. Also, if you have some sort of driver problem on your host operating system, the VM isn’t subject to that, and you won’t get intsability from crapy drivers (exactly). And if you’re using the VM for testing and you manage to screw up something crucial the VM is the only thing that crashes.

Not to mention that you can generally start, stop, and pause virtual machines at will, so say you’re working on things in a virtualized linux, but need to run OS X system updates, you can puase your work in the VM update the system, restart and then unpause the VM and be right where you stoped.

Sweet!

VMs have become more popular/prevelent in the last several years as Macs have started running on the same x86/”intel” hardware that PCs have been running on for years. If Macintosh hardware is just pretty looking PCs with only one mouse button, it makes it easy (and tempting) to want to virtualize OSes on desktops, particularly as for people switching from Windows to OS X, who either need to use their existing software or who just want something familar near by. And the great news is that since virtualization has been used for years in servers, the programers are pretty good at writing the software.

So it seems to me, that VMs might be the way that we all interact with our desktop computers in a few years. There are a lot of useability/backup benefits, not to mention the portability ability, and it could also improve operation, depending on who gets stuck with managing the metal/hardware. I think the possibilities are pretty endless.

Onward and Upward!