The excellent Coding Horror blog has a short article up about one way of categorizing software: UsWare vs. ThemWare. The idea is simple enough. ThemWare is software that's only used by "Them" - ie, none of the users are also developers of it. UsWare is software that is used by the developers as well as others.
Jeff comes to the conclusion - which I happen to agree with 100% - that creating software as UsWare will, all other things being equal, lead to vastly higher quality than software created as ThemWare. To help this process along, he encourages his software developer readers to work to gain the user perspective, to eat their own dogfood. This is certainly a good idea.
But as I thought about it a bit, I realized that this is only half the picture. The focus here is to give the programmers more of a user perspective so they meet user needs better. But what if things could go the other way? What if users could get more of a programmer perspective, so they actually could communicate their needs effectively? And maybe, in the case of users who have some programming experience, be allowed to help out and contribute bits of code that demonstrate what they want with far more precision than any prose description. Either way, the end result is to break down barriers, and blur the line between developer and user.
Oh, wait. There's a name for that already - open source.
That phenomenon called open source software hasn't really caught on too strongly in the Windows world, in no small part because Microsoft does everything in its power to keep all of its source code under heavy lock and key. With how much Microsoft depends on license keys to enforce paying for software, there really isn't much of an alternative for them. Even more important, I believe, is the fact that Microsoft began from square zero by selling software to non-programmers. The people using those original DOS systems didn't want computers for their own sake, they just wanted them to run their business.
In the Unix world, however, things began completely different. While Microsoft was busy trying to sell computers to people who didn't want to know anything more about them than they had to, Unix was a programmers playground. Researchers used Unix, and often had to create their own applications, and were able to with compilers being commonplace on Unix systems. Unix was an environment created by programmers for programmers, and the result is that once you begin to feel a little comfortable as a Unix user, the bar to becoming a Unix programmer is fairly low.
As the Free Software and OSS movements had propelled Linux systems as the successor to the Unix heritage, this trend has only become more pronounced. These days, a typical Linux system will have two or three programmer-friendly editors, an IDE, compilers for C, C++, and possibly Fortran, lisp (if you count Emacs), java (Sun, or an open source alternative), and a handful of powerful scripting languages such as Perl, Python, and Ruby.
And that's just the typical stuff! For the Linux user truly interested in becoming a programmer, there are debuggers, Ada, Smalltalk, Rexx, Haskell, and countless other languages and development aids just a Freshmeat search away. With all those tools just waiting to be picked up, each and every open source user is a potential contributor, of anything from a bug fix, to feature enhancement, to documentation, all the way up to becoming a full fledged maintainer.
Jeff is absolutely right that programmers who learn what it's like to be users will end up producing higher quality software. But as long as you freeze out your users from becoming contributors, you're throwing away valuable resources that you often couldn't buy if you wanted to. And that's why Linux will always have an edge over Windows, no matter how many animations they add to Aero.
No comments:
Post a Comment