git, flashbake, and audience

I've mentioned a while back (surely) a program called flashbake, which Gina Tripani covered on lifehacker a while ago, and while I don't think I could add anything this review, I can provide you with links, and talk a bit about how hacker-types get their starts, and how audiences for free software are formed.

This is, I think, a big issue facing the free software movement, basically: we build great software, how do we get (more) people to use it.

The issue is that free software doesn't have advertising budgets, free software projects don't have muscle with operating system vendors (MS) to bundle applications, and for the most part free software projects can't get their software distributed on hardware (eg. the dell-Microsoft relationship).

And then on top of requiring users to actively choose open source, a lot of free software requires a certain level of technical knowledge, and the documentation is poor, and open source projects can't (generally) afford the kind of usability studies that closed-development projects rely on, and as a result it often takes a few generations for applications to really work.

The conventional response is to try and make software as usable and intuitive as possible, and I've written before about the problems of treating your users like idiots and some issues regarding user experience issues, and in general I think the conclusion is: our goal should be to unobtrusively turn less technical users into more technical users, rather than turn more technical computing domains into less technical computing domains. Make people smarter, rather than make computer interfaces smarter.

I think, in a weird way, GNU Emacs does this pretty well. A hacker might not know very much (emacs-)Lisp when they start to use emacs, but for the most part it doesn't take people very long to get to a point where they can hack things together in elisp and understand what's going on in the emacs code that they download.

So back to git and flashbake. Right.

I actually don't think that flashbake treats users like idiots. In fact, git was built so that new interfaces could be added to the system without breaking compatibility with other git repositories.

Git is a filesystem, basically. A microfilesystem, if you will, with a notion of versioning--storing iterations across time--and distribution--replicating the store across locations. In order to make both of these features work, it has to have top level support for branches and merging (and it does).

But beyond those capabilities, what goes in to git doesn't seem to matter much. And once you start using git, and you get a feel for how it works, the more you want to put into it.

Flashbake is just a tool for putting writing into git.

Programmers who aren't familiar with how writers work and think may say "why would you want to commit so often?" Or, "why would I want to know what the weather is every fifteen minutes while I do my work?" But I think it makes sense, and makes it possible a sort of digital archeology of a text that writers--myself included--are really intrigued with. Particularly given that "the cost" of running a script like this in the background is so small.

Anyway, give it a try if you're so enclined.