I've realized much to my chagrin that I haven't written a post on about the Awesome Window Manager in a long time. It's funny how window managers just fade into the background, particularly when they work well and suit your needs. Why then, does this seem so important to me and why am I so interested in this? Funny you should ask.

Tiling window managers aren't going to be the Next Big Thing in computing, and if they (as a whole) have an active user-base of more than say 10,000 people that would be really surprising. While I think that a lot of people would benefit and learn from using Awesome (or others), even this is something of a niche group.

As a result, I think something really interesting happens in the tiling window manger space. First, the project is driven by a rather unique driving force that I'm not sure I can articulate well. It's not driven by a desire of profit, and it's not driven by some larger Utopian political goal (as a lot of free software is). This is software that is written entirely for oneself.

That's the way most (ultimately) free software and open source projects start. A lot of emphasis in the community (and outside) is made on the next stage of the progress, where a project that was previously "for oneself" becomes something larger with broader appeal. Lets start with the git version control system which started because the kernel development team needed a new version control system, but in the past couple of years has become so much more, by way of phenomena like github and flashbake. The free software and open source worlds are full of similar examples: the Linux Kernel, Drupal, b2/WordPress, Pidgin/Gain, Asterisk, and so forth.

But Awesome, and the other tiling window managers will, likely as not never make this jump. There is no commercial competitor for these programs, they're never going to "breakthrough" to a larger audience. This isn't a bad thing, it just effects how we think about some rather fundamental aspects of software and software development.

First, if developers aren't driven by obvious "us versus them" competition, how can the software improve? And aren't there a bunch of tiling window mangers that compete with each other?

I'd argue that competition, insofar as it does occur, happens within a project, and within the developer rather than between projects and between developers. Awesome developers are driven to make Awesome more awesome, because there's no real competition to be had with Aqua (OS X window manger,) or other Kwin and Metacity (GNOME and KDE's window mangers), or even other alternate X11 window managers like OpenBox.

Developers are driven to "do better," than the people that preceded them, better than their last attempt, better than the alternate solutions provided by the community. Also, the principals of minimalism which underpins all of these window managers towards simple, clean, and lightweight code, inspires development and change (if not growth, exactly). This seems to hold true under anecdotal observation.

While there are a number of tiling window managers in this space, I'm not sure how much they actually compete with each other. I'd love to hear what some folks who use xmonad and StumpWM have to say about this, but it's my sense that the field of tiling window managers has more to do with other interests. Xmonad makes a point about the Haskel programing language. Stump is targeted directly toward emacs users and demonstrates that Lisp/Common Lisp is still relevant. Awesome brings the notion of a framework to window management, and seems to perfectly balances customizable with lightweight design. While Awesome is a powerful player in this space, I don't think that there's a lot of competition.

Second, if there's no substantive competition in this domain and if there's a pretty clear "cap" to the amount of growth, how are tiling window managers *not entirely pointless.*

I think there are two directions to go with this. First I think we're seeing some of the benefits of these window managers in other projects like xcb (a new library for dealing with X11) and freedesktop benefit both directly and indirectly from the work being done in the tiling window manager space. Similarly, Xmonad is a great boon to the Haskell community and cause (I suspect).

The other direction follows an essay I wrote here a few months ago about the importance of thinking about the capabilities of programing languages even if you're not a programmer because languages, like all sorts of highly technical concepts and tools create and constrain possibilities for all computer users, not just the people who ponder and use them. In the case of the tiling window manager, thinking about how the people who are writing computer programs is productive. In addition to the aforementioned thoughts about competition and open source.

So there we are. I'll be in touch.

I've been working a bit--rather a lot, actually--on getting myself ready to apply for graduate school (again) in a year to eighteen months, and one of the things that I'm trying to get figured out is the "why" question. Why go? Why bother? Questions like that. For starters, I hope to have some of the youthful angst regarding education knackered by the time I go back, and second, I think I'll be able to make the most of the experience. This post speaks to one part of this challenge: about what research is productive and worthwhile (that is, novel and original), and what research is by contrast merely an explanation of the obvious.

This is all predicated on the assumption that there's some sort of qualitative divide between the kind of causal observation and theoretical work that is what I do, (already), and "real work," productive work that productively contributes to a discourse. (Too young for impostor syndrome? unlikely!) Now this might be a ill conceived separation but, nevertheless the thought is on my mind.

The trains of thought:

• There's some fundamental difference between blagging and productive "knowledge production." Blogging is a practice that doesn't lead to systematic investigation, and thus, while interesting and a productive tool for the development of my thinking, it's a lousy end in and of itself.

  As I wrote that above paragraph, I remember that it resonated with a thought I've had about this website (in it's previous iterations) many years ago. Interesting.

