As this blog ambles forward, albeit haltingly, I find that the process of generating the site has become a much more complicated proposition. I suppose that’s the price of success, or at least the price of verbosity.

Here’s the problem: I really cannot abide by dynamically generated publication systems: there are more things that can go wrong, they can be somewhat inflexible, they don’t always scale very well, and it seems like horrible overkill for what I do. At the same time, I have a huge quantity of static content in this site, and it needs to be generated and managed in some way. It’s an evolving problem, and perhaps one that isn’t of great specific interest to the blog, but I’ve learned some things in the process, and I think it’s worthwhile to do a little bit of rehashing and extrapolating.

The fundamental problem is that the rebuilding-tychoish.com-job takes a long time to rebuild. This is mostly a result of the time it takes to convert the Markdown text to HTML. It’s a couple of minutes for the full build. There are a couple of solutions. The first would be to pass the build script some information about when files were modified and then have it only rebuild those files. This is effective but ends up being complicated: version control systems don’t tend to version mtime and importantly there are pages in the site--like archives--which can become unstuck without some sort of metadata cache between builds. The second solution is to provide very limited automatically generated archives and only regenerate the last 100 or so posts, and supplement the limited archive with more manual archives. That’s what I’ve chosen to do.

The problem is that even the last 100 or so entries takes a dozen seconds or more to regenerate. This might not seem like a lot to you, but the truth that at an interactive terminal, 10-20 seconds feels interminable. So while I’ve spent a lot of time recently trying to fix the underlying problem--the time that it took to regenerate the html--when I realized that the problem wasn’t really that the rebuilds took forever, it was that I had to wait for them to finish. The solution: background the task and send messages to my IM client when the rebuild completed.

The lesson: don’t optimize anything that you don’t have to optimize, and if it annoys you, find a better way to ignore it.

At the same time I’ve purchased a new domain, and I would kind of like to be able to publish something more or less instantly, without hacking on it like crazy. But I’m an edge case. I wish there were a static site generator, like my beloved jekyll that provided great flexibility, and generated static content, in a smart and efficient manner. Most of these site compilers, however, are crude tools with very little logic for smart rebuilding: and really, given the profiles of most sites that they are used to build: this makes total sense.

I realize that this post comes off as pretty complaining, and even so, I’m firmly of the opinion that this way of producing content for the web is the most sane method that exists. I’ve been talking with a friend for a little while about developing a way to build websites and we’ve more or less come upon a similar model. Even my day job project uses a system that runs on the same premise.

Since I started writing this post, I’ve even taken this one step further. In the beginning I had to watch the process build. Then I basically kicked off the build process and sent it to the background and had it send me a message when it was done. Now, I have rebuilds scheduled in cron, so that the site does an automatic rebuild (the long process) a few times a day, and quick rebuilds a few times an hour.

Is this less efficient in the long run? Without a doubt. But processors cycles are cheap, and the builds are only long in the subjective sense. In the end I’d rather not even think that builds are going on, and let the software do all of the thinking and worrying.

A reader (hi grandma!) asked me to write a post about why I’m so interested in open source, and who am I to refuse. In fact, I tend to do requests pretty well, so if there’s a subject you’d like to see me cover here, just ask and I’ll see what I can do. In any case, I’ve been involved, for varying definitions of involved, in Free Software and open source for a few years now. On a personal level, I use this software (almost exclusively) because I can make it do exactly what I need it to do, because it’s very stable, and because from an architecture perspective I understand how these systems work and that’s useful for me. Having said that, I think open source is important and worth considering for reasons beyond the fact that I (and people like me) find it to be the most important tool for the work we do.

When folks get together and say “I’m going to work on an open source project,” I think some interesting things happen. First, they’re making a number of interesting economic decisions about their work. There are business models around open source, but they are more complex than “I make software, you give me money for software,” and thus require people to think a little bit more widely about the economic impact of their work. I think the way that people view the implications of their labor is incredibly important, and free software presents an interesting context to think about these questions.

The second, and perhaps larger reason I’m interested in open source is the community. Open source developers often know that the things they want to create are beyond the scope of their free time and personal ability, so they collaborate with other people to make something of value and worth. How this collaboration happens: what motivates developers, how they create tools and technologies to support this kind of work flow, how the “intellectual property” is negotiated (particularly in projects that don’t use the GNU GPL,) how leaders are selected and appointed, how decisions are made as a community, and how teams are organized and organize themselves. These are intensely fascinating.

