Atom Feed

Associated Blogs
 
Edge City
 
Numbering Peano
 
Orcmid's Lair
 
Praxis101
 
Spanner Wingnut's Muddleware Lab

Recent Items
 
Federated Logic: The FLoC Community
 
Design as Choice: Eugene Wallingford
 
Pimping up Scampo: From Media Center to Media Producer
 
Identity - Not Just the Law Any More
 
Mark Guzdial and the Computer Science Education Travail
 
Does Visual Studio Rot the Mind?
 
Grady Booch on the Limits of Software
 
Modeling the Office Open XML Packaging Conventions
 
Appreciating ALGOL 60: Launching Computer Science
 
Orcmid's Lair: Global Social Identity

Archives
2004-06-13
2004-06-20
2004-06-27
2004-08-29
2004-09-05
2004-09-12
2004-09-19
2004-10-10
2004-10-24
2004-11-07
2004-11-28
2004-12-05
2004-12-12
2004-12-26
2005-01-30
2005-02-06
2005-03-06
2005-03-13
2005-03-20
2005-04-03
2005-04-10
2005-04-17
2005-04-24
2005-05-01
2005-05-08
2005-05-15
2005-05-29
2005-06-05
2005-06-12
2005-06-19
2005-06-26
2005-07-10
2005-07-17
2005-07-31
2005-08-28
2005-10-09
2005-10-16
2005-10-23
2005-11-13
2005-11-27
2005-12-04
2005-12-18
2006-01-08
2006-02-05
2006-02-12
2006-02-19
2006-03-05
2006-03-12
2006-03-26
2006-04-23
2006-04-30
2006-07-16
2006-07-30
2006-08-06
2006-09-03

Ted Dziuba: The Core Incompetencies of Open-Source Production

[update 2006–09–04–11:34 It has taken me two updates to spell Dziuba correctly, this last time in the tags.  For other amusement with regard to blog incoherence, this post figures in the account here.] 

Epsilon-Delta » MythTV: A Comedy of Errors.  I favor open-source licensing for community-developed and community-shared software.  I prefer open-source development for cultivation of novices and beginners, for sharpening the prowess of enthusiasts, and for long-tail undertakings that cannot survive business-plan scrutiny for return after the high costs of shrink-wrap industrial-grade software production.  But the failure of the open-source community (and no small number of commercial-software aspirants) to attend to the customer delivery process (or even recognize that there are customers to attend to) has always bemused me. 

{tags: Ted Dziuba orcmid open-source development software engineering software lifecycle core incompetencies}

Ted Dziuba had an iconoclastic moment that exposed ground truth underneath the accepted scripture that open-source is the natural law to goodness for personal computing and computer-based appliances: 

The last time I build a linux rig from scratch was 9 years ago. Things have certainly improved since then, but the core incompetencies of the open source movement still remain. Why doesn’t stuff just work? Yes, I know what you’re going to say: I should fix the problems, submit my patch, and make the world a better place. Well, I just wanted to build a personal video recording machine, not get deeply involved in a quagmire of open source projects, submitting patches to maintainers who turn them down because their egos take up half the space in the room. Plus, I don’t have the time to dive into some pre-established project. I’m building this machine explicitly to make my wasting of time more efficient and enjoyable.
In the end, I’m going to use a serious solution: XP Media Center Edition. Sure, MythTV is cute, but it’s not ready for prime time. I would also be willing to bet that had I gotten it installed and working, it wouldn’t be “wife friendly”, but that’s just idle speculation.

I guess for me it’s worth the $100 to get a piece of software that I know will recognize with my $2,000 worth of machinery, will have updates that won’t break the installation, and will actually do what I need it to do.

Ted’s commenters predictably turn to geek problem-solving, offering alternatives and speculating ways that might have worked better than Ted’s excruciating experience.  Sixth commenter “oneofmany” points to the key disparity and the simple reason that non-developers will prefer packaged commercial systems running Apple OS X or Microsoft Windows with this quotation: “ 'Don’t buy a puzzle when it’s just a picture that you want.' ”

One of the blind spots of developers is their failing to recognize and respect the world of the adopter.  In particular, there is blindness to how commercial solutions can be economically-optimal choice and not against the best interests of the adopter at all.  The adopter’s value trade-off does not have to be the same as the open-source adherent’s, and there’s not a thing wrong with that.  Our developer-centric, self-satisfying inpersonation of our customers as like ourselves, with our values, is an incompetent approach.

It is also a great lesson of my own experience, that (self-indulgent?) ignorance of adopter realities is a widespread failing of developers.  Yet in open-source development and its support in academic circles, this vice is dressed-up as virtuous.  That will be disheartening to those who actually want to see their work taken up and valued by users, users who don’t have to have been able to write and trouble-shoot it themselves in order to enjoy its operation and utility. 

Just yesterday I saw how the same problems can arise when professional developers (perhaps relatively junior ones) step out of the confines of their industrial-strength development-and-delivery enterprise and start lofting open-source contributions into the cyberverse.  I take this anecdotal indicator as evidence that software quality, especially suitability for purpose, is an institutionally- (that is, socially-) maintained competency.  

The achievement of dependable software quality is spotty everywhere, and it is clear that it invariably takes the restraints of institutionalized behavior to pull it off at any scale and level of consistency. 

It comes down to this: the obsessive attention to detail, thoroughness, and honoring of the adopter’s world is against our nature.  We do not take this on naturally nor willingly.   We are not automatically equipped for it and it doesn’t scale (the same way warriors don’t scale without a military) unless there’s an institutional structure to keep restoring the commitment and having us succeed despite our contrary tendencies.

We also pursue tools, nostrums, and other magical elixirs to save us from the tedium and the frustrated demands of adopters.  I accept that we do need the aid of all computational tools we can find for dealing with the parts of our work that are computational and formal in nature (and that fit into an institutionally-sustainable paradigm, not our self-absorbed predilections).  

In the end, that won’t be enough, because the world of the adopter is not what our computational formulations address.  How we bridge that gap and become responsible for our products as instruments (not ends) in the world of opportunity that adopters live in remains to be dealt with.  I predict that it will demand teamwork and institutional structures of some form having a trustworthy relationship with adopters at the heart of it.