Update 4/24/07: Om Malik asked me to write a trimmed down version of this article for his Found|Read site. It was a great honor to be asked by Om to contribute, and hopefully this will get it a little more exposure among web-types who might be able to help make it a reality!
Original Article below:
I’m tired of suffering under the weight of all of my brilliant ideas. Just joking. Mostly.
I’m sure that most of the ideas I have aren’t particularly unique, but once I have the idea, I find it difficult to resist the temptation to implement it. I am hoping that by sharing ideas with the public, I’ll get them out of my mind and spark the ambition of some other developer/facilitator.
Today’s idea is pretty simple. As small Mac businesses who earn most of our revenues through the web. What do we need in order to achieve these revenues? Only three basics spring to mind:
- Development labor in coding and testing, to produce a compelling product.
- Customer support labor, increasing the odds of an ideal user experience.
- Marketing investment and labor, increasing the total number of ideal user experiences.
Some developers mistakenly assume they have accomplished the first two, and move quickly into marketing their fundamentally flawed and poorly supported products. This is a good way to burn through what little revenue is coming in. Worse, it can be difficult to judge for ourselves whether our products are “ready to pop.”
I think the situation would be helped if there was more fluidity between the lowest level of financial commitment (blogging, participation in internet fora, etc), and the pricier options. When is it worth the investment risk of a print ad in Macworld, for instance?
It’s often pointed out that the Mac developer community is just that, a community. We take it for granted, but it seems unusual that a large collection of people should be so simultaneously devoted both to money-making and to helping each other out. Frankly, it’s one of the things that prevents development on the Mac from becoming a grind: the fact that even your biggest competitor will probably sit down with you for a friendly chat. Heck, they’ll probably even buy your lunch!
As a community, we share lots of things ranging from advice, to icon designers, to source code. But we don’t share advertising. Why is that?
The one thing every Mac developer has in common, regardless of our particular emphasis, is some number of loyal Mac-loving customers who visit our web sites regularly. Yet when visitors come to our sites, unless we’ve specifically called out a colleague’s product, they only see our products. This is good, but chances are they already know about our products.
Enough! What’s the idea?
OK, I know I’m rambling! Enough preface, here’s the idea: a network of Mac-businesses trading a tiny patch of our web page in exchange for the cooperative advertising of our colleagues.
Think The Deck, without the money. I’m envisioning a scenario where a central server dispatches ads to participants. For every ad a viewer sees on your site, one of your ads gets displayed to a viewer of another participant’s site. The degree to which your ads get shown is directly proportional to the number of viewers you bring “to the collective.” So slightly bigger companies get lots of exposure across the network, while even the tiniest of companies at least gets occasional exposure on a big site.
To head off some obvious criticisms, I would propose a few required features for 1.0 of this service:
- Participants must be vetted by some high-level filter. This could be as simple as one person giving the go-ahead for new participants, or as complex as the existing cooperative approving by majority any new participant. The idea here would be to prevent utterly inappropriate members.
- Participants would have “line-item veto” on any participant’s ad appearing on their site. Inevitably there will be some marketing that you simply don’t want to have showing up on your site. For instance, BBEdit probably doesn’t want to promote TextMate, Sandvox doesn’t want to promote RapidWeaver, etc.
- Perhaps participants could also take the “opt-in” approach. Imagine a menu of cooperative members, from which a member could check on or off the inclusion of ads for their “feed.” The resulting URL would encode the ids of the specific companies whose products should be included.
Another problem to tackle would be questions of ad format. I’m expecting there would be a single specific size and content. Perhaps as a condition of admission to the collective, the joining member would have to propose a mock-up of exactly how they would display the ads on their site.
Take a look at my blog and you’ll see a few “Try My Products” items at the right side of the page. I would be happy to list a rotating product from a reputable company that I trust, in exchange for the privilege of being exposed to their customers. Rogue Amoeba, Flying Meat, Outer Level, Bare Bones, Karelia, Martian Technology, Sci-Fi Hi-Fi, Atomic Bird, Clickable Bliss, Panic, and many, many others would easily get my approval. For those I wasn’t familiar with, I could go download and try for myself before I decided to “endorse” them or not. Think of all the customers everybody else has, that you don’t.
OK! The idea out of my head. Now somebody go do all the hard work and I’ll join.
Update: In case some web-savvy person does pick up the ball here and start developing something, I’d like to suggest some development guidelines that would make this project maximally beneficial:
- The project should be deployment-independent. That is, the project source code should be useful for us in the Mac community, but another group should be able to install the same software and host a “Rails-Centric Ads” network, or whatever.
- To that end, maximum compatibility with server software should be a design consideration. So I don’t think this should be in Rails or Django. It should be done in something commonly available on all hosts. My naive perception is this means it should be straight Perl, PHP or (non-Rails) Ruby. Something I can drop in and easily configure for my “collective” to then create an account and request membership.
Update 2: Answers to some common questions:
Some people have been inquiring as to “what if” certain scenarios are met, how should they be overcome? My answer in general is “forget about it until after 1.0”, but to quell some certain concerns, here are some further refinements to the idea.
Q: What happens at the beginning when nobody has any credit to have their ads shown?
A: The situation is general, not just applicable to the beginning. The system needs to have a “tank is empty” behavior that helps to jumpstart the quid-pro-quo ad trading. I propose that the default behavior for an empty tank should be to just pick a random ad and show it, debiting the ad “vendor” as usual. So at the beginning if companies A, B, and C are all at 0 credit, company A will show a random ad C. Now A has 1 credit, B has 0, and C has -1. This should be a good enough policy to get things rolling.
Q: But what if one company is just spanking everybody in terms of ad shows, and the others can’t keep up in credits?
A: The cited scenario is that some company shows so many ads that the rest of the companies combined cannot possibly earn enough credits to allow their ads to be shown. This might be an artificial imbalance. The odds of one company outnumbering all the others combined is probably easily solved by simply adjusting your collective membership. But to address this issue in the system might be a good idea. I think it could wait for post-1.0, but the idea would be that after some threshold of disparity (the big site is basically showing ads and causing all other publishers to get negative credits), the big site’s ads should be switched off, so that it’s no long earning credits, and no longer deducting credits from the smaller guys. In this state I would suggest that the big site be served its own self-promotional ad, or optionally a “public service” ad from a set agreed upon by the collective. (Could promote open source Mac products, etc).
These questions were motivated by discussions in IRC by Jan Lehnardt, who has commented below that he is willing to implement the 1.0 version of the system, provided he gets enough donations ($500) to buy himself an ADC Select membership. I am impartial to who implements it. I only hope that somebody implements it as an open source project that I can deploy on my own if I choose. It would also be nice if they include me as an idea-motivating credit.