And these phenomena matter, both in and for themselves, but also as they impact and connect with other questions and phenomena in the world. For instance:

• I think that the decision making process in free software projects is instructive for thinking about how all sorts of communities can reach a “decision making fork” resolve it somehow and then continue with their work. Some open source projects have formal structures, and that is easier to understand from the outside, but most make decisions in an informal way, and that decision making process is potentially novel, I’d argue. In what other context do people have to construct projects outside of work.
• While leaders in the open source community are rarely elected (aside from a number of notable examples; the Debian Project Leader springs instantly to mind) most projects are very democratic. But this requires that we keep in mind a fairly broad definition of democracy. Because there isn’t a lot of voting, and sometimes decisions aren’t discussed thoroughly before people start doing things, it doesn’t look democratic. But everything is volunteer based, and leaders I think have a sense of responsibilities to their constituencies, which is meaningful.
• The tools that open source developers use are, unsurprisingly open source, and are often picked up and used by teams that aren’t making free software. I’m interested in thinking about how “ways of working,” proliferate out of open source and into other spheres. Is non-open source developed differently if the developers are familiar with and use open source tools?
• Similarly, I think I’m interested in thinking about how the architecture of Linux and Unix give rise to a thought about APIs and open standards in a way that doesn’t necessarily happen on closed platforms. After a certain point, I think I’m forced to ask: is GNU/Linux the leading free software/open source platform because it just happens to be, or because it’s UNIX. Is there something special about the design of UNIX that leads to openness, and the practices of openness? To what extent does the limitations of the environment (operating system here) the social conventions that are built on it?

And then beyond the specific questions--which are terribly important in and of themselves--open source present a terribly exciting subject for the study of these issues. There is so much data on the ground concerning open source: version control history, email logs, IRC logs, and so forth. Not only are the issues important but the data is rich, and I think has a lot to tell us if we (I?) can bother to spend some time with it.

Ok. I can’t be the only one.¹

I look at open source projects like OpenSolaris, Alfresco, Resin, Magento, OpenSuSE, Fedora, and MySQL, among others, and I wonder “What’s the community around these projects that people are always talking about.” Sure I can download the source code under licenses that I’m comfortable with, sure they talk about a community, but what does that mean?

What, as a company, does it mean to say that the software you develop (and likely own all the rights to,) is “open source,” and “supported by a community?”

If I were sensible, I’d probably stop writing this post here. From the perspective of the users of and participants in open source software, this is the core question, both because it dictates what we can expect from free software and open source and more importantly because it has been historically ill defined.

There are two additional, but related, questions that lurk around this question, at least in my mind:

1. Why are new open source projects only seen as legitimate if the developers are able to build a business around the project?

2. What does it mean to be a contributor to open source in this world, and what do contributors in “the community,” get from contributing to commercial projects?

There are of course exceptions to this rule: the Debian Project, the Linux Kernel itself, GNU packages, and most open source programming languages among others. I’d love to know if I’ve missed a class of software in this list--and there’s one exception that I’ll touch on in a moment--but the commonality here is that that these projects are so low level that it seems too hard to build businesses around directly.

When “less technical” free software projects began to take off, I think a lot of people said “I don’t know if this open source thing will work when the users of the software aren’t hackers,” because after all what does open source code do for non-hackers? While it’s true that there are fringe benefits that go beyond the simple “free as in beer” quality of open source for non-hacker users, these benefits are not always obvious. In a lot of ways the commercialization around open source software helps add a buffer between upstreams and end users. This is why I included Debian in the list above. Debian is very much a usable operating system, but in practice it’s often an upstream of other distributions. Ubuntu, Maemo, etc.

The exception that I mentioned is, to my mind, projects like Drupal and web development frameworks like Ruby on Rails and Django. These communities aren’t sponsored or driven by venture capital funded companies. Though the leader of the Drupal community has taken VC money for a Drupal-related start up. I think the difference here is that the economic activity around these projects is consulting based: people use Drupal/Django/Rails to build websites (which aren’t, largely open source) for clients. In a lot of ways these are much closer to the “traditional free software business model,” as envisioned in the eighties and nineties, than what seems to prevail at the moment.

So to summarize the questions:

• What, as a company, does it mean to say that the software you develop (and likely own all the rights to,) is “open source,” and “supported by a community?”
• What does it mean to participate in and contribute to a community around a commercial product that you don’t have any real stake in?
• How does the free software community, which is largely technical and hacker centered, transcend to deal with and serve end users?
• How do we legitimize projects that aren’t funded with venture capital money?

Onward and Upward!

This post covers the role and purpose (and utility!) of analysts and spectators in the software development world. Particularly in the open source subset of that. My inspirations and for this post come from:

• Why is there no Anthropology Journalism?
• This Video Featuring an interview with Michael Coté of Red Monk

In the video Coté says (basically,) open source projects need to be able to justify the “business case” for their project, to explain what’s the innovation that this project seeks to provide the world. This is undoubtedly a good thing, and I think we should probably all be able to explore and clearly explain and even justify the projects we care about and work on in terms of their external worth.

Project leaders and developers should be able to explain and justify the greater utility of their software clearly. Without question. At the same time, problems arise when all we focus on is the worth. People become oblivious to how things work, and become unable to successfully participate in informed decisions about the technology that they use. Users, without an understanding of how a piece of technology functions are less able to take full advantage of that technology.

As an aside: One of the things that took me forever to get used to about working with developers is the terms that they describe their future projects. They use the imperative case with much more ease than I would ever consider: “the product will have this feature” and “It will be architected in such a way.” From the outside this kind of talk seems to be unrealistic and grandiose, but I’ve learned that programmers tend to see their projects evolving in real time, and so this kind of language is really more representative of their current state of mind than their intentions or lack of communications skills.

Returning for a moment to the importance of being able to communicate the business case of the projects and technology that we create. As we force the developers of technology to focus on the business cases for the technology they develop we also make it so that the only people who are capable of understanding how software works, or how software is created, are the people who develop software. And while I’m all in favor of specialization, I do think that the returns diminish quickly.

And beyond the fact that this leads to technology that simply isn’t as good or as useful, in the long run, it also strongly limits the ability of observers and outsiders (“analysts”) to be able to provide a service for the developers of the technology beyond simply communicating their business case to outside world. It restricts all understanding of technology to journalism rather than the sort of “rich and chewy” (anthropological?) understanding that might be possible if we worked to understand the technology itself.

I clearly need to work a bit more to develop this idea, but I think it connects with a couple of previous arguments that I’ve put forth in these pages one regarding Whorfism in Programming, and also in constructing rich arguments.

I look forward to your input as I develop this project. Onward and Upward!

I’ve been thinking recently about the relationship and dynamic between the corporations and “enterprises” which participate in and reap benefits from open source/free software and the quasi-mythic “communities” that are responsible for the creation and maintenance of the software. Additionally this post may be considered part of my ongoing series on cooperative economics.

When people, ranging from business types, to IT professionals, to programmers, and beyond, talk about open source software we talk about a community: often small to medium sized groups of people who all contribute small amounts of time to creating software. And we’re not just talking about dinky little scripts that make publishing blogs easier (or some such), we’re talking about a massive amount of software: entire operating systems, widely used implementations of nearly all relevant programing languages, and so forth. On some level the core of this question is who are these people, and how do they produce software?

On the surface the answer to these questions is straightforward. The people who work on open source software are professional programmers, students, geeks, and hacker/tinkerer-types who need their computers to do something novel, and then they write software. This works as model for thinking about who participates in open source, if we assume that the reason why people contribute to open source projects is because their individual works/contributions are too small to develop business models around. This might explain some portion of open source contributions, but it feels incomplete to me.

There are a number of software projects that use open source/free software licenses, with accessible source code, supported by “communities,” which are nonetheless developed almost entirely by single companies. MySQL, Alfresco, and Resin among others serve as examples these kinds of projects which are open source by many any definitions and yet don’t particularly strike me as “community,” projects. Is the fact that this software provides source code meaningful or important?

Other questions…

1. If there are companies making money from open source code bases, particularly big companies in a business directly related to software, does this effect participation of people who are not employed by that company in the project?

In my mind I draw distinctions between technology businesses that use/sell/support open source software (e.g. Red-Hat, the late MySQL AB, etc.) and businesses that do something else but use open source software (i.e. everyone with a Linux server in the basement, every business with a website that runs on Apache, etc.)

2. Does corporate personhood extend to the open source community. Are corporate developers contributing as people, or as representatives of their company?

