Hooray for me!!

The new company is called Wry Research, and at least at first, I’m mostly just doing AI research consulting for a couple of clients. I’m trying to also fit in some original product development, when I have spare time. But I don’t have a whole hell of a lot of spare time, so I’m mostly just consulting right now.

But life is very good, and I’m enjoying the freedom and flexibility of being a solo software developer.

In the near future, I’ll talk about some of the work I’m doing as a consultant. I’ll also talk a little bit about a really cool research project that I’m doing, in conjunction with the Columbia Medical School Neurovascular Research Lab. Depending on the success of the research, it could lead me to developing a very cool product/service for the medical research community.

I’ll keep ya posted :)

Over the summer (and immediately following my failed interview at Google) I announced a project to brainstorm 30 business ideas in 30 days. Although the project slipped a little bit (I ended up developing 28 ideas in 43 days), I came up with a broad range of possible software projects.

Over the next month or so, I arrived at a decision: the AI-Coder project rose to the top of my list, and I started working on an implementation. But within a few weeks, I ran into a number of difficulties (both technical and legal) and I decided to reconsider.

So, I returned to my list of semifinalist projects and began to weigh the options.

And now I’ve chosen a new project.

Here’s a quick rundown of the my thought process as I revisited those four ideas:

WebDelve

I still think this would be a very cool project, and I’m still enamoured with the idea of using a Windows GUI application (rather than a webapp) as a platform for a rich web-analytics experience. I also really like the idea of presenting the kinds of charts typically only seen in financial applications as an advanced mechanism for exploring the different characteristics of web-surfing behavior.

When I’m looking at my own web stats, I’d love to be able to view them as a seven-day moving average, or as a pair of crisscrossing momentum lines or as a region between a set of Bollinger Bands. It’d also be nice if i could drill down to see the browsing activities of individual users, rather than always having to work with aggregate stats. I’d like to be able to annotate the charts with my own notes, and I’d like to join my web-analytics queries with queries on my other database tables (products, purchases, users, articles, blog posts, etc).

So I think I could develop a really unique product in this space.

But, like I said before, I don’t relish the idea of competing with the world’s googliest search engine company. Google Analytics is one of the four most important pieces of software produced by Google (in order of importance: Search, AdSense, AdWords, and Analytics). These separate applications work in four-part harmony for Google’s overall revenue strategy, since Analytics is the tool that advertisers use to maximize their revenue. And when the advertisers maximize their revenue, so does Google.

Google isn’t likely to smile at competing products, and I’m not likely to smile if they’re frowning at me.

Plus, integration with AdWords isn’t something I could offer, and the WebDelve product would be significantly less compelling than theirs, for that reason alone.

Beltway Analytics

This project would also be fun, and very personally satisfying. I’d get to participate, indirectly, in American politics (which I enjoy). I’d also get to flex my skills in writing machine learning algorithms and natural language processing systems.

Unfortunately, the whole project would have to be driven by advertising revenue. Which would almost certainly mean Google AdSense. And, call me crazy, but I’m just not comfortable relying on a single source of revenue for an entire business model. (Though I wouldn’t mind supplementing my revenue with ad dollars.)

Besides, there have recently emerged lots of interesting players in this space. Between FindLaw, GovTrack, and Google U.S. Government Search (couldn’t they think of a catchier name?), many of the features I was planning are already being offered. (Though, without quite as much natural language processing as I would have liked. For example, wouldn’t it be interesting to know that a recent piece of legislation contained three different quotes from the Bible, or from a United Nations document?)

Anyhow, although I think it’d be a fun research project, the Beltway Analytics project lacks many of the key criteria for me to consider it a viable business plan right now.

Project Artifact Management

This one is so tempting.

Unlike the software industry–where there’s already a multitude of free software to manage the versioning, transfer, documentation, and release of project resources–most other industries are still grappling with the need for a robust methodology to handle their project artifacts.

In fact, just a few weeks ago, I was talking with my older brother–who has a masters degree in civil engineering and works in the transportation sector–about how his company (and the industry at large) manages its project assets. In most engineering firms, electronic documents are continually passed back and forth between the project personnel and the client. Technical specs, charts, diagrams, schematics, construction and fabrication plans, FMEA analyses, and on and on and on. Document versioning information (when it exists at all) is usually just pasted into the filename.

And, in most cases, these documents travel around in email attachments or burned onto DVDs and sent through the mail. The mail!!

He said that a few artifact-tracking systems have started to appear in the marketplace. But they’re very complex. And very expensive.

The engineering industry is just ripe for the kind of product I’m envisioning. Other industries are in even worse shape. I mentioned the intelligence and law enforcement communities in my original blog post as being particularly hungry for this kind of software. I’ve talked with a few people from the intelligence community about this software, and they’d be espcially interested in a solution that combines artifact tracking and versioning with strongly encrypted access controls to sensitive documents.

Unfortunately, in these industries, I would need a very knowledgeable sales person, with a Rolodex full of industry contacts. And the sales cycles would be long and difficult. This isn’t the kind of software I could sell myself, either by whipping up a brochure-style website or by trying to make sales appointments myself. I don’t know any such person (my brother is an engineer, not a salesman), and I definitely don’t have the cash to hire a sales team.

So, as much as I like this idea, I’m putting it on the shelf for now.

VaporTrade

I actually started developing this software many years ago, back in the late 1990’s when the stock market was experiencing its heyday of growth.

When I looked for new investment opportunities, I browsed through a few hundred charts every day, keeping my eye out for particular price-movement patterns. Maybe I wanted to find a security with high price volatility over the previous weeks whose decreasing price was about to cross the 90-day moving average.

Or whatever.

At first, I trained my eyeballs to look for these kinds of patterns. And I got pretty good at it. I could look at twenty or thirty charts per minute, only pausing to look at the ones that might meet my criteria. But it didn’t take long for me to realize that those patterns could be described logically and that I could use software to search for my criteria in a pool of thousands of securities.

Even more compelling was that I could go back in time, through the previous ten years of market history, to test the validity of my assumptions. It’s nice to have actual numbers to quantify the effectiveness of each type of pattern. And it’s even nicer to have a dispassionate algorithm doing the work, instead of my over-emotional brain.

Of course, since I was just writing the software for myself, I didn’t bother to develop any fancy GUI interface. At that time, the VaporTrade software was just a fast analysis engine, with a small set of command-line tools for querying the engine and an XML syntax for describing patterns.

Obviously, I don’t think I could market a command-line analysis tool for the stock market.

But I think the core idea is still worthwhile, and I think it could be very powerful if I build a slick GUI to accompany those tools.

Plus, this idea is very good from a business perspective, since it will facilitate the capturing of additional revenue streams. Not only will I sell the software, but I’ll also sell a daily data feed of market prices and volumes. And, since the software will be built entirely around a plug-in architecture (even core services like charting will be provided through plug-ins), I’ll have the opportunity to up-sell additional capabilities like paper-trading, money-management, hypothesis testing, and portfolio tracking.

