I've been thinking about how ideas, projects, and ideas scale a bit in the past few weeks, and as usual, I wanted to collect a few of these thoughts. This post is generally in my series of posts of "Extrapolations from Systems Administration." Inspirations and origins of these ideas come from, in part:

• My Tumblr Killed the Tumblelog Star post.
• My Google reader unread count.
• Savage Minds Post on Social Enterpernurship and Anthropology post.
• All the television I don't watch.
• The nginx HTTP Proxy module.
• Seeing the Forest for the Brand

The internet is a big place, you don't need me to tell you this, but I think that it's really incomprehensibly big. Even the small corners of the internet that we (well, I at least,) inhabit contain vast amounts of information and it's very difficult to keep your head above water, to feel like you're in touch with what's happening. Strategies for managing this information successfully are as concerned with "figuring out what to ignore," as they are about figuring out how to absorb information successfully.

Scaling an idea or a concept (like a blog, or a piece of software or a web server) to be able to address problem sets (like an audience, or a given set of data, or both) of different sizes is just as difficult. It's tough to get a web server to be able to host really large loads, its difficult to be able to write a blog that appeals to a huge audience: the this nexuses of related problems are quite large.

I think, however, we can begin to draw some conclusions. I do hope that you'll be able to help me add to this list. Perhaps in a wikish page.

1. Be the biggest fish in the smallest possible pond.

   The core strategy here is to avoid having to figure out how to scale up to "full speed," by reframing the problem set. You don't have to become the most popular or widely consumed blogger/novelist: you just have to become the most popular blogger about cyborg philosophy, or the political economics and philosophy of the open source world. You have to become the most popular post-colonial historiography space opera novelist.

2. Don't participate in the proliferation of crap: only build/use what you need to.

   I see lots of people say something along the lines of "I want to make a websites for all of the people interested in what I'm interested in, and we'll need a wiki and some discussion forums, and some sort of blogs, maybe a lot of blogs, and..." This inevitably leads to a bunch of organization and building of things for their websites, and then everything is built and... no one is interested in using the crap.

   This is a classic premature optimization problem. Don't build things that you think you might need later. Build things that you need now. Or things that you really needed last week. Focus on the thing you do, and build the infrastructure as you need it, when you need it.

3. Work in a scalable and sustainable manner, and assume that other people will need to pick up on your projects.

   While you shouldn't expend the effort to scale before you need to, because that could end in failure, it's common sense to approach your projects with the assumption that other people might have to finish them for you, if things take off and you need to delegate later you'll be ready for them. Consider the possibility that you might need to scale a project when you're in the initial planning stages and avoid getting backed into a corner by a decision.

4. Ignore everything you can possibly stand to.

   There are so many things that you could be doing with your time. There are so many distractions. Email lists, RSS feeds, the work of other people in your field. Charity projects of one sort or another. All of these things are important and you should participate fully in the communities that surround your work, but be fully aware that humans as individuals don't scale well, and succeeding at [your project] is dependent upon your ability to ignore everything that you can stand to.

5. Consume information on your terms, in the formats that make the most sense to you.

   As a corollary to the above, the way to successfully engage and manage everything that you can't possibly stand to ignore is to as much as possible engage on your terms. Figure out what your terms are first, and then work to consume content in these terms.

6. Use technology and media to build relationships rather than accumulate information.

   Too often, I think, the geekier among us (and I count myself among this number) are interested in technology because it's cool, and we're tempted to solve technological problems and learn about the inner workings of stuff because they interest us. And that's okay, as a hobby: in the pursuit of doing work, technology is only useful insofar as it allows you to get things done. And in most cases, the core function that technology provides is to enable relationships. So focus on that, and fiddle with the technical underpinnings, only when you must.

Onward and Upward!

This post represents two major ideas, first of "app stores," and second of "Sass" or "software as a service," which seems to be the prevailing business model for contemporary technology companies that aren't stuck in the 80s. With reflection on free software, open source, and the technology industry as a whole. Because that's sort of my thing.

On the one hand the emergence of these tightly controlled software distribution methods represent a fairly serious threat to free software, as does SaaS particular insofar as SaaS exploits a GPL loophole. On the other hand these models, potentially, represent something fundamentally awesome for the technology and software world, because it represents a commonly accepted paradigm where users of software recognize the value of software, and the creators of software can get compensated for their work. It's not without its flaws, but I think it opens interesting possibilities.

Ok, so not really.