I largely expect that it’s the former; however, I’d be interested in learning more about the various factors which affect the way these contributors are perceived?

3. Do people participate in open source because it is fun or for the enjoyment of programming,

4. Has software become so generic that open source is a current evolution of industry standards groups. Do we write open source software for the same reason that industries standardized the size and threading of bolts?

5. Are potential contributors disinclined to contribute to software that is controlled by a single entity, or where projects

6. Is the cost of forking a software project too high to make that a realistic outcome of releasing open source software?

Conversely, were forks ever effective?

7. Do communities actually form around software targeted at “enterprise” users, and if so in what ways are those communities different from the communities that form around niche window p managers or even community projects like Debian?

I don’t of course have answers yet, but I think these questions are important, and I’d love to hear if you have any ideas about finding answers to these questions, or additional related questions that I’ve missed.

There’s an issue in tiling window managers, that I think a lot folks who are used to floating window managers never expect. I wrote a post to the Awesome listserv a while back explaining this to someone, and it seems to have struck a chord (I saw the post linked to last week). I thought I’d write a brief post here to explain what’s going on in a more clear and general way.

The Problem

When tiled, windows don’t seem to take up all the space that’s available to them. This creates weird “gaps” between windows. But only some windows: Firefox is immune to this problem, while terminal emulators like xterm, and urxvt, and gVim, and emacs get all funky.

What’s Happening

The application that are affected by this draw their windows based upon a number of fixed width columns. We’ll note that terminal emulators, as well as GUI versions of programmer’s text editors like vim and emacs, all used fixed-width fonts and often allow you to set window sizes based on the number of columns (of characters).

As a result, these applications are only able to use space on the screen in increments of full characters. Most of the time, in floating window managers, we never really notice this limitation.

In tiling window managers you do notice, because the window manager forces the windows to use all available space, except in some windows it leaves these weird gaps at the bottom and right of the window. Sometimes the gaps end up in the window, as unusable buffers, and sometimes they end up between windows. It looks funny, pretty much no matter how you slice it.

What You Can Do About It

The truth? Not much.

The Awesome Window Manager, by default shows the gaps between the windows. I always found this to be the “more ugly” option. You can alter this behavior by searching your configuration file for size_hints_honor and making the line look like this:

c.size_hints_honor = false

This tells Awesome to ignore windows (client’s) when they say “I want to have these dimensions.” It doesn’t fix the problem but it does get rid of the gaps.

The real solution is to tweak text sizes, fonts, and any buffering elements (like a status bar, mode line, or widget box), and window borders so that the windows aren’t left with extra space that they don’t know how to cope with.

By real solution, I really mean “only option:” it’s really impossible to get all of your fixed width applications to have exactly the right number of pixels. You can get close in a lot of situations, and I’ve always found this to be much less annoying than using floating window managers.

The Original Post

Just for giggles, I’ve included a quoted portion of what I posted original to the listserv on the topic.

The one big of information that might be important: The urxvt terminal emulator, when not “honoring size hints,” is unable to really properly draw the “extra space” with the proper background. I suspect this is a bug with the pseudo-transparency system they use. As a result there are often a few pixels with the background in an inverted color scheme. Same problem as above, but it looks funny if you’re not used to it.

What’s happening is that urxvt (like many terminal emulators) can only draw windows of some specific sizes based on the size of the characters (eg. x number of rows, and y number of columns.) So while you may have larger and the equivalent of say 80.4x20.1, urxvt can’t do anything with this extra space.

If you honor size hints, the windows will end wherever they can, and use as much space as they can, but leave gaps between windows if the total space isn’t properly divisible. If you don’t honor size hints, the windows themselves take up the extra room (but they can’t do anything with the extra room, so they just leave it blank, and sometimes the transparency is a bit wonky in those “buffers”).

So there you have it. I hope this helps!

In “Radicalism in Free Software, Open Source” I contemplated the discourse of and around radicalism in and about Free Software and Open Source software. I think this post is a loose sequel to that post, and I want to use it to think about the role.

I suppose the ongoing merger of Sun Microsystems and Oracle, particularly with regards to the MySQL database engine weights heavy on many of our minds.

There are a number of companies, fairly large companies, who have taken a fairly significant leadership role in open source and free software. Red Hat. Sun Microsystems. IBM. Nov ell. And so forth. While I’m certainly not arguing against the adoption of open source methodologies in the enterprise/corporate space, I don’t think that we can totally ignore the impact that these companies have on the open source community.