So, there you have it, folks. This is the project I’ll be working on for the next six months. Even though I’ve been at it for a little while, I’m going to cheat slightly by declaring today as the official start date. Six months from today–on April 28, 2007–I’ll release the first public beta of the VaporTrade platform. I hope you’ll stick around and take the software for a spin around the block.

Along the way, I’ll keep you posted about my progress, writing with copious detail about my technical and business decisions. In fact, tomorrow I’ll write about a jaw-droppingly-stupid decision I’ve (proudly) made, to implement one of my core infrastructural components from scratch.

Why the sudden change of heart?

I’ve been doing my homework.

Over the last three weeks, I’ve given a lot of consideration to the four high-level design goals that I outlined a few days ago (fun, security, speed, and legality). I’ve written some sample code, I’ve buried my head in a small stack of technical books, and I’ve read through pages and pages of federal and state laws.

As a result, I’ve identified some major obstacles. On their own, each of the obstacles presents a barrier I could probably overcome. But combined, the accumulated weight of these obstacles is more than I’m willing to tackle for this project.

Needless to say, I’m pretty disappointed.

Anyhow, to give you an idea of the challenges inherent to this project, I’ll walk you through my thought process as I considered the technical and business implications of making the AI-Coder project fun, secure, fast, and legal.

Sounds Like Fun!!!

There are plenty of programmers who write code in their spare time, for fun or self-betterment (as evidenced by more than 120,000 projects and more than 1.3 million registered users at SourceForge), so I’ve never been too concerned when people have asked me how I’d find people willing to write code in their spare time. Hobby programming is already remarkably common. And hobby programming with the potential to win cash prizes is almost a no-brainer.

But the one detail that always nagged at me was this: How many programmers are really passionate about chess strategy?

Sure, coders are more likely to play board games than your average citizen, but focusing on super-geek games like chess, backgammon, go, or othello would be too limiting. To develop a large, broad, and enthusiastic community, I’d need to include a game with more broad-based appeal. Something cool. The kind of game that could even convince non-programmers to start slinging some code.

So I decided to include Texas Hold’Em (or some other poker variant) in the AI-Coder platform. (As a bonus, I’ve already written thousands of lines of poker AI code myself over the last year.)

In my opinion, the availability of cash-money pokerbot tables would be a key ingredient to the long-term success of the AI-Coder project. Although I’d offer cash tournaments for plenty of other turn-based strategy games, I think poker would be the real money-maker.

Dealing from the Bottom of the Deck

Even without offering poker-style games, I’d have to think about cheaters. What are all the possible ways people could exploit the system to gain an unfair advantage?

What if one player could sneak a peek at another player’s cards?

What if a player could modify the state of the table, stacking his own hand with better cards, or sabotaging the hands of his opponents?

What if, in a game with more than two players, two or more players could secretly communicate with one other, conspiring against the solo players at the table? What kind of software architecture can prevent two bots from colluding?

What if, at the moment preceding a catastrophic loss, the losing player can crash the system by blowing the stack, eating through the heap, or overflowing a buffer? How can the software prevent (or at least detect and punish) any bot who sabotages the game to avoid losing?

This is where I thought the .NET platform would provide a straightforward solution. With my experience writing code for a managed environment (the JVM), I assumed that I could get up to speed on .NET security without too much trouble.

My technical experimentation over the last few weeks has proven that assumption wrong.

Microsoft has actually given a lot of thought to the security architecture in the .NET framework with a concept they call AppDomains. All managed code executed by the CLR is first loaded into a privilege-managed AppDomain sandbox. Code executing in one AppDomain is prevented from accessing the objects allocated in another AppDomain unless the objects are deliberately marshalled (using dynamic proxies or serialization) across the sandbox boundaries. In addition, each AppDomain can have its resource-access privileges completely locked down, preventing certain assemblies from accessing the file-system or connecting to a remote host on the network.

By loading each bot into its own AppDomain, I could use those isolation mechanisms to prevent quite a few exploits. A rogue bot would be unable to sabotage the game-state or peek at the hidden cards in his opponents’ hands or collude with another conspiring player.

But, unfortunately, all AppDomains in the parent process still allocate their objects on the same global heap, so it would be impossible to enforce memory restrictions on a player-by-player basis, leaving the door wide open for a player to deliberately over-allocate objects, throwing an OutOfMemoryException and corrupting the state of the current game.

How could I monitor allocations to fairly distribute resources among all the active players?

This is where it gets really tricky.

By implementing the game controller as an unmanaged C++ application, I could create an instance of the CLR as an ICLRRuntimeHost COM object. By instantiating that COM object using a custom implementation of the ICLRPolicyManager interface, I could set my own escalation policy for trapping (and recovering from) OutOfMemoryExceptions, using a custom IHostMemoryManager to keep careful records of allocations, deallocations, and GC compactions. I could catch OutOfMemoryExceptions as they occur, causing the offending player to automatically forfeit his hand.

That’s pretty impressive stuff, but it still wouldn’t really solve the problem. What if, at a ten-player table, Player#1 filled 90% of the available memory with his objects? By the time Player#10 got his turn, he might throw an OutOfMemoryException by allocating only a fraction of the memory unfairly claimed by the first player. Rather than punishing the player who actually uses the last byte of memory, I should punish the player who allocates more than his fair share.

As far as I can tell, the only way to accomplish that granularity of memory management is to run each player’s code in its own separate process, using COM interop for inter-process communication. At that point, the conveniences of the .NET framework fall mostly by the wayside, and I’m left implementing a whole lot of unmanaged C++ code.

I was prepared to write a thin C++ management layer as the controller for this architecture, but this is more than I bargained for. With only a little C++ experience, and no exposure to COM at all, I’m reluctant to pursue this route.

The Need for Speed (or, at least, Non-Slowness)

The idea of having third-party code executing on my server is not appealing, even if that code was confined to execute within a secure sandbox. AI code, often written by novices, would probably chew through a server’s CPU cycles pretty quickly.

I’ve considered building speed-incentives into the game rules. Maybe the winner of a particular game would forfeit a percentage of his winnings if his code was too slow. Maybe the winner of a Hold’Em hand would be determined by some combination of hand strength and execution speed.

But what if a GC collection was triggered in the middle of someone’s algorithm, to clean up for the allocations of the previous player? Without process (and heap) isolation, it would be very hard to come up with a fair mechanism for measuring execution time of any given player’s code.

A few people have suggested to me that I should just host the game server, allowing people to connect their algorithmic code via a SOAP interface, or some other remote API. But then it’s impossible to guarantee the integrity of the game. What if someone’s “AI” code just consists of a GUI where a human can compete against all the other machines (in many cases, humans are much better than machines at playing these games). And what if a few players started teaming with one another, colluding against the other players at the table. The only way to prevent those kinds of exploits is to execute the code in a known secure sandbox.