• Fiction writing has (and continues) to be the most satisfying output of this impulse that I've been able to have thus far. While I do worry that my fiction isn't novel enough, that's a technical (eg. plot, setting, character) issue rather than a theoretical (eg. the science, and historiography) concern.

  Fiction writing also has a long publication cycle. My blog posts, from inception to posting, aren't particularly time intensive. Fiction, even/especially short stories require a bunch of extra time, and being able to immerse myself in a collection of ideas for a long time has a bunch of benefit.

  Also, there's a credential issue that I rather enjoy with-regards to Science Fiction. There's no degree that I could possibly want. I mean, sure, there are popular fiction writing programs, but that's not a requirement, and I suspect that I'll (try) to go to viable paradise sometime in the 2010s (or Clarion if I am somehow, ever, able to spare 6 grand and the ability to take 6 weeks off of my life), these would just be "for me," and there's nothing other that the quality of my work and the merit of my ideas that are between me and acceptance as a science fiction writer. That's really comforting, somehow.

• Most of us read literature of some sort, and talk about literary texts of one stripe or another, but I don't think that these activities necessarily make most of us literary critics. The art and project of literary criticism is something more. The difference between reading and talking about a text and practicing literary criticism is an issue of methodology. One of the chief reasons I want to go back to school is to develop an additional methodological tool kit, because my current one is a bit lacking. I'm pretty convinced that the difference between "thinking/doing cool things" and "doing/thinking important things," is largely an issue of methodology.

While I don't think this would short circuit the gradschool plans, but I think working to develop some sort of more rigorous methodological companion to the blogging process that goes beyond the general "so folks, I was thinking about foo so I'm going to tell you a story" (did I just give away my formula? Eep!)

In the last several days, I've spent a lot of time writing and working on this new novel that seems to be capturing too much of my attention. It's a nifty story, definitely the best piece of fiction that I've written henceforth, despite all my worry, dread, and seemingly limitless self-doubt in relation to the project. Despite the gremlins on my shoulder saying "why aren't you working on short fiction; why aren't your characters having more sex; do you really think you can float such a disjointed/complex narrative; do you have a clue where this is going? ...and so forth," I've learned a few rather interesting things from this story this past week.

I've been reading this is stevenf.com recently, and I have to say that it's among my favorite current blogs (by people I don't know). Geeky, but it doesn't revolve around code snippets, simple, and minimal but in all of the right ways. And a bunch of fun. Anyway he posted an article a while ago that got me thinking called, "it's my xanadu," go ahead read it and then come back.

That's a great idea isn't it? I've been thinking a lot about data management and the way we represent, store, access, and use knowledge on the computer, so stuff like this gets me more excited than it really should, all things being equal. My good friend Joseph Spiros is even working on a program would implement something very much like Xanadu and the system that sevenf described.

First order of business should probably be to explain what Project Xanadu is for those of you who don't know.

Xanadu was the first "hypertext system" designed that recognized that text in digital formats was a different experience and proposition than analog text. Proposed by Theodor Holm Nelson in the 1970s (with floundering development in the 1980s), Xanadu to be something amazing. It had features that contemporary hypertext systems sill lack. I think everyone has their own list of "things from xanadu that I want now," but for me the big sells were:

• Links went both ways: If you clicked on a link, you could reverse directions and see what documents and pages had links to the current page. This means that links couldn't break, or point to the wrong page, among other things

• Dynamic transclusions. Beyond simply being able to quote text statically, Xanadu would have been able to include a piece of text from another page that dynamically represent the most current revision of the included page. For example, I include paragraph 13 on page A (A.13) somewhere on page B; later you change A.13 to fix a typo, and the change is reflected in page B. I think links could also reference specific versions of a page/paragraph (but then users could from page B, access new and older dimensions of A.13).

• Micropayments. The system would have had (built in) a system for compensating "content creators/originators" via a system to collect very small amounts of money from lots of people.

  Needless to say, it didn't work out. It turns out that these features are really hard to implement in an efficient way--or at least they were in the eighties--because of computing requirements, and the very monolithic nature of the system. Instead we have a hypertext system that:

• Is built around a (real or virtual) system of files, rather than documents.

• Has no unified structural system.

• Must rely on distributed organizational systems (tagging, search engine indexes.)

• Is not version-aware, and it's pages are not self-correcting.

• Relies on out-modded business models.

To be fair, much of the conceptual work on the system was done before the Internet was anything like it is today, and indeed many of these features we can more or less hack into the web as we know it now: wiki's have "backlinks," and google's link: search is in effect much like Xanadu-Links, using dynamic generation we can (mostly) get transclusions on one site (sort of), and paypal allows for micropayments after a fashion.

But it's not baked in to the server, like it would have been in Xanadu, this is both the brilliance and the downfall of Xanadu. By "baking" features into the Xanadu server, hypertext would have been more structured, easier to navigate, easier to collaborate, share and concatenate different texts, and within a structure easier to write.

And yet, in a lot of cases, I (and clearly others) think that Xanadu is worth considering, adopting: indeed, I think we could probably do some fairly solid predictions of the future of hypertext and content on the internet let alone information management in general, based on what was in Xanadu.

That's about all I have, but for those of you who are familiar with Xanadu I'd love to hear what you "miss most" about Xanadu, if you're game.

I wrote a series of articles nearly two years ago to rethink the GTD system, which I think is worth revisiting again. Not the essays, which were from when I called the website "TealArt" (don't ask) and were before I really discovered free software and open source in a big way; but rather, I think two years out from my original article and even further out from the heart of the GTD fad, I think that it's worthwhile to explore GTD again.

For those of you playing along at home, GTD (Getting Things Done) is really a "personal productive methodology" designed by David Allen that swept the geek community a few years ago. It's good stuff, and while it's certianly not a one-size-fits-all miricle cure for umproductive and overwhelmed folk; it promotes (to my mind) a number of goals that I think are quite admirable:

• Have a single system, that integrates across all aspects of your life. One place where systems can fail is if you're using different "databases" (in the non-technical sense) to store information and tasks, and you have a piece of information that might fit in either system: when you go to look for it later (or need to be notified by it later) the chance of you missing the task because it's on the wrong list is much higher if you have more than one place where lists might be.
• Think about tasks and projects being broken into "actionable items," and have actions be the unit of currency in your system. As you assimilate information be sure to record anything that needs doing and keep it in your system
• Attach two pieces of metadata to your action: project (what larger goal does the action help you acomplish; you'll likely have a list of these projects), and "contexts" (where do you have to be in order to do the action, things like "phone" "office" "erands") are helpful for focusing and making it easier to move your projects forward.
• Do regular reviews of the information on your todolists, and spend (an hour?) once a week making sure you're not foregetting things and that you've checked off all the actions that you've actually done and so forth.

There are other details, precise methods which GTD people focus on, talk about, and provide in their software applications. Frankly I've not read the book and I'm by no means an expert on the subject. I continue to have objections to the system: it assumes large tasks and quickly and easily be broken down into smaller tasks (which isn't always true), and that projects follow linear and predicatable sequences, which I find to be almost universally false. While the reviews help counteract these sorts of assumptions about projects, I have always tended to find GTD a poor solution to the productivity problem: [1] both for myself and in my observations of how other people work.

At the same time, I think the notion of a single system that comes to the mainstream via GTD and of weekly/regular reviews, another artifact of GTD, are both really helpful and powerful concepts for organizing ourselves. The other aforementioned "features" are helpful for many, but I feel that very often organinzing the "GTD list," and our lives to fit ino a GTD list is often too much of a burden and gets in the way of doing things.

I'm interesting in finding out how people these days are talking and thinking about GTD these days. I think the fad has died down, and I'm interested in seeing what we've as a geeky community have learned from the experience.

Interestingly, I'm probably doing something much closer to what GTD recomended these days than I ever have before. org-mode is (among many other things) a capiable GTD tool. I think it's successful not simply because it supports GTD, and the task-management features seem to have grown out of an emacs/writing writing platform rather than a calendar platform. The end result is that I've found the GTD way to be quite effective, though its largely unintentional.

I'm interested in hearing where your own systems are, and how you feel about GTD these days:

• Do you use GTD or GTD based methodologies for your personal organization?
• If you only use some which, and why?
• If you don't use GTD, what system if any do you use?
• If you once used GTD but stopped, or have considered using GTD and then didn't, I'm particularly interested to learn why you came to these conclusions?
• What current factors influence the way that you organize your work?

I hope that covers everyone. I'm particularly interested by how creative folks work, but i think in the right light that covers most of us. I look forward to hearing from you?

Cheers, sam

[1]	Not the least of which is the way GTD (et al) classify the problem of work acomplishment to be a "productivity problem" rather than an issue of "effectiveness".

My grandmother reminds me that she got a laptop in the late eighties, [1] it's massive by today's standards (particularly in comparison to my 12 inch thinkpad), but it had a great keyobard, and she remembers using it rather effectively. It had WordPerfect 5.1 back in the day but I think it also had StarWriter/StarOffice (which, the astute will recognize as the predecessor code-base for today's Open Office). It probably weight ten or fifteen pounds, and I think she even brought it between work and home several times a week (using a luggage cart); but this was before her days on the Internet, and like all good things this laptop has gone to the land beyond.

For my college years, and a few years after I was a laptop-only computer user. It didn't make sense to have a computer that I'd have to move so damn frequently, and it wasn't like I was playing games or anything that would require desktop, and I loved having only one machine to keep current and up to date. It seems like laptop-only is a definite trend among the Internet-hipster/start-up monkey crowd. And it's admirable, and for these folks (who are likely, and appropriately, Apple users) a laptop-tax of 400 dollars isn't too much for people who have already bought into the Apple tax.

And then, along came the "netbook" phenomena, which posits that most of the time we don't really need a desktop-grade laptop when we're on the run. There's a lot of merit to this model as well. We don't really need to carry around powerhouses to check our emails in coffee shops, and for folks like me for whom the vast majority of our computing is pretty lightweight, building a system around a primary desktop computer and a sufficient but not supercharged laptop makes a lot of sense.

So what kind of laptop system do you use?

[1]	Turns out it was a toshiba t100. Here's another picture/account

I just wanted to check to see if you all use RSS, and if so I have a few questions:

• Is one of the primary ways you interact with content on the web?
• What software do you use to read feeds? (Google Reader? NetNewsWire? Lifrea? Newsbeuter? FeedGator/FeedDemon? LiveJournal?).
• What's your biggest pet peeve about the RSS ecosystem? (including feed readers, feed parsers, variations in feed generation/publication, under/over adoption).

Thanks.

(my answers? yes; google reader; non-full text feeds and generally lackluster reading options.)

I look forward to hearing what you have to say.

People who use free software are almost all "open source/software freedom advocates" in on sense or another. There's something empowering about the experience of using software that you control, really control, and we want to share this with others. That makes sense, not just on a "lets get the family using GNU/Linux" level, that we want to increase the user base of free software as much as possible.

One of the chief recruiting concerns for communities, seems to be "lets make this piece of software more usable." This gets us into a lot of trouble as a community as there are a lot of similar and intersecting issues that get confused in the project of increasing usability. While "usable" is a subjective thing in the end, there are a lot of factors that make software more or less useable, they include:

• greater or lesser functional complexity,
• more or less visual clarity (of control interface and data visualization,)
• functional and/or visual minimalism,
• thoroughness of documentation and support materials, and
• the learning curve.

One of the most powerful effects of free and open source software is the way that it encourages users to learn more about the software and systems they use. We say that one of the reasons for software freedom is "education," and you might think that this relates to the great potential for the use of GNU/Linux in schools, but I think it really relates to the way free software encourages users to learn more about the software they're running.

Given these notions, I must say that writing software that "even a non technical user could learn" (dumbing down features and interfaces) doesn't strike me as a very productive project, and a poor excuse for providing good documentation and support for a given project.

But maybe that's just me.