Freebies From Platform Makers Are Destroying Markets

As platform makers like Apple, Google, and Microsoft expand their offerings to include more and more features they often destroy the markets of their developer partners. These companies are natural monopolies as the sole maintainer of their respective platforms; even the relatively open platform of Android is migrating to increasingly proprietary apps and services that Google alone controls. Yet because of their ability to influence through defaults and brand they’re also in a position to swallow whole markets.

Apple’s Ping, Google Wave, and Microsoft’s Windows Phone all show that such expansion efforts are not always a runaway success. Unfortunately there are also examples of platform producers acquiring and pricing others out of markets:
* Apple Siri and Google Now compete with 3rd party voice recognizing assistants like Vlingo
* Google’s purchase of DoubleClick has accelerated the race to the bottom of advertising pricing
* Microsoft Internet Explorer destroyed Netscape’s browser market
* Microsoft Office 365’s bundling unlimited storage for less than $10 per month may prove decimating to competitors like Dropbox

Recent anti-competitive measures are not limited to bundling and acquiring. The move to official application stores has also further tightened the grip of platform developers on users who once depended upon 3rd party providers. Apple prohibits 3rd party stores on it’s devices. Google has also tightened certification requirements to get their increasingly core applications onto hardware. This leaves users with fewer practical choices and developers at the mercy of a relatively small number of platform makers.

Freebies from companies of all sizes seems to be an increasingly significant portion of the software and services used by everyday consumers. Imagine if the same were true of cafeterias in malls, with the largest portion of consumers taking samples from many different food vendors. And not only once but on an ongoing basis. Such a market would be untenable. This is all the more acute when a monopoly does so because they have the most immediate access to users of their platform, and often they can offset loses elsewhere.

Companies should not be forever pigeon-holed into their original business market, that would stifle innovation. However, once a company gains a significant or controlling share of a market I do think it is better for everyone if there were some reasonable limits to their expansion. Perhaps if expanding their platform were justified, for example for accessibility, then the default would have to show alternatives and the internal Application Programming Interfaces (APIs) be exposed for others to utilize.

Requiring customers to buy only on faith is another unrealistic solution. Allowing free products and services has it’s place, but I believe that much like the shareware market of the 1990’s the current freeware and services cannot last. Bitcasa’s recent pricing increase is a sign of things to come as smaller companies are unable to compete.

Issue Tracking Needs Are Specialized

Different companies have different kinds of issues and ways of managing them, so I probably shouldn’t be surprised there are many software and service solutions available. And as an engineer it’s tempting to fall into one of two extremes: build it from scratch or buy something and deal with it.

Do-it-yourself was my preferred approach as a young and ambitious programmer. After all, what could be better than a custom-built solution? However, within five years of making and maintaining such solutions I found myself in the get-it-and-forget-it camp. Another five years later I think I’ve settled somewhere in the middle.

My first experience with issue-management systems was on-line support forums. These were simple message boards requiring a lot of moderation. Shortly thereafter I was exposed to a somewhat custom, Lotus-based solution. This time though, as a support technician handling the problems. Since the solution required Lotus, and only worked within the network, it seemed ripe for replacement with a web-based frontend. Studying web programming made me eager to try my hand at making something better.

Building custom intranet solutions came next with employment at a company branching out into other industries. It was interesting to see how the various needs could be met with custom software. At first simple comment systems were enough for employees to keep track of their customer complaints, notes, and follow-ups. Of course e-mail and IM were also being used heavily to supplement.

In time, however, maintaining so many different systems became burdensome for only two or three developers. Increasingly I also saw patterns in the various needs that also fit some existing solutions.

One of the first to be used in house was Trac, and it worked well for our needs initially. Integration with software repositories was nice. Some add-on’s for things like discussion boards worked well enough. The wiki, its integration, and its export options were my favorite features. At one point I even used the mantra “If it’s not in Trac it doesn’t exist” in a push to unify the disparate repositories of knowledge.

Over time though it’s simplistic reports and lack of built-in, multi-project support were too problematic. Other solutions were tried with varying levels of success and failure. One of the most lasting was Altassian JIRA and it’s wiki offering. Customization options did not appear obvious or immediately better to me at the time. Though, some in management were more familiar and appreciated it’s built-in flexibility.

Experiments along the way pushed the boundaries of such trackers; pressing them into service as the official source of truth, customer complaint tickets, feature tracking, road-mapping, to-do/task management, time tracking, and discussion. Ultimately I’ve come to realize that specialization is needed; even if it takes the form of creative use of, extension software for, or rethinking about existing solutions. And at times it is better to have many, separate solutions than keeping it all in one.