I don't want to give you the impression that I write open source software because I'm an altruistic software engineer. I have selfish reasons, definitely. I want to make lots of money as well -- I have no problem admitting I'm a capitalist. Mostly I want to prove I can manage a software project.

What better way to do that than transparently? The disadvantage of giving away my development time for free is offset by the investment in a project that might get me into the project manager hot seat. Open source projects also make fantastic discussion topics for interviews -- which I found out last year -- because commercial companies won't let you talk about your work in detail with other people. I could talk about my open source project in detail because it is completely open.

Business people might get the impression that software developers are a bit too idealistic about their work -- their art -- to realize where their paycheque comes from. Software engineers might think that business people don't understand software processes well enough to get them working for them instead of against them. This post is an exploration of these thoughts and hopefully the start of a small discussion with my readers on the business of software, as seen by a software developer.

---

There are lots of ways for a software business to sell software to another business but here are quick rundowns of four major ways.

Note that this list does not include internally developed software or commercially-developed open source software (like Eclipse). That kind of software, while developed in a similar way, does not have similar business-to-business concerns because the development is internal to one business.

BDUFware

Secure a business contract to make software for a customer. Design the whole thing on paper up front, gathering requirements from your customer. Write one or many large specification documents (note the root word specific). Over the course of many months implement the contents of those documents. Spend a few weeks testing and then deliver the product.

**BDUF is software lingo for By Design Up Front.

Demoware

Quickly hack together a prototype to show people some neat software technology that they've never seen before. Listen to the oooohs and aaaahs at your demos. Continue to add features to this prototype until you make a sale. Once you have a customer with a chequebook in hand, spend some time cleaning up the prototype until it is ready for use in the Real World instead of in a controlled demo.

Agileware

Secure a business contract to make software for a customer. Pear the requirements down to the smallest amount of work that can produce an initial working product. Build that small product in a short BDUF-style iteration. After the iteration deliver the product, take comments from your customer along with new feature suggestions and incorporate them into the next iteration. Repeat over and over again until all of the customer's requirements are met.

** Agile is a classification of a group of software processes. An example is eXtreme Programming (XP).

COTSware

Identify a market that needs software to perform some task or is underserved by current products. Secure funding to develop this software from an investor (angel), bank (debt financing) or from your own pocket (equity financing). Develop the product with requirements gathered from prospective customers without giving your secrets away to competitors. After months of development and testing release the product to much fanfair, recoup your investment and make a profit.

** COTS more software lingo; it stands for Commercial Off The Shelf. It refers to software designed for a market instead of a specific customer, like Microsoft Office.

---

Each of these approaches has software development and business advantages and disadvantages. Here's my list. Feel free to add to it in my comments.

BDUFware

Advantages

• This is how businesses are used to doing business with software companies because it's the oldest method.
• Once the software company has the detailed requirements its easier to estimate the total effort required, and make a development schedule.
• It's easier for a business to budget for a project that has a timeline, even if that timeline is overly optimistic.
• Because everthing is "on paper" this process works well for offshoring the programming effort to cheap programming labour in places like India.

Disadvantages

• It's difficult to secure a contract for BDUFware without a demo unless you have a reputation or recommendation.
• It's hard to gather write requirements for a product that doesn't exist yet. The customer often doesn't know what he wants.
• This process does not handle change in the requirements late in development very well, so it has a high failure risk. Not a failure in that the project won't finish but that it won't solve the problem it was meant to solve.
• Time estimates for large software projects are difficult to make.

Demoware

Advantages

• The demo is very, very close to what the end product will look and behave like. It's easy to sell a product that looks like it is almost done.
• Doesn't require as much up-front financing as COTSware because development time is faster.

Disadvantages

• At worst the demo is smoke and mirrors and the product is vapourware. Some software companies use completely fake demos to sell a product before it exists.
• At best the product can't be deployed in a commercial environment because it hasn't been tested, has no deployment plan and has a hasty demo architecture.
• The customer thinks you are almost ready to ship, because of the 80/20 rule[1]. This is good for making sales but bad for shipping the product with a quality that the customer is expecting.
• Demoware doesn't require as much up-front financing as COTSware -- but putting together Demoware takes time and money, which usually means investors.
• The demo architecture might be so bad that making a tested and deliverable product from it is impractical or impossible.

[1] There are a few variations to the 80/20 rule, actually. This version of the 80/20 rule states that 80% of the "work" takes 20% of the time. The last 20% of the work takes 80% of the time. It all depends on how you define "work" -- but in this case it's the difference between visible work (what the demo does) and under-the-covers work. Without the under-the-covers work the product is not ready to ship, but the customer probably doesn't know this.

Agileware

Advantages

• Unlike Demoware the software you use for demos is always ready to ship as a real product.
• The agile process allows for changes later in the development cycle.
• Agile puts an emphasis on testing.
• Agile puts an emphasis on continual user feedback on a deployed product so the customer is getting what they want.

Disadvantages

• Business are not used to dealing with software companies in short milestones, without a definite timeline and with no definite end to the project. Businesses are not used to thinking of maintenance iterations as pseudo-development iterations in Agile processes.
• It takes longer to pull together an impressive demo with this approach (unless you build a hacked demo on an existing milestone and then throw it away) because unlike Demoware the demo is actually tested and deployed properly.
• Because Agile processes are new, few developers are used to Agile processes and finding capable and disciplined staff is difficult. In five years this problem will be much less of an issue.

COTSware

Advantages

• There's no single customer to dictate direction so the software company has more flexibility to go after a larger market.
• A larger market means the opportunity to make much much larger profits (like Microsoft).

Disadvantages

• Riskier than the other three approaches for both the software company and its investors. Without a shipped product, the company has no revenues.
• Requires a very good understanding of the market/domain and competitors, which takes time.
• Requires months of financing up front.
• A market opportunity usually has a very short window, putting pressures on the development process. These sacrifices usually manifest themselves in deployment and quality problems.

---

That's it for now, but I'll probably be adding to this in the upcoming week. Comments?