But what would it cost to fully host an ongoing competition like I’ve envisioned with the AI-Coder project?

In my experience writing poker AI code, a straightforward decision (folding a hand with a deuce and a three, off-suite) can be made in a few milliseconds. But more difficult decisions (like determining whether to fold a straight when an opponent might be bluffing a flush) can take two or three seconds to run through all of the probabilistic calculations, stochastically modelling the opponent’s likely hand, based on his observed play-style. (The exact sequence of checks, calls, and raises tells you a lot about what cards the player is actually holding.)

Realistically, with novices writing code, I’d expect an average ten-seat table to run at real-life poker-table speeds: about one full hand per minute. Maybe two. So a single server would be able to handle between ten and twenty simultaneous users.

In order to be profitable, I’d need to host a large cluster of powerful servers. Although I could start off small with a closed beta, increasing the hardware along with market demand and using an invitation system to control the flow of new members, it would definitely be a challenge to grow a scalable architecture.

I Don’t Want to Go to Prison

And of course, I’ve spent many many hours conducting legal research, trying to identify the potential regulatory hurdles I’d encounter with a business like this.

It’s not pretty.

Most of the laws (at the federal and state level) would consider the AI-Coder business model to be “gambling”, as long as the games involved an “element of chance”. Even if the game outcome is predominantly affected by the skill level of the participants (as would surely be the case with an AI programming contest), the influence of that “element of chance” would make the contest subject to gambling laws.

In Title 18, Chapter 50, Section 1081 of the US Code, a “gambling establishment” is defined as:

The penalty for operating a gambling establishment is detailed in Title 18, Chapter 95, Section 1955, to whit:

Ouch.

And, as if that wasn’t bad enough, I’d like to refer you to Title 18, Chapter 96, Section 1961 and Section 1962:

Racketeering, huh?

And you thought writing AI code was difficult? I bet you’ve never tried writing a thousand lines of code with a pair of brass knuckles on your fingers. Now that’s what I call hard-core programming!! And how would you like to try on a pair of cement shoes, my friend?

Of course, the Feds will be very interested in all the internet traffic going to and from my servers. According to Title 18, Chapter 119, Section 2516:

Of course, all of this relies on the notion that the AI-Coder platform could be classified as “gambling”, a classification that rests largely on the “element of chance” inherent in some of the games.

But what if I could eliminate the element of chance from the games? Obviously, games like chess and backgammon are already purely games of skill. But would it be possible to slightly re-write the rules of Texas Hold’Em to eliminate the element of chance?

I’ve developed an ingenious idea that I call “collaborative shuffling”, wherein one player gets to arrange the deck in whatever order he likes. He can stack the deck to his own advantage. But then he passes the deck to a second player, who re-arranges the cards again. The only restriction is that the second player is unable to see the values of the cards, so he can’t know how the first player arranged them.

The collaborative shuffling process would eliminate randomness from the game, while still providing a mechanism for scattering cards throughout the deck. As a classic example of a Prisoner’s Dilemma, the shuffle would become a key strategic element of the game.

But, even with the “element of chance” gone, would the AI-Coder project be free from legal trouble?

I don’t think so.

Even though it might be possible for a non-random poker variant to pass muster against the federal gambling laws, the state statues are much more varied in their construction.

In Florida, for example, the state Criminal Code (in Title XLVI, Chapter 849, Section 14) specifically prohibits wagering “any money or other thing of value upon the result of any trial or contest of skill, speed or power or endurance of human or beast”, making violations of the prohibition punishable as a second-degree misdemeanor.

Arizona doesn’t create a special prohibition against games of skill, but (in Title 13, Section 3305) it places a blanket prohibition on any wagers concerning “the results of a race, sporting event, contest or other game of skill or chance”. A violation of this statute is a class 1 misdemeanor.

The Arkansas statutes (in Title 5, Chapter 66, Section 113) prohibit “betting any money or any valuable thing on any game of hazard or skill”. The fine is $25.

Similar prohibitions against wagering on skill-based games exist in at least five or six other states.

So, I could probably operate legally, if I eliminated the element of chance from all of my games, and if I excluded residents of non-skill-gaming states from participating.

But the law is a slippery thing. I’d be stupid not to retain expert legal counsel, since I’m not personally capable of keeping up-to-date on the gambling laws for 50 different states, as well as the federal laws (which, by the way, automatically kick-in whenever you’re charged with a violation of a state gambling law).

So, that’s it then?

If it were just the legal issues, I might have the stomach to go for it.

I’ve found a number of attorneys who specialize in gambling laws, and I could hire them to do some research for me, giving me a set of parameters within which I could operate legally.

I don’t have a lot of start-up capital, but getting some sound legal advice would be a good use of that cash.

And if it were just a matter of learning COM interop programming with C++, I’d be up to the task. After all, I’ve learned a half-dozen different programming languages over the last few years, and I could certainly learn a few more.

If my only concern was providing a fun coding experience, or setting up a fast implementation, I’d take the plunge.

But there are too many obstacles here, and I’m afraid I’d injure my probability of succeeding by picking a project so fraught with peril.

Instead, I’m going back to the drawing board.

I’m going to re-visit my previous list of ideas and decide on a more suitable business plan. Unfortunately, despite my enthusiasm for the AI-Coder idea, this is the wrong project for me.

In many cases, those first few haphazard strokes set a tone and texture that guides the rest of the creative process.

While the paint is still wet, and the figure is still mostly unformed, I’ll step back from the canvas and look at what I’ve done so far, asking myself “What is this? I like what I’ve got so far, but how can I turn it into something worthwhile?”

The decisions made during that post-improvisational stage often determine whether the painting gets hung on my wall or tossed into the dumpster.

I feel the same way right now, at the beginning of the AI-Coder project.

Although I’ve spent the last year or so experimenting with AI techniques and building my own game-playing software, those tasks really just give me a preliminary sketch for the overall design of the AI-Coder platform. Since I’m developing this software for widespread consumption, the design constraints and priorities are entirely different than if I was building something just for myself. And of course, as is always the case, some of the design criteria conflict with one another.

At this point, I’ve identified four overarching principles that should guide the whole development process. In no particular order, it’s essential that the software is:

• Fun
• Secure
• Fast
• Legal

All four of those constraints will make a big difference on the software design, and all four of them are critical to the monetary success of the project. If I fail to meet any of those criteria, I can expect big problems.

Ahem…What?

My parents are avid readers of this blog, and when they read that I’d chosen the AI-Coder project, they were completely perplexed. Not necessarily because I had chosen this project above all the others. Rather, they were perplexed about what this project even is.