This post is mostly about playing a head game with yourself, in an effort to get more organized. But not "head games" in a bad way. On my to do list for the past few weeks I've had something like "write a blog post about todo list item titles," because in light of this post about org-mode it seems like a topic in need of further definition. Basically my goal is to explore, the best way to think about what we have to do, to allow us to accomplish what we want to. The GTD system which so many people are enamored of present a few ideas on the topic, and while the GTD way is a good place to start thinking, it's not a good place to stop thinking.

We've all done it. Made a todo list that we didn't end up using for one reason or another. Todo lists, need to be useful: they should help us organize our day, and help us keep track of all the things wee need to accomplish. In a lot of ways, maintaining focus over our day and all of the tasks that nag at us are contradictory, so todo lists are failed by design.

The first, and frequent issue in my own organization are lists and plans that go too far and list too many "actionable items." This divides your time and actions into too many little pieces, leading to a number of outcomes. The first risk is that you might start to ignore the list entirely because it's too long and complicated, even if it's an illusion caused by the size of the items on your list. Ergo, the total length of the list you "work off of," needs to be manageable and comprehensible.

The second risk, is that, an overactive todo list is one where you over plan for yourself, such that your list--while accurate and comprehensible--isn't useful. Beyond simply providing "outboard memory," the best todo lists allow us to structure and make plans for our working time. When working (e.g. writing, at the computer, etc.), I like to have my projects chopped up into pieces that can conceivably get done in the time I have to work on them, but that give me the time and freedom to bury myself on a side project, or follow inspiration or a train of thought to its completion when needed. While effective todo lists help you structure your time, flexibility is still valuable.

There are issues on the other end of the spectrum as well: when lists are too short, and the "actionable items" on a list are too conceptually large, the effectiveness of lists is degraded as well. A reminder to "write a novel," even a specific novel, is less than helpful for helping you accomplish something in the moment. Even a dozen items, on a list where you end up checking something off once every day or two doesn't help you figure out "Ok, what do I need to work on now." Besides the chances are, if the items are too large and the list is too small, that you probably have it memorized anyway.

Right? Other strategies?

As you all might have heard that Amazon (finally) released a Kindle Application for the Blackberry. When I heard this I thought that this would be a good thing, as I have (and quite enjoy) both my Blackberry and Kindle. Here's the rundown:

• The Kindle App for the blackberry is probably the most well designed blackberry application I've seen thus far. Having said that, the bar isn't terribly high.

  In a lot of ways, the way (before the Kindle app) to make a "successful" blackberry application is one that figures out how to make its data "fit" into an email or messaging context and then blend that data into the messaging/event feed in a useful sort of way.

  This doesn't do that, and I think learns a great deal from advancements made in iPhone app development. The resolution on the Blackberry Bold is amazing (same number of pixels as the iPhone, much greater density.) and the buttons/interface is really intuitive and well designed. The app itself gets as many thumbs up as I can manage.

• I've been having phone angst recently. I don't use it very much, I need to have better filtering of my email and reorganize how I do my voice mail, and while this is easy enough to say here it's a much more substantial project than I've got time for now.

• The Kindle App isn't a replacement for the kindle, but it's a great compliment, and it makes it much more possible to lighten the load in my back-bag, and it makes it easier for me to entertain myself with my phone. This might not seem like a bit deal, but I think it is.

  There are also situations where the Kindle isn't usable (in bed when the lights are off and various other low light situations) and that's alright, but the Kindle app is. So that's a good thing indeed.

• I had hoped that the kindle would make it easier to read in the in between moments throughout the day when I might read but didn't. That isn't exactly true, as it turns out. Reading on the Kindle still requires a fair piece of directed attention, and it's not the kind of thing you can idly whip out while you're waiting in the grocery check out line.

  I'm not sure at this point, of course, but I do think that having access to the Kindle on the phone will improve this usability feature.

• I'm sort of annoyed by the lack of subscriptions. While you can have multiple devices attached to your Kindle account, when you subscribe to a periodical, that content is only accessible to you on one of your devices. I don't really like this, and it represents a huge loss of value for the Kindle store.

While I got the Blackberry shortly after the first iPhone 3g came out, the "app explosion" hadn't really happened yet. I must confess some "app jealousy." The Blackberry is awesome, and really it does the messaging quite better than anything else around (I'm convinced.) And I love the hardware keyboard. But when I think "I'd like to do something with my phone," the chance of getting a Blackberry app to do that is... unlikely. I don't know if I want a lot of apps on my phone, in the end, but I know the hardware is capable, and it's nice to take advantage of that from time to time. In any case...

Onward and Upward!

Perhaps part of the reason the iPad doesn't make sense for me is that I've never really used an iPhone, and at the core iPad is basically iPhone++. I opted to get a Blackberry because I wanted a device that did email right and messaging, I had/have an iPod Touch that I don't really use and the little isolated applications that don't interact well with my existing work flow and lock data in didn't really appeal to me.

