The Atomization of Software

pluginReader Bill Burcham talks about one Open Source phenomenon that had not occurred to me: Just as business is likely to atomize into a World of Ends— 

many small specialized, networked businesses each doing one or two things really well, self-organized collaboratively with their customers to produce integrated, customized, even Peer-Produced goods and services perfectly attuned to each customer’s need–

it is very conceivable that software offerings could atomize into a World of ‘Microapplication’ Ends —

many small networked software developers, each designing small pieces of code that add useful functionality that can be plugged into existing Open Source applications.

There is no reason why these microapplications couldn’t also be Peer-Produced — co-designed by the customers who need them.

So, for example, it would be nice to have a microapplication that would add wiki functionality, or maybe podcasting functionality, to blogs. The wiki ‘plug-in’ to a blog would produce what is called a bliki. It would allow any reader of the blog to add his two cents to an article right in the body of the post (instead of in the comments thread below it) — to become in effect a co-author of the article. The miniapplication would have to allow the original author some simple control e.g. the ability to tag readers’ additions and changes and ‘inline’ comments in another colour, or to display them only as pop-ups or scroll-overs, or to remove them if she thinks they detract rather than add to the article.

This opportunity to create atomized software only arises as a result of (a) open access to the code of existing applications so that designers can add in or plug in in a simple, modular way, and (b) emerging standards and protocols like Ajax that make modular design simple, so add-on/plug-in miniapplications need not be tweaked for each similar application they are adapted to. For example, a wiki miniapplication for one blog tool would ideally work for all blog tools without the need for additional coding.

This would require that the basic functionality of core applications (like blogs) evolve quickly to a single, simple set of standards with a stripped-down or modularized set of functionalities. This probably won’t appeal to designers who like to design an elegant and complete product, and it will essentially destroy ‘brand’, but it offers the promise of immensely more value and flexibility to customers.

Rather than imposing such standards using some ISO-type oversight organization, I’d like to believe these standards could evolve naturally using methods to capture the Wisdom of Crowds. Customers would first have to realize they have the power to demand such standards. They, we, need not settle for sloppily designed, bloated, buggy, over-engineered, proprietary, memory- and processor-hogging applications.

If we could achieve such standards, incorporating modularity, flexibility, openness and organic design in the software domain, this might serve as a model for the future design of physical objects, like cars and houses. Instead of cars being designed to discourage ‘non-factory’ improvements, wouldn’t it be great if we could design (intentionally create) our own car, by simply selecting a chassis and engine from a standard set, and then adding whatever additional functionality we need, from a million choices offered by a million lean, adaptable entrepreneurial companies? And then when our needs changed, wouldn’t it be great if we could simply ‘pop out’ and resell the modules we no longer require, and add new ones that meet our new needs?

It’s all possible.We just need to flex our ingenuity and our consumer and voter muscle to make it happen. The Internet, a freed market and the imaginative possibility of Open Space Business will look after the rest.

This entry was posted in Working Smarter. Bookmark the permalink.

8 Responses to The Atomization of Software

  1. Hmm… Tell me how a bliki would increase the value of a blog as opposed to creating a war of words within the blog postings themselves. I foresse a bilikified future in which liberals and conservatives spend hours every day rewriting, erasing, “correcting” and mudslinging throughout each other’s articles. Wikipedia, as novel an idea as it is, already strikes me as a bunch of amateur historians writing what they think they know about a given subject, and the rest of the world taking it as gospel… which, in a way, is not unlike the operation of the major media in the US, no?

  2. Gideon says:

    I’m beginning to become very disappointed in fora and wikis.There seems to be a tipping point where everything brakes down at the social level. Suddenly people get “ignored” (a filter option of the fora software), or edits are constantly reversed (without explanation) because the text was viewed by many to be ideological incorrect: the disenting voice is made quiet and even the fact that there may be a disent voice will most often not be acceptable.Where before that moment one has real intelligent and lively discussions and worked hard towards common understanding, after that moment the fora or wiki disintegrates. Crowds maybe wise, but it’s the individuals whom are intelligent. They need to think for themselves. I’ve seen it every time again: The moment the crowd becomes a group the discussions die, the intelligence goes away and what is left is only the most basic of shared emotions: gossip, porn and flames.The only solution I can see is to assume that something is wrong with fora and wiki software, and all kinds of “groupware” in general. Maybe personal websites (like blogs) could be made to work like some kind of crowd-ware? I’m working on that problem right now and hope to have a working product by june 2006.

  3. Martin-Eric says:

    I agree that an atomic solution created via a P2P bottoms-up approach works best, especially compared to commitee-designed piecemeal solutions that end up pleasing nobody in particular. This being said, a minimum of interoperability is needeed and it cannot be achieved without some sort of a council that regroups a wider scope of interests than the local peer network could ever provide. I think of standards like Unicode. Without the non-USian world’s sytematic and organized insistance that we need to be interoperatable accross the whole planet and to become character-set agnostic, we would still be stuck with ASCII and all the old ISO-8859 character-sets.

  4. Dave Pollard says:

    Justin: I’m not saying that wiki functionality on every blog, or every blog post, is desirable. And it is quite possible that (especially political) blog owners might require people to be authorized before they can edit the owner’s posts. The wikis I’m involved with work just fine without restrictions, probably because they are non-political.Gideon: The problem, perhaps, is one of anonymity and unscalability — in essence, the online version of Tragedy of the Commons. The solution, then, would be the same as the solution to TotC: the wiki/forum ‘community’ would have to be a small unanimously self-selected group that would manage both membership and the product they produce (including editing non-members’ contributions). If you don’t like what the members are doing with your contributions, you have the alternative of either applying for membership or going elsewhere.Martin-Éric: I defer to your assessment in highly technical areas like Unicode. But global standards for measurement have evolved even though the standard-setting groups have no political authority. I would like to believe the standards could be arrived at by having standard-setting groups suggest them, rather than impose them. But then I’d like to believe a lot of things that won’t happen ;-)

  5. Randall says:

    Dave, I think your idea is a great one. I’d encourage all of your readers to make it a personal goal to drop all software that is not open source. It’s the first logical step in creating the ecosystem that you’ve outlined.

  6. Lawrence says:

    1. “Small pieces, loosely joined” has been part of the design philosophy of Unix/Linux from the beginning. That’s why every *nix system comes with dozens of little tools & scripting languages for manipulating text & files. Each does a specialized task, but by chaining them together, the knowledgeable user can automate pretty complex operations. The “standards” in this case are simply agreements as to how text is formatted, how files are stored, and so on.You don’t need open access to a tool’s code; you just need to know what output it’s going to give you. In fact, usually you don’t give a damn about the tool’s source code, because understanding that uses your precious mental energy; you just want the tool to work.The tradeoff is hidden in the word “knowledgeable” above: the more modular your tools are, the more skill required to connect them. 2. Gideon’s point is crucial. More technology is not going to solve the problem. Making it easier and faster to respond to & edit other people’s words is not necessarily going to make the quality of the dialogue better. Quality dialogue emerges from sincere and thoughtful engagement with the topics at hand and with the other individuals in the conversation. Some tools promote that; some don’t. And as you point out, Dave, picking the right people is really the most important step. (Somewhat related: Situated Software)

  7. Dale Asberry says:

    Looks like the trackback didn’t pick up my blog entry…Software as Serviceshttp://www.artima.com/weblogs/viewpost.jsp?thread=135616

  8. For a technical approach to the extreme atomization of software, see my article “Disorganized Incremental Software Development” at http://www.1729.com/blog/DisorganizedIncrementalSoftwareDevelopment.html.

Comments are closed.