A lot of people--mistakenly, I think--fear that Free Software works against commercialism¹ in the software industry. People wonder: “How can we make money off of software if we give it away for free?”² Now it is true that free software (and its adherents) prefer business that look different from proprietary software businesses. They’re smaller, more sustainable, and tend to focus on much more custom deployments for specific users and groups. This is in stark contrast to the “general releases” for large audiences, that a lot of proprietary audiences strive for.

In any case, there is a whole nexus of issues related to free software projects and their communities that are affected by the commercial interests and “powers” that sponsor, support, and have instigated some of the largest free software projects around. The key issues and questions include:

• How do new software projects of consequence begin in an era when most projects of any notable size have significant corporate backing?
• What happens to communities when the corporations that sponsor free software are sold or change directions?
• Do people contribute to free software outside of their jobs? Particularly for big “enterprise” applications like Nagios or Jboss?
• Is the “hobbyist hacker” a relevant and/or useful arch-type? Can we intuit which projects attract hobbyists and which projects survive because businesses sponsor their development, rather than because hobbyists contribute energy to them. For example: desktop stuff, niche window managers, games, etc. are more likely to be the province of hobbyists and we might expect stuff like hardware drivers, application frameworks, and database engines might be the kind of thing where development is mostly sponsored by corporations.
• Is free software (or, Open Source may be the more apropos terminology at the moment) just the contemporary form of industry group cooperation? Is open source how we standardize our nuts and bolts in the 21st century?
• How does “not invented here syndrome” play out in light of the genesis of open source?
• In a similar vein, how do free software projects get started in today’s world. Can someone say “I want to do this thing” and people will follow? Do you need a business and some initial capital to get started? Must the niche be clear and undeveloped?
• I’m sort of surprised that there haven’t been any Lucid-style forks of free software projects since, well, Lucid Emacs. While I’m not exactly arguing that the Lucid Emacs Fork was a good thing, it’s surprising that similar sorts of splits don’t happen any more.

That’s the train of thought. I’d be more than happy to start to hash out any of these ideas with you. Onward and Upward!

The background:

• zonker on Selling vs. Shaming
• bkuhn on Denouncing vs. Advocating: In Defense of the Occasional Denouncement
• Various other conversations on identi.ca over the past few weeks.

In light of this debate I’ve been thinking about the role and manifestations of radicalism in the free software and open source world. I think a lot of people (unfairly, I think in many cases) equate dedication to the “Cause of Free Software,” as the refusal to use anything but free software, and the admonishment of those who do use “unpure” software. To my mind this is both unfair to Free Software as well as the radicals who work on free software projects and advocate for Free Software.

First, lets back up and talk about RMS¹. RMS is often held up as the straw man for “free software radicals.” RMS apparently (and I’d believe it) refuses to use software that isn’t free software. This is seen as being somewhat “monkish,” because doesn’t just involve using GNU/Linux on the desktop, but it also involves things like refusing to use the non-free software written for GNU/Linux, including Adobe’s Flash player, and various drivers. In short using the “free-only” stack of software is a somewhat archaic experience. The moderates say “who wants to use a computer which has been willfully broken because the software’s license is ideologically incompatible,” and the moderates come out looking rational and pragmatic.

Except that, as near as I can tell, while the refusal to use non-free software might be a bit traumatic for a new convert from the proprietary operating system world, for someone like RMS, it’s not a huge personal sacrifice. I don’t think I’m particularly “monkish” about my free software habits, and the only non-free software I use is the adobe flash player, and the non-open-source extensions to Sun’s Virtual Box. I’m pretty sure I don’t even need the binary blob stuff in the kernel. For me--and likely for RMS, and those of our ilk--sticking to the pure “free software” stuff works better and suits the way I enjoy working.²

In short, our ability to use free software exclusively, depends upon our habits and on the ways in which we use and interact with technology.

To my mind, the process by which the pragmatic approach to free software and open source radicalizes people like RMS, is terribly unproductive. While we can see that the moderates come away from this encounter looking more reasonable to the more conventional types in the software world, this is not a productive or useful discussion to entertain.

In any case I think there are a number of dimensions to the free software (and open source world,) that focusing on “how free your software” is distracts us from. Might it not be useful to think of a few other issues. They are, as follows:

1. Free software is about education, and ensuring that the users of technology can and do understand the implications of the technology that they use.

At least theoretically, one of the leading reasons why having “complete and corresponding source code” is so crucial to free software is that with the source code, users will be able to understand how their technology works.

Contemporary software is considerably more complex than the 70s vintage software that spurred the Free Software movement. Where one might have imagined being able to see, use, and helpfully modified an early version of a program like Emacs, today the source code for Emacs is eighty megabytes, to say nothing of the entire Linux Kernel. I think it’s absurd to suggest that “just looking at the source code” for a program will be educational in and of itself.

Having said that, I think free software can (and does) teach people a great deal about technology and software. People who use free software know more about technology. And it’s not just because people who are given to use free software are more computer literate, but rather using free software teaches people about technology. Arch Linux is a great example of this at a fairly high level, but I think there’s a way that Open Office Firefox plays a similar role for a more general audience.

2. There are a number of cases around free software where freedom--despite licensing choices--can be ambiguous. In these cases, particularly, it is important to think about the economics of software, not simply the state of the “ownership” of software.

I’m thinking about situations like the “re-licensing” such as that employed by MySQL AB/Sun/Oracle over the MySQL database. In these cases contributors assign copyright to the commercial owner of the software project on the condition that the code also be licensed under the terms of a license like the GPL. This way the owning copy has the ability to sell licenses to the project under terms that would be incompatible with the GPL. This includes adding proprietary features to the open source code that don’t get reincorporated into the mainline.

This “hybrid model” gives the company who owns the copyright a lot of power over the code base, that normal contributors simply don’t have. While this isn’t a tragedy, I think the current lack of certainty over the MySQL project should give people at least some pause before adopting this sort of business model.

While it might have once been possible to “judge a project by the license,” I think the issue of “Software Freedom” is in today’s world so much more complex, and I’m pretty sure that having some sort of economic understanding of the industry is crucial to figuring this out.

3. The success of free software may not be directly connected to the size of the userbase of free software

One thing that I think Zonker’s argument falls apart around is the idea that free software will only be successful if the entire world is using it. Wrong.

Lets take a project like Awesome. It’s a highly niche window manager for X11 that isn’t part of a Desktop Environment (e.g. GNOME/KDE/XFCE), and you have to know a thing or two about scripting and programing in order to get it to be usable. If there were much more than a thousand users in the world I’d be surprised. This accounts for a minuscule amount of the desktop window management market. Despite this, I think the Awesome project is wildly successful.

So what marks a successful free software project? A product that creates value in the world, by making people’s jobs easier and more efficient. A community that supports the developers and users of the software equally. Size helps for sure, particularly in that it disperses responsibility for the development of a project among a number of capable folks. However, the size of a projects userbase (or developer base) should not be the sole or even the most important quality by which we can judge success.

There are other issues which are important to think about and debate in the free software world. There are also some other instances where the “hard line” is over radicalized by a more moderate element, nevertheless I think this is a good place to stop for today, and I’m interested in getting some feedback from you all before I continue with this idea.

Onward and Upward!

When I want to install an application on a computer that I use, I open a terminal and type something to the effect of:

apt-get install rxvt-unicode

Which is a great little terminal emulator. I recommend it. Assuming I have a live interned connection, and the application I’m installing isn’t too large, a minute later or less I have whatever it is I asked for installed and ready to use (in most cases.)

Indeed this is the major feature of most Linux Distributions: their core technology and enterprise is to take all of the awesome software that’s out there (and there’s a lot of it,) and make it possible to install easily, to figure out what it depends on, and get it to compile safely and run on a whole host of machines. Although this isn’t the kind of thing that most people think when they’re choosing a distribution of Linux, one of the biggest differentiating features between distributions. But I digress.

I’ve written about package management here before, but to summarize:

1. We use package managers because many programs share dependencies, that we wouldn’t want to install twice or three times, but that we might not want to install by default with every installation of an operating system. Making sure that everything gets installed is important. This, is I think, a fairly unique-to-open-source problem, because in the proprietary system the dependencies are installed by default (as in there are more monolithic development environments, like .NET, Cocoa, and Java¹, and other older non-managed options).
2. One of the defining characteristics of open source software is the fact that it’s meant to be redistributed. Package management makes it easy to redistribute software, and provides real value for both the users of the operating system and for the upstream developers. Or so I’m lead to believe.

