Imbalance Of Power

What are the technical and social forces in the commercial software world that lead to an Imbalance of Power?

Heres my stab at some forces:

UserSuggestion? (Software that guides, suggests, forces or just downright deceives its users into taking some decision.) "Click here" to opt-in, but "click here 2,000 times" to opt out. (See http://www.around.com/agree.html for example.)
Binary incompatibility (Vendor lock-in: Barrier to competition, since switching products becomes very expensive if at all possible.) - "AllRoadsLeadToRome".
The upgrade treadmill. (Psychological pressure to upgrade whether users need it or not.)
Careful restriction of the public interfaces into BlackBoxComponent? products. (Doing this enables the perpetrator to control the 3rd party-add on markets.
Control of 3rd party business services can lead to a "certification" sideline, which has the nice side effect of turning developers into unpaid salespeople. Since they've paid $x (for large values of x) to learn this, they can't afford to consider alternatives.
Non-accidental "bugs". ("X ain't done until Y won't run.")
Bundling (Think of my first point as a means for implementing this...)
The effect of NetworkExternalities in creating de-facto, proprietary standards as the TragedyOfTheCommons forces open standards and media to be dominated by proprietary concerns.
TheSecretOfPower. Most people want comfort, not freedom. (See point one for an implementation technique.)

I'm sure lots of people would like to ride on these effects. Naturally, I'm not naming names... due to the imbalance of lawyers*;-)

Have I missed any forces? -- some guy

That's most helpful, some guy. What I've been mulling over a lot is how much all the above forces are then compounded by the absolutely lousy quality of most commercial software - when you really are called in to deal with the code. Any approach that begins to deal with the real issues is a godsend (if you'll forgive the phrase) - even restricted to TeamsOfUpToTwelve.

Which properties in particular did you have in mind when you say "lousy"? Performance? Design? Documentation? Requirements? or do you think it varies too much for classification? None of them. I was trying not to think about any particular. No, all of them. It hurts to think about things one has seen, tried to refactor/produce value with in small steps under great pressure and then be blamed for. Varies too much for classification. Those are my initial thoughts. That's what it does to you. Will still refactor, will still refactor. What was that about once and only once?

Some guy did a great job in interpreting this phrase after a long piece of mine many months ago, with the addition of NetworkExternalities this weekend strengthening the particular (and useful) direction that he's taken.

My original point I now think would probably have been better expressed as the ImbalanceOfEconomicIncentive?. That is: given the background of the ImbalanceOfPower is there ever going to be sufficient economic incentive to do software right? I ask this not to be defeatist but because I sense that there is a major opportunity presented right now to reform the economics and ethics of our business.

--RichardDrake

If you're dealing with standards such as file formats and protocols, you can choose how tolerant you are of the other party, and how strict you are with respect to the standard. You could try to repair broken input, and output only pristine stuff. On the other hand, you might want to embrace and extend... If you get a big enough market share, maybe you can use this to turn an official standard into a de-facto one. On the other hand, if you handle input in sub-format Y.X, you could say you support the Y standard. Just think how bad it'll look on your competitors when you reject input in sub-format Y.Z (which they use.) Perhaps I'm being cynical, or perhaps "compatibility engineering" really does get taken into consideration.

see IsThereEverGoingToBeSufficientEconomicIncentiveToDoSoftwareRight

I wonder what company would be blamed for the mistake. The one which produces Y.Z or the one which rejects Y.Z? Usually big companies advertise themselves as Y compatible, but only when you read the small letters they say they won't be 100% compatible any time soon.

It is interesting to realize why such a company would have success. In the case of a CIO who decides to align all the software of the company to the big company offerings, he does it because of the prestige that such action will bring on him. If the decision proves wrong, he will say he was deceived by the big company which has deceived a lot of people, so he is not the one to blame. If he instead decided in favor of a small company, if there is a perceived problem with that software, he would take responsibility. In that case he would delegate the decision to a technical manager who would have to make that decision and take the blame in case of a perceived failure.

The big company's ability to capture new audience must be faster than its ability to deceive customers. Probably that is why big companies prohibit customers to publish their findings about the licensed software.

I wonder if the combination of ProfessionalPerfectionism and FearUncertaintyAndDoubt results in an ImbalanceOfPower.

Have I missed any forces?

Consolidation (via buyouts, mergers, etc.) of mature/maturing markets
Increased barriers to entry in areas in which the established powers have had many years of development
Software maturity in general - how many competing word processing programs do we need now that they all have more features than any one person can use in a lifetime?
Discontinuous innovation, the rare case when one company/product really does make the way things were done last year obsolete
Hype, buzz, and marketing success