I can hardly blame them. So far, I haven’t figured out how to explain the gist of the AI-Coder project without going into a twenty minute explanation.

So before I dive into my four design criteria, I’m going to step back for a second and try to write a 30-second elevator pitch for AI-Coder:

I’m sure that the definition of the AI-Coder project will fluctuate as the software (and the business develops), but that’s the core idea. And hopefully, a description like that clearly expresses what I’m trying to accomplish without needing any further explanation.

Now that I’ve gotten the elevator pitch pretty solidified, I can focus on my four central design criteria.

Over the next week, I’ll post four follow-up articles, discussing how the elements of fun, security, speed, and legality will affect the design decisions of the AI-Coder platform.

And, by the end of that process, I hope to develop a clear concept (from both a business and a technical perspective) of how my preliminary sketches will develop into a fully-formed picture, one that I’ll be proud to put on public display.

At times like these, I should remind my readers that–in addition to my entrepreneurial ambitions–I’m still happily (and busily) employed in the software business. And sometimes that means I’ve got to focus on projects for the people who actually pay my salary.

In today’s blog post, first I’ll talk a little bit about what I’ve been doing at work lately. And then I’ll grumble a little bit about last week’s lost-blog-post snafu. And then, I’ll talk about a little bit about the final five business ideas in my 30-days-30-ideas project, culminating with an announcement of which idea I’ll be pursuing. (!!!)

Here we go…

So, it’s gotten busy at the office lately. We’re entering the final stages of our release cycle, and code freeze is coming up soon. One of my main contributions to the product is a new domain-specific language, with an accompanying compiler. Most of my actual engineering work is done, though I’m still adding a few tweaks here and there, when the need arises (last week, I added an inheritance model to the language & compiler).

But it seems like now is when the really intense work is kicking in. With a new compiler available, I’ve been conducting training sessions with engineers from some of the company’s other teams. The QA department is going to use the compiler to automate lots of testing that used to be manually conducted (or only semi-automated). And the professional services department is going to use the compiler, in lieu of our config UI, to produce product customizations for our clients.

As author of the compiler, I’m now also the resident expert with the new language. Although I’ve written a few dozen demo scripts to showcase different aspects of the language functionality, I’m assuming my workload will triple (at least) over the coming weeks, as I assume primary responsibility for authoring code in the new language.

And that’s okay. For me, crunch-time can be oddly satisfying, if I’m working on a project that really interests me. When I’m passionate about a piece of software, I don’t mind taking some extra time to make sure that it gets the love and attention it needs.

For some reason, at times like this, I’m reminded of the A-Team, a silly American TV series from the early 1980’s.

After a ridiculous battle with an army of thugs, and after escaping from yet another imprisonment in an abandoned warehouse (using their ingenuity with blow-torches and explosives to free themselves), the A-Team would end each episode back on the run again. Covered in dirt and dried blood, Hannibal Smith (the A-Team’s unflappable leader) would lean back in his chair and chew on a gnarly cigar, smiling into the wind and barking “I love it when a plan comes together.”

That’s how I feel at the end of a successful software project.

And the A-Team metaphor works on so many levels. Most software projects are written by a ragtag team of weirdos (is there a Murdock or a B. A. Barackas on your team?), and most software projects are at least partially welded together from bits of old farm machinery. At the end of the project, we satisfactorily drink a celebratory beer or puff on a metaphorical cigar. And then, immediately thereafter, we find ourselves on the run from the law again, fugitives from sanity and reason, riding around southern California in a dilapidated old van.

Metaphorically, at least.

Anyhow, I was just having a nostalgic moment and thought I’d share it with everyone. Those of you without a background in American pop culture circa 1985 won’t have a clue what I’m talking about.

That’s the kind of feeling I’m hoping to cultivate with my own software business. Sure, I want to produce useful software. And, of course, I have certain revenue targets that I expect to meet. And ultimately, I’d like to contribute something back to the field of computer science. But, along the way, I’d also like to keep that software passion alive and kicking by working on really cool and interesting projects.

Anyhoo…now that I’ve gotten THAT out of my system, I’d like to talk about last week’s lost blog post.

I had written a long, thorough, and contemplative treatise on the topic of pricing. I dissected each of my five remaining business ideas, from the perspective of different pricing models, examining how each business idea supported different kinds of pricing options, and how those pricing options either supported or undercut the inherent strengths and weaknesses of each idea.

And then at the end, for a laugh, I decided to attach this hilarious photograph:

And somehow, in the process of uploading the photo, I lost most of the pricing post.

I’ve decided not to rewrite it. The original draft took too much effort, and I think I’d be disappointed trying to recreate it. But here are a few of the salient points, in no particular order:

• Nearly all of the businesses would support some kind of segmented pricing model. This kind of pricing model divides the market into various segments (Community Edition, Pro Edition, and Enterprise Edition) based on the typical budgets of the members of each segment. Although the more-advanced product-types have a few additional features, the different editions exist primarily to allow customers to measure the depth of their wallets and purchase accordingly.
• The WebDelve and Project Artifact Manager products are the perfect textbook examples of segmentable products, since they’re basically just shrink-wrap software applications, installed on the customer’s own hardware, with little need for advanced customization options.
• The VaporTrade product is especially interesting, since most customers would probably also purchase a subscription to a daily data-feed. The data-feed could have its own segmentation (including different aggregations of securities and indices), and I could put together an interesting set of cross-promotions. (Buy the VaporTrade SuperGenius Edition, and get six months of the Omnibus DataFeed for FREE!!!)
• Pricing can be tricky when a competing product, from the world’s googliest search engine company, is available for free to pretty much anyone who wants it. The WebDelve product would have to differentiate itself in significant ways (other than price). These would likely be 1) The data is on your own server, 2) The product comes with a zillion reports, but you can also write your own, 3) Sure, you can see a high-level aggregate of user activity, but you can also drill-down to individual sessions of people browsing your site, 4) Better integration with your product/content database (write queries that JOIN your web analytics DB with your e-commerce DB), and 5) Better time-series charting analytics (moving averages, momentum, relative strength, etc).
• Pricing is basically not a factor, at all, with the Beltway Analytics idea. I can’t think of a way to develop this website without it being entirely funded by advertising revenue. And that makes me nervous as hell.
• The AI-Coder.com project actually has more possible pricing models than any of the other ideas. I’ve already proposed the subscription model to lots of people. Users could participate for free, at a limited level, but would be required to pay a small monthly fee ($4.99 ~ $6.99) for more intensive use of the system. But most of the feedback I’ve received has indicated that people will resoundingly refuse to pay a subscription fee. But what if I offered (daily/weekly/monthly) prizes for top-performing gamebots? What if each game contest is a tournament, with a small cash prize? What if two chessbots each pay fifty cents to enter a tournament, with the winner taking home a crisp, cool, dollar? (They’d also pay me a dime for facilitating the tournament.)

  What if universities wanted to pay a fixed rate for a class tournament? What if companies wanted to host extra-curricular tournaments among the members of their engineering teams? I could rent out my game servers by the CPU-minute.

  I could provide a downloadable version of the tournament platform, so that users could test their gamebots before entering them into live competitions. They could get the basic SDK for free, paying me only to facilitate individual contests. Or, I could facilitate the tournaments for free while also giving away the basic SDK, making money only by selling an advanced GUI interface to the SDK (where users could host their own scrimmage tournaments to develop the AI abilities of their gamebots).

  In all likelihood, the ideal pricing model for this software would probably be a hybrid, segmented approach. Subscriptions should be available for those who want a flat monthly rate. Cash tournaments should be available, for people willing to stake a few dollars on the quality of their AI. And flat-rate, one-time group tournaments should be available, for college classes, corporate tournaments, and other groups-of-nerds.

In the final shakedown of things, I’ve decided to pursue the AI-Coder.com idea. With actual cash on the line, I think there are thousands of programmers who’d be interested in participating. By providing a market-segmented pricing structure for tournament stakes (anywhere from a nickel-per-game to twenty bucks for a best-five-of-seven), I should be able to entice users into playing, while also keeping the skilled gamebot authors away from the absolute beginners.

This is possibly not the most profitable idea in my list. The VaporTrade software probably has the greatest profit potential (particularly because of the accompanying data-feed). And the WebDelve software probably has broader market appeal (though I don’t relish the the idea of competing with one of Google’s principle products).

But, the AI-Coder software really appeals to that side of me that’s passionate about computer science. This is where I think I’ll do the most interesting algorithmic work. This is where I think I’ll make the greatest contribution back to the computer science community. And this is where I’ll probably get to hang out with the ragtag team of weirdos that I like so much.

I think this project will be the most satisfying to me personally.

So six months from now, if everything goes as planned, I’ll be covered in dirt and dried blood, muttering to myself “I love it when a plan comes together”.

At this point, I have a certain affection for each of the eight surviving business ideas. But if I don’t eliminate seven of those ideas, I’ll never get started on the really satisfying work of designing software, writing code, developing a marketing plan, and ultimately earning ridiculous sums of money.

So it’s time to make a few more cuts.

Today, I’m eliminating these three ideas:

• Idea #2: Budget Buddy
• Idea #18: Art Marketplace
• Idea #27: Lick This Chocolate

There was a certain appeal to the Budget Buddy idea. It would have been a simple implementation, my six-month timetable would have provided ample time for development and testing, and I could have spent some extra time developing a compelling set of aesthetically-pleasing charts and graphs.

But the market for this software would be somewhat elusive: People with organizational tendencies strong enough to compel the usage of budgeting software probably already have a budget-tracking methodology of their own (most likely a simple Excel spreadsheet).

Likewise, the organizationally-impaired among us are not very likely to use budgeting software to begin with, so the target demographic for this software would be the slim margin of people who possess the discipline to budget, but who lack the tools to do so.

And since simple budgets can be constructed with the humblest of tools (pad of paper + pen), I’d be nervous about trying to find (and sell to) such a narrowly-scoped market segment. Finally, the low price tag and the lack of repeat-sales opportunities (or upsell opportunities) makes this software quite a bit less compelling.

As for the Art Marketplace and Lick This Chocolate ideas…well…I’m really sad to see them go.

I’m an artist at heart, and I’d love to be somehow involved in an art-oriented business. But I’ve decided that these ideas just aren’t strong enough. Here are a few reasons:

• The Art Marketplace is really just an online store. I could customize an existing auction/ecommerce engine without writing much new code. But I think my skills as a software author are one of my most important assets, and I think I’d be better served by choosing an idea that makes better capitalization of those skills.
• An online Art Marketplace would require major efforts in marketing, on two separate fronts: I’d need to create a strong marketing presence among art-producers as well as among art-consumers. I’m disconnected enough from the world of fine arts that I really don’t know how to market to either of those demographics (much less to both of them simultaneously).
• The Lick This Chocolate business would require even less software customization than the Art Marketplace. And, as much as I’d love to be surrounded by sculptors, nude models, and mountains of chocolate, this idea would require me to hire a small team of talented employees. Since one of my primary objectives is to bootstrap this business from scratch, with very little budget for salaries or materials, it would be silly to choose a business model where I couldn’t personally contribute more to the day-to-day operations. If I were already an accomplished sculptor or chocolatier, this idea would be much more attractive.

So those are today’s cuts.

All three of these ideas are still very attractive to me, for their own reasons, and maybe I’ll pursue them later. But, for now, the list has been trimmed down to just these five final contenders:

• Idea #1: WebDelve: Small Business Web Analytics
• Idea #4: Project Artifact Management
• Idea #6: AI-Coder.com
• Idea #15: Beltway Analytics
• Idea #28: VaporTrade

(Just kidding, Phil :)

Now, I’ve discovered that the same thing has happened again.

On July 4th, I wrote about an idea for a role-playing game called Assassinate! Then, over the course of the next seven days, someone in Scotland obviously read my blog, started a company (called Outer Light) and developed The Ship, which was publicly released on July 12.

According to a July 27 article in the New York Times, this “ingenious” game is “essentially a virtual version of real-life games like Assassin”. Here’s how Times writer Charles Herold describes the opening scenes of The Ship:

Good grief. That sounds startlingly familiar.

Compare it with my own description of the Assassinate! game:

Obviously, the people at Outer Light studios completely copied my idea. And understandably, I’m a bit shaken by the whole thing.

But I’ve got to give those guys credit for developing and marketing an entire game: the characters, the storyline, the graphics, the client-server software and everything, all within a single week. I’m so impressed, in fact, that I’m willing to forgive the blatantly obvious fact that they stole my idea.

Seriously though…

It’s actually very validating to see that these ideas are being simultaneously developed by other authors. It gives me the feeling that my intuitions about the software market are correct. Or at least, that my intuitions are congruent with the intuitions of other software developers throughout the world. If I’m hopelessly misguided, at least I’m in good company.

It’s been fun lollygagging around, lazily daydreaming about business ideas. But now it’s time to start throwing the dumb, unworkable ideas into the fire.

I won’t quiiiite make a final decision today, but I am going to narrow down my choices significantly, crossing twenty of the twenty-eight ideas off my list. In doing so, I’ll provide some broad reasons why I’m eliminating various groups of ideas.

And when all the eliminated ideas have been laid out on the table, we’ll take a brief look at the eight remaining ideas. And then I’ll try to clear my head, preparing myself for the increasingly difficult task of killing my remaining babies, until only the winning idea remains.

But, what are we waiting for? There’s a lot of work to do.

Let me present you with the first category of losers:

The Problem Has Already Been Solved

As I’ve discovered from many of my informative readers, some of these ideas have already been done (and done extremely well) by other software developers. In many cases, the existing products have been on the market for years. They have mature feature-sets and an established clientele. In most of those cases, I’m going to choose not to compete.

At least, not right now. Not with this product. In the future, when my software company consists of more than just me, it might make more sense to deliberately engage an established competitor with a mature product. But not today.

In some cases, the exact software that I had in mind doesn’t exist, but the market has compensated in some other way, solving the problem through the introduction of other products or services.

One way or the other, these ideas all fall into the “It’s Already Been Solved” category:

• Idea #3: A Simpler Email Server

  Hosted Gmail and Zimbra, as well as Exchange (and a bunch of other friendly Windows email servers)

• Idea #5: TiVo For Audio Streams

  The ubiquity of Podcasts pretty much eliminates the market potential here.

• Idea #8: DotJNet Bytecode Translator

  Between the IKVM Project and J#, there’s not much more compelling functionality I could offer.

• Idea #9: Holdem Simulator

  CalculateEm offers similar functionality to my application, but it’s already capable of screen-scraping more than 100 different poker clients. Implementing 100 different screen scrapers sounds really tedious to me, so I don’t want to compete on those grounds. As far as a full-featured simulator/bot-construction kit, WinHoldEm is already very popular. I think my software is superior (in nearly every way), but that’s not really a market niche I’m interested in pursuing.

• Idea #14: Instant Photo Sharing

  When I saw the software and services currently being offered by Flickr I knew they had already implemented my vision for this software. Anything I implemented now would just be an attempt to copy their already-significant accomplishments.

• Idea #19: My Blue Country

  Evidently, the national political parties and PACs already have the distribution-of-campaign-funds problem pretty much solved.

• Idea #16: Incessant Pestering

  Need I mention the competitors? There are a billion of them, and my differentiating points are very slight, at best.

• Idea #21: JavaScript Obfuscator

  There are already many seemingly-capable JavaScript obfuscators on the market (and they generally only sell for $15 or $20). I don’t know if they perform their obfuscations directly on the Abstract Syntax Tree. But, honestly, who cares?

There’s Just Not Enough Market Potential

As much as I like these ideas, I just don’t think it would be possible to make enough money to justify the effort.

• Idea #10: SIMD for Java
• Idea #11: Desktop Workspaces
• Idea #23: Quick DSLs for Eclipse
• Idea #26: Anonym Disambiguation

In general, I think these would make cool open source projects (in particular the SIMD for Java, or Eclipse DSL projects) or personal research projects (like the Anonym Disambiguation website), but I think building a successful business from any of them would be a long shot.

They Just Don’t Excite Me

I’m going to be committing myself to this project for a long time, so it would be a mistake to get engaged in a project that doesn’t really stir my passions. And, although I think these could all be valid products, I’ll leave them for someone else to implement. Someone who can get really jazzed about household inventories (sorry mom!!!) or a search engine for product data & reviews:

• Idea #12: Household Inventory Database
• Idea #20: Desktop Analytics
• Idea #22: Copyright Infringement Finder
• Idea #24: Product Info Search
• Idea #25: MicroISV GoldRush

Insufficient Domain Knowledge

I these are all very strong ideas, but they’re probably not quite right for me:

• Idea #7: Retail Analytics

  I have very little experience in the world of retail sales (either electronically or in a physical store). Even though I could implement the analytics, I think I’d be at a disadvantage during requirements-gathering and marketing. Of course, I could overcome those weaknesses (especially with a few more people on my team), but for this first product, I’d rather focus on something where my own current level of domain knowledge will suffice.

• Idea #13: Assassinate!

  God, it sounds like fun, doesn’t it? Unfortunately, I have nearly zero experience with games, either in building them or (probably more importantly) in playing them. Maybe this’ll be a good project for later, but I think I’d need serious help from actual gamers, and at the moment, I’m just a one-man-show.

• Idea #17: Composer’s Workbench

  As much as I’ve daydreamed to the contrary, I’ve never been anything but a wannabe musician. I’d love to use software like this, but I’d be deluding myself to believe that I’m competent to build software like this myself right now.

The Finalists

That makes twenty ideas eliminated so far.

Leaving eight ideas that are still under consideration (in no particular order):

• Idea #1: WebDelve: Small Business Web Analytics
• Idea #2: Budget Buddy
• Idea #4: Project Artifact Management
• Idea #6: AI-Coder.com
• Idea #15: Beltway Analytics
• Idea #18: Art Marketplace
• Idea #27: Lick This Chocolate
• Idea #28: VaporTrade

This is where it gets really tricky.

I’m going to have a tough time deciding which of these exciting ideas excites me the most. Which of these technically challenging projects will be technically challenging enough to satisfy my interests, while being straightforward enough to implement (on my own) within a six month time frame?

Which of these marketable ideas are truly marketable enough to meet my revenue requirements? For me to seriously consider one of these ideas, it needs to have to potential to produce (at minimum) $250,000 in annual revenue within a few years. Otherwise, it’s probably not the kind of business that can substantially grow. And, while I like the idea of a one-man software company, I’m more interested in building a business with a bit more growth potential.

So, over the coming days, I’m going to continue chewing over these ideas. I’ll try to eliminate at least one idea every day (though I’ll be out of town again this weekend, so I probably won’t finish the elimination process until late next week).

Please continue contributing your critique.

I’ve really appreciated everyone’s feedback so far in this process. Many of the ideas I’ve posted have grown from the suggestions and comments people have posted to the blog entries. And many of my conclusions regarding the software marketplace would have been woefully uninformed if not for the continued participation of my readers.

So, thanks for sticking around this long.

Ideas breed more ideas.

Thinking about these ideas, and writing about them, is addictive in a way that reminds me a lot about playing Tetris. (Yeah, yeah, yeah. I’ll get back to work in a few minutes. I just want to finish up this one level first.)

Once I started brainstorming at the beginning of the 30-days-30-ideas project, it was difficult to turn off the spigot. The ideas came to me faster than I could write about them. So, in addition to the nineteen ideas that I’ve actually published here over the last month or so, I’ve also jotted down a set of notes for an additional dozen or so software and business ideas.

The only reason these ideas didn’t also get published here is because I spent so much time doing the analysis and writing the blog posts for each idea.

At this point, I’m not willing to let the idea-generation process further delay the decision-making process. I’m anxious to start designing some software. So, tomorrow, I’ll start crossing ideas off the list, either because I think the marketing obstacles or the technical challenges or just too high. Or maybe because I’m not very passionate about a particular idea.

But before I dive into the decision making process, I’ll publish my notes for some of those other dozen or so ideas. Let me give you fair warning, though: some of the ideas are only half-baked. I haven’t devoted nearly the same amount of time analyzing these ideas as I did with the other nineteen.