In the end, we’re back at the beginning where, you can install just about anything in the world if you know what the package is named, and the operating system will blithely keep everything up to date and maintained.²

While GNU/Linux systems get flack for not being as useable as proprietary operating systems, I see package management as this huge “killer feature” that open source systems have on top of proprietary system. We’ll never see something like apt-get for Windows not because it’s not good technology, but because it’s impossible to mange every component of the system and all of the software with a single tool.³

And then all these “App Store” things started popping up.

As I’ve thought about it, “App stores,” do the same thing for application delivery on non-GNU/* systems that package management does for open source systems. We’re seeing this sort of thing for various platforms from cell phones like the iPhone/Blackberry/Andriod to Inuit’s QuickBooks and even for more conventional platforms like Java.

Technically it’s a bit less interesting. App stores generally just receive and distribute compiled code,⁴ but from a social and user-centric perspective, the app store experience is really quite similar to the package management experience.

I’m surely not the only one to make this connection, but I’d be interesting to move past this and think about the kinds of technological progress that stem from this. App stores clearly provide value to users by making applications easier to find, and to developers who can spend less time distributing their software. Are there greater advancements to be made here? Is this always going to be platform specific, or might there be some other sort of curatorial mechanism that might add even more value in this space? And of course, how does Free Software persist and survive in this kind of environment?

I look forward to hearing from you.

I wrote a post for the Cyborg Institute several weeks ago about the idea of “Reusable Software”, and I’ve thought for a while that it deserved a bit more attention. The first time around, I concentrated a lot about the idea of reusable software in the context of the kinds of computing that people like you and me do on a day to day basis. I was trying to think about the way we interact with computers and how this has changed in the last 30 years (or so) and how we might expect for this to change soon.

Well that was the attempt at any rate. I’m not sure how close I got to that.

More recently, I’ve been thinking about the plight of reusable software in the context of “bigger scale” information technology. I’d say this fits into my larger series of technology futurism posts, except that this is very much a work of presentism. So be it.

To back up for a moment I think we can summarize the argument against reusable software, which boils down to a couple of points:

1. With widely reusable software, most of the people who use computers on a regular basis can pretty much avoid ever having to write software. While it’s probably true most people end up doing a very small amount of programming without realizing it, gone are the days when using a computer meant that you had to know how to program it. While more people can slip into using computers than ever before, the argument is that people aren’t as good at using computers because they don’t know how they work as well.

Arguably this trend is one of the harbingers of the singularity, but that’s an aside.

2. Widely reusable software is often less good software than the single-use, or single-purpose stuff. When software doesn’t need to be reused, it only needs to do the exact things you need it to do well and can be optimized, tuned, and designed to fit into a single person’s or organization’s work-flow. When developers know that they’re developing a reusable application, they have to take into account possible variances in the environments where it will be deployed, a host of possible supported and unsupported uses. They have to design a feature set for a normalized population, and the end result is simply lower quality software.

So with the above rattling around in my head, I’ve been asking:

• Are web applications, which are deployed centrally and often only on one machine (or a small cluster of machines), the beginning of a return to single use applications? Particularly since the specific economic goals of the sponsoring organization/company is often quite tightly coupled with the code itself?
• One of the leading reasons that people give for avoiding open source release is embarrassment at the code base. While many would argue that this is avoidance of one sort or another, and it might be, I think it’s probably also true more often than not. I’m interested in thinking about what the impact of the open source movement’s focus on source code has had on the development of single use code versus multi use code in the larger scope.
• What do we see people doing with web application frameworks in terms of code reuse? For starters, the frameworks themselves are all about code reuse and bout providing some basic tools to prevent developers from recreating the wheel over and over again. But then, the applications are (within some basic limitations) wildly different from each other and highly un-reusable.

Having said that, Rails/Django/Drupal sites suffer from poor performance in particularly high-volume situations for two reasons: Firstly, it’s possible to strangle yourself in database queries in the attempt to do something that you’d never do if you had to write the queries yourself. Secondly the frameworks are optimized to save developers time, rather than run blindingly fast on very little memory.

I suppose if I had the answers I wouldn’t be writing this here blog, but I think the questions are more interesting anyways, and besides, I bet you all know what I think about this stuff. Do be in touch with your questions and answers.

Onwards and Upwards!