Striking up a conversation about my business idea

A personal note:

This post is quite off topic from the theme (if there is a theme) of this weblog. I try to share my experience (good and bad). By experience, I mean things I believe to be the case thanks to having experienced them from concept to action right through to consequences.

Now I'm sharing some of my thoughts as I fashion a concept into a piece of software art. As I haven't suffered the consequences, I have no experience to impart.

All I can say in defense of these posts is:

"Our show may not be fancy, but it's noisy and it's free!"

...

From "Signs of Art":

Art is "the documentation of a thousand interesting decisions". [emphasis mine]

Let's take that apart word by word:

"The documentation..." In order to qualify as art, you've got to be able to share it with others. This means capturing it on some canvas whether it's paper, a DVD, a web page, a city, or your skin. If you can't share your art, it's not art. It's a conversation with yourself and I'm sure you're fascinating, but why not share it with the rest of us?

"... a thousand..." A thousand is a swag. It describes that there needs to be some perception of effort for a work to be art... I'm not suggesting that an outside observer needs to look at art and say, "Gee, that looks hard to do. I couldn't do that." The observer needs to experience something in the piece whether it's the size, weight, or complexity of the work and can't be created with a single trivial decision.

"...interesting decisions..." Now, here's the heart. Art is when someone captures a set of decisions worth remembering. Blue or red? Serif or sans serif? Ruby or Python? ... It's a personal thing. Some decisions will inspire, some will bore and the sum of all the decisions will affect each person differently.

Software is art.

——Michael "Rands" Lopp

Well, I've been having "a conversation with myself" for two years and it's time to share. I'm pretty confident I've made quite a few decisions. Are they interesting? You be the judge. Some of them are fashionable right now (delivering an AJAX application on a subscription basis), some not (development tools).

I'm going to kvetch about the so-called "intellectual property" laws: they make it hard to have a meaningful dialogue with the world. That's because they're really about keeping secrets, not possession of property.

I'm not worried about my ideas being "stolen." For starters, if anything I'm considering is so obvious that someone reads it and yells "that's it, let's do it, yeah!" based on my description, then I'm pretty sure there are already a dozen people already doing it and we're only talking about adding one more competitor.

"Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats."

—Howard Aiken

So here goes, I'm going to start talking about the business model. I think it's pretty safe to say that I will not ever apply for a business method patent.

Where's the beef?

Let's start with the business idea. There are two value propositions. The first value proposition is "the beef." It's how we will attract users and grow. We help individual members of a software development team build software. The first value proposition is all about the team members: the product managers, the team leaders, the testers, and the programmers.

Here's the product:

Our product is a wiki. It's a web site that describes the state of their software development project. The value proposition to team members is that the wiki helps our users organize their work and communicate with their team mates.

There's a bit more than repackaging any of the zillions of free wiki servers:

• There is special support for the semantics of software development. There is an ontology that includes entities like code, builds, releases, acceptance tests, defects, and, of course, deadlines.
• There is special support for tracking and inspecting the history of projects.
  
• There is integration with existing tools like issue tracking software and source code control.
  

Before I get into some of the details, let's look at the business idea from Rands' software as art perspective. What are some of the decisions that drove the first value proposition and the wiki approach?

One decision is to sell from the bottom up (for more about that, here's my rueful explanation). That drives an approach to the product. For example: the product has to provide value to even a single user on a team; it has to integrate with existing tools; and it cannot require a server installation.

The fallout from the bottom-up decision (actually it was a reversal of another decision) has been heavy. Most of the big wins I conjectured for a software development team have been "boil the pond" stories: they only work if the entire team adopts a practice.

When you think of one user at a time, you have to think a lot smaller in some ways. Two things that stand out are helping people organize their own work and communicate clearly. Thus the wiki.

Decisions are at least as much about what a project isn't than what it is. I have a jillion ideas about how wonderful things will be when a critical mass of users on a single project adopt the product. Nevertheless, it isn't about making teams effective, it's about making individuals effective.

I also have strong opinions about the benefits of integrating release management with continuous integration, source code control and automated acceptance testing. Nevertheless, it isn't a build and/or release tool.

I think I have some idea what kind of development software managers want to buy. There's always a workflow component. Nevertheless, it isn't about setting up a process and constraining users' behaviour.

I'll be circulating more detail soon, including the second value proposition. Please feel free to comment publicly or privately: I welcome all feedback.  ¶ 4:00 PM