Idea #20: Desktop Analytics

Google and Omniture and AWStats provide detailed information about how people use your website.

But wouldn’t it be cool if you could get similar types of statistical reports about the usage of your own computer? How much time did you spend on the internet? How much time did you spend using Excel? How many bytes of internet traffic did you use? How heavily-loaded is your CPU?

How many google searches do you do every day? How effective are your web searches? (What ratio of your page views are on search-engine pages, verses actual content pages?)

And wouldn’t it be cool to see a detailed, day-by-day chart of your desktop usage patterns?

Idea #21: JavaScript Obfuscator

Back when I started working on my WebDelve software, it occurred to me that it would be nice to automate the obfuscation of the JavaScript driving the collection-tier of the application.

I had been using a Perl script to perform regex replacements on the JavaScript, getting rid of comments, obscuring variable names, and removing unnecessary whitespace. The resultant JavaScript code was not only well-obscured, but also much more compact than the original code.

But the obfuscation was pretty fragile. The Perl script didn’t really know how to parse JavaScript, and I had to be careful not to let the obfuscator break the code.

Then it occurred to me that I could use the Mozilla JavaScript engine (the Java implementation is called Rhino) to perform obfuscation at a much more semantic level. I could actually create an abstract syntax tree from a snippet of JavaScript, and then I could perform my obfuscations directly on the parse tree, subsequently serializing the parse tree back into JavaScript code.

I downloaded the Rhino code and tinkered with it enough to think that it would be pretty simple to write a really solid obfuscator.

Idea #22: Copyright Infringement Finder

A friend of mine is a professional photographer who works in Hollywood, taking pictures of celebrities and models. Up until last year, he kept a comprehensive portfolio on his website.

But it was a constant battle for him to find and fight the many people who made digital prints of his images and sold them on eBay or used them on their own websites, without permission. Eventually, he gave up the fight, and took most of his portfolio offline.

I think there’s a big market for an online service where artists (and other types of content owners) could register their images and writings and music. The software would create a content fingerprints and then scour the internet, looking for unauthorized usage. When the software found offenders, the people hosting the unauthorized content would be contacted with requests to either remove the content or apply for redistribution rights.

I think content producers would be thrilled with such a service. But the internet is a big place, and infringements would be hard to find.

Idea #23: Quick DSLs for Eclipse

Recently, at my actual job, I developed a domain-specific programming language that customers and sales engineers can use to customize the company’s main product.

I developed an EBNF grammar and wrote a compiler. It was a fun project.

Now, it’d be really nice to have an Eclipse plug-in for the new language. But I’ve looked into it, and it looks like a pretty complex process.

Why?

The grammar and compiler are already there. It should be possible to produce a basic plug-in (with syntax highlighting, hyperlink navigation, and rudimentary refactoring) without having to do anything else at all.

DSLs are becoming increasingly common, and it’d be nice if there was a fast, easy, standard methodology for creating IDE customizations for those new languages.

Idea #24: Product Info Search

So you’re thinking about buying a new laptop, and you want to know which brands have the most durable monitors. Or maybe you’re wondering which different brands of digital SLR cameras come with multi-point auto-focus capabilities.

Searching with Google can be frustrating, because the search results are filled with computer stores and camera shops. It’s usually a chore to weed out the actual product reviews, and it’s often difficult to find the manufacturer’s detailed product information.

A search engine that deliberately eliminated pages from online retailers (or at least, confined retailers to a distinct part of the search UI) would be extremely helpful.

Idea #25: MicroISV GoldRush

They say that the people who really profited from the original California gold rush were the people selling shovels and pickaxes. Very few prospectors ever struck it rich panning for gold, but the people selling the pans made a killing, whether or not anyone found any actual gold.

I’m sure the same is true right now, in the midst of an explosion of small software companies. Certainly, very few of the one-man software companies will ever become multi-million dollar corporations (and, to be fair, many solo software developers go solo precisely because they like the freedom and flexibility of operating a very small business). But the point I’m trying to make is that there’s probably plenty of money to be made by developing software tailored to the prospectors in the MicroISV gold rush.

This is only a vague idea, but I’m kind of envisioning a single application to unify all of the tasks of a tiny, one-man software shop:

• Simple logging (and progress reporting) for features and bugs
• Simple CRM, for keeping track of client info and for logging communications with various clients
• Basic income/expense tracking
• Production and management of client invoices

There are probably a few more features that would need to be included, in order to make this a compelling piece of software for a MicroISV owner, but I think there’s a kernel of a useful idea there.

Idea #26: Anonym Disambiguation

Have you ever searched for an old friend online?

Maybe one of your old high school buddies happens to also be a guy named “Benji Smith”.

Maybe your Benji Smith is an extremely successful real estate agent in South Carolina, who owned the benjismith.com domain name until April 2005.

Maybe the Benji Smith you know is actually a ballroom dance instructor in Tennessee, whose buddy Matt Pickwell bought the benjismith.com domain name for him in May 2005, the nanosecond it became available again (after the other Benji Smith let it expire).

Or maybe you know Benji Smith (the heavyweight boxer in New Jersey) or Benji Smith (the high school cricket player in South Africa).

But wouldn’t it be convenient if a search engine could analyze all of the instances of “Benji Smith” out there and use a set of similarity algorithms to cluster all that Benji Smith related information into nodes corresponding with each of the actual Benji Smith individuals out there?

But it’s even trickier than that, because people refer to themselves on the internet using all sorts of different anonyms.

Suppose you met someone online through a dating website who calls herself flowerjane77. In her Match.com profile, maybe she used a unique phrase to describe herself (”i’m a devout follower of nothingism”). Maybe she also has a MySpace profile, under a different username (inanejane), where she also mentions her (”profound unfaith in the principles of nothingism”). Based on the linguistic similarities between those two documents, it’s possible to create a weak association between the anonyms “flowerjane77″ and “inanejane”.

I think a specialized search engine, focused on performing anonym disambiguation of internet identities, could be very popular. Particularly if its primary objective was to analyze and associate the identities represented across hundreds of different dating and social networking websites.

Idea #27: Lick This Chocolate

Okay, fair warning: this isn’t a software idea at all. But this idea has been rattling around in my head for many years, and I think it could be a successful business.

I’d like to recruit a small team of college art students to do create original sculptures, with live nude models as subjects, using blocks of high-quality dark chocolate as a sculpting material.

It’d be like a erotic version of the chocolate Easter bunny, and I think it’d make a great gift idea.

An ex-girlfriend of mine from a few years ago was expert in making the most incredible chocolates, laced with cayenne pepper and other spices, and I really like the idea of using a similar recipe for these chocolates.

Hot. Spicy. Nude. Chocolates.

The more expensive pieces would be carved directly in chocolate by the artists. Less expensive pieces would be limited-edition reproductions of original sculptures by the same artists.

Idea #28: VaporTrade

Waaaaay back in my first published software idea, I briefly mentioned my experience with stock-market technical analysis. Back in 1999 and 2000, I developed some software for performing in-depth analysis of price movement patterns on historical stock market data.

For example, I might ask the software to find all instances (over the last fifteen years) where a stock’s closing price increased by at least 2% each day, for five consecutive trading days, while the trading volume simultaneously decreased by at least 5% each day. Then, with all of those instances, I might filter out all the securities whose prices were less than $10 or more than $10, or where the trading volume averaged less than a million shares per day. Finally, I could ask the software to create clusters, based on the price movement patterns of the securities over the next ten trading days. Which ones decreased in price by more than 5%? Which ones increased in price by at least twenty-five cents?

At the core of the software was an extremely fast analytics engine capable of stringing together arbitrarily complex formulae. I wrote a formula parser to read strings like this:

ROLLING_MAX(5, MOVING_AVERAGE(3, (HIGH(MSFT) - CLOSE(MSFT)))

In English, that’s a formula for “a 5-day rolling maximum value of a 3-day moving average of the daily Microsoft trading range”.

The formula evaluator compiled these formulas into an internal representation that allowed for lots of cool optimizations: prefetching of data that would likely be used, caching of values from intermediate calculations, short-circuiting to eliminate unnecessary calculations. And, as a bonus, the more complex the formula, the more likely it would be to benefit significantly from the optimizations. Even back then, with an ancient computer (and an even more ancient JVM), I was able to analyze more than 33 million data points (15 years of data, 250 days per year, for about 9000 securities) in about twenty minutes, calculating a few dozen different statistical indicators on each and every security.

I was very happy with the software. And I used it myself, with quite a bit of success, earning double-digit percentage returns on my investment every month. Until spring of 2000, when the market tanked and I lost most of my previous gains.

The software has been sitting quietly in my personal source code repository for the last five years, just waiting for me to dust it off again and do something interesting with it. The mathematics (and the parser, and the optimizer) made for very fun programming, and I’ve been itching for something challenging like that.

Sometimes I wonder whether it would make a good product. In its current state, it’s just a command-line application.

No charts.

No colors.

No trendlines or candlesticks or bollinger bands.

It consumes an XML file describing the formulae and the hypotheses that use those formulae. Then it connects to the database, retrieves the financial data, evaluates all of the formulae, and produces statistical reports (in CSV format, for import into Excel) based on the success and failure of the hypotheses. There is no GUI at all.

And one of the primary strengths of the application is that it was written just for me: a Java programmer. I didn’t have to simplify it, or make it intuitive for non-programmers. It’s intuitive for me, and that’s the only thing that has ever mattered. It’s easy for me to extend the software to perform new kinds of analysis just by writing new classes that implement a standard interface. But the software would be pretty useless for anyone who wasn’t comfortable authoring Java and XML files.

So I wonder whether it’d be worth the effort to wrap it all up in a pretty GUI and make the formula & hypothesis languages a little bit more accessible to ordinary humans.

But then what would differentiate it from the other zillions of stock market back-testing platforms?

To a certain extent, I think it would be better to market it as the “Stock Market Analysis Tool for Expert Programmers” because I’ve never heard of any other financial analysis tool that wasn’t specifically written for people with programming experience.

I love the city. I love the people. I love having the mountains just a stone’s throw away. During the winter months, I go snowboarding every week with six or seven people from my office. We manage to get a solid half-day in on the slopes, and still get back to our desks by 1 PM to finish off the rest of the work day.

But living in Utah has its down-sides. For starters, I consider myself pretty politically liberal, so living in the most conservative of all the fifty states often makes me feel like I’m not really participating in the political process. I have a solid track record, during every single election, of picking the losers.

Of course, I think I’d still be frustrated if I lived somewhere like Massachusetts. My vote still wouldn’t make much difference (though it’d be nice to be on the winning side of an election, for a change).

Instead, I’d much rather be casting my vote in a swing state, like New Hampshire or Florida or Nebraska. I’d rather be helping unseat a vulnerable incumbent than vote helplessly against Utah Senator Orrin Hatch. Again.

For example, if I could re-allocate my congressional votes this fall to any other state in the Union, I might choose Pennsylvania. In that state, Senator Rick Santorum (R) has his job cut out for him. He only has a 36% approval rating, and he only won re-election in 2000 by a slim majority (52%). Or, if I had a choice, I might choose to vote in Rhode Island, where Senator Lincoln Chafee (R) has only a 49% approval rating. Chaffe won the 2000 election with 57% of the votes. Political analysts are currently calling it a tossup, but with enough support from district-hoppers like me, a Democratic candidate might be able to oust Chaffee.

But why should I be able to vote in Pennsylvania or Rhode Island? After all, I have my own representation here in Utah. Shouldn’t I be more concerned with convincing
Senators Hatch and Bennett to better represent my views?

I don’t think so.

The Republican majority is so entrenched in Utah that those senators have no reason to give consideration to opposition opinions. At this point, the only way to have my opinions reach Washington DC would be for me to move to another state.

Or maybe there’s another way.

Elections are won and lost, to a certain extent, with money. The candidates with the biggest campaign budgets tend to win the most elections. And I, for one, would be happy to vote with my wallet, if I thought I could make a difference at the national level.

So my idea is to develop a website where sad, blue, red-state residents like myself could make campaign contributions to unnamed candidates in as-yet-undetermined states. Then, the software would evaluate all available statistics for each district, and each race, using that information to allocate funds to the campaign budgets of highly contested races, making proxy campaign contributions in the names of the original contributors.

“But Wait!!” I can hear you saying. “This isn’t a for-profit business idea. How could this possibly be considered ’starting a software business’?”

And I’ll concede that you’ve got an excellent point there. In order to make this work, I’d publish (very prominently) the fact that I’d retain 3% of the contributions for administration costs. But even with those fees in place (and I don’t think I’d be willing to take more than 3%), it would be difficult for me to earn a living at it. In order for me to meet my regular $250,000 personal gross revenue target, I’d need to oversee $8.3 million in donations, or $160,000 per week.

That’s a lot of cash.

It might be possible to drum up that kind of support in an election year like this one, where there’s so much at stake for Democrats. But it would be much more difficult during a less-intense election year. And it would be damn near impossible during those pesky oddly-numbered years when nobody gets kicked out of congress.

So, even if you could call this a business idea, I’m sure it doesn’t have the consistency or the revenue potential that I’m looking for, personally.

But it sure would be nice. Some of us would like to feel like part of a representative democracy again.

…

This is the nineteenth of 30 business ideas that I’ll be writing about over the course of 30 days. Or maybe it’ll only end up being 19 ideas in 36 days. We’ll see. Either way, one of these ideas will become a product over the next six months, and the foundation of my new software business.