People are always talking about "the apps," as if there's something revolutionary happening here, and I've always been a bit non plussed. At least for my personal use, more "applications," or places where "things can be done," doesn't always equate into more productivity.

Running in parallel to this, of course is the whole Web 2.0/web-based application development thing. (Is Web2.0 coasting to a halt yet? In any case, it's probably still a current phenomena worth noting.) Although iPhone applications and Web applications are constructed in very ways that are quite technically distinct, there's an underlying commonality between the way that both function. These applications are very much not general purpose. The best iPhone (or web) applications take a specific kind of data or information (or a collection of such), and provide a way for you to interact with that information in a way that's (hopefully) intuitive.

In contrast the old familiar applications typically are designed to be either: platforms that enable you to accomplish a whole range of tasks within a certain sphere ("Office tools," email applications, emacs), or some sort of filter or pipe that allows you to access data in one format in an interface that's easy to use (RSS readers, Content management systems, pdf readers, web brwosers, etc.) There are certainly web applications that are basically pipes, and I'm sure Google would love it if we all used their application stack.

So, then, what describes this new "widget," class of applications for mobile devices and the web? On the one hand it's a case of developers "making do with what there is:" the iPhone imposes a number of serious constraints: small screen, limited on board computing resources, and a potentially inconsistent data connection. Small structured apps that are all about allowing you to interact with a small set of data work best in this environment. Additional I suspect that technology has advanced to a point where making these kinds of applications is finally possible and worth the it takes to build them: MVC frameworks have finally matured perhaps.

The enduring questions in my mind:

• Is the data that we're throwing into databases by way of iPhone apps and web applications going to continue to be useful in the future? This gets at the "open data" question as much if not more than the "open source" aspect of applications. What's the realistic utility of our data in the long form?
• Does this shift mark a move away from a certain kind of "paper-based logic," to a more digital way of organizing or data and digital experiences?
• Is this just the process of bringing the kinds of "business applications," that enterprises have developed and used for decades into the consumer sphere?
• How do the concepts of software freedom and data ownership transfer to this mode of using technology. While it's easy to say "data ought to be free," and "source code still matter" (both of which are true,) I think practically it's a bit more difficult.
• What do these applications look like on the Desktop? Is the future JavaFX, Flex, Silverlight, and Apple Desktop Widgets? Is the desktop going to be stuck in the browser? Are there other options?

And while I think we're definitely using and creating this kind of software with abandon, I don't know if we've reached good answers to these (and other related) questions. I look forward to exploring these ideas, and hearing your thoughts!

A few years ago, highly citational, link/youtube video blogs came back into style again. This time rather than calling them blogs, we called them "tumblelogs." I never really got into it, though I tried, and even my original inspiration for starting tychoish.com was to do a more "tumblelog-esque" blog.It never quite worked out. Then I read this post by Michael Coté which inspired a few things:

First, it got the following title to stick in my head and refuse to get out. Second, it left me with the idea that, although successful, sites like tumblr and to a different extent posterous basically ruined the tumblelogging revival.

Here's the thing about tumblelogs: they worked and worked so well because they were efficient, because the people creating tumblogs were doing something unique and had unique voices, because you could keep your pulse on most of a single discourse by watching only a few sites/rss feeds. And then it became, very suddenly, trivial to make a tumble log. And so everyone had a tumblelog, and it was like blogging was new again, except things "meme'd out" at an epic pace and it became difficult to track what anyone was saying. It was like a distributed denial of service attack on our attention spans.

And as the dust settled, tumblelogs, at least as far as I could see, became less about a sort of delightful amalgamation of interesting content and more about templates, about piping in a fire hose of content from delicious/twitter/etc. So not only were there too many tumblelogs, but the style had devolved somewhat into this weird unedited, awkwardly template-ed mass of "crap" that is (in my opinion) quite hard to read or derive value from.

By day I write documentation for systems administrators, and as a result I spend a lot (perhaps too much?) time thinking about how we organize computer systems so that they can be both useful and easy to manage in the long run. "Right, so..." you say? Well indeed. Recently it's become clear to me that there are some generalizable lessons to be learned from sys-admining that might be helpful to those of us who are less organized than they'd like to be.

Which is pretty much everyone, right?

Right. In brief:

• Automate everything that can be automated.
• Closely followed by don't automate something that doesn't need automation.
• Prefer simplicity over complexity, and prefer systems that require you to remember fewer things.
• Design systems to make it possible for others to easily understand what you've done.

To elaborate: