Design vs. Develop

PHP Appalachia 2008 will be held sometime this September (thanks to Keith for the tip). It’s in the planning stages and deposit money is needed to make it happen, so contact Elizabeth Naramore at elizabeth _at_ naramore _dot_ net to pitch in.

Definitely my kind of conference

UPDATE: here are the official details.

(via OSC)

Anthony weighs in on features for Joomla! 1.6. I’d have say that I argee with him. Is there anyone out there who uses the Banners, Weblinks, and Newsfeed components to such an extent that it would be highly inconvenient to leave them out of the core? I personally don’t use these components (whenever I want a banner, I usually reach for a content module).

Recently I’ve been doing a lot of thinking about the different business models available in the software industry. While software companies sometimes assert that they have a unique model used by nobody else, all of them ultimately boil down to four basic ones: services, product centered services, products, and products distributed as services. All four of these are perfectly valid models with unique opportunities. The best way of showing the relationship between these models  is what I call the Software Industry Model Map. Version 1.0 is seen below:

Here is a brief description of each model, including advantages and disadvantages:

Services

This is the simplest business model and has the fewest barriers to entry. You build custom code for clients to do whatever they need. So long as you know how to code and have basic computer equipment, you can be in business. Many boutique web development firms operate this way.

This model is on cash basis: you do the work, tally the hours, then invoice the client. Barring cash flow issues (and deadbeat clients), you usually get paid a few weeks after sending the bill. While the simplicity of this model is appealing, there are several drawbacks:

• Code reuse tends to be lower than other models.
• You tend to get maintenance work, which may dictate the tools you have to use.
• When clients request unpleasant or time-consuming work, you either have to do it or convince them to accept an alternative.
• Cash flows can be irregular, unless you have retainer agreements in place.

Product centered services

This model is usually the logical successor to services (if it isn’t used from the beginning). While it tends to take more planning and investment than pure services, the revenue streams are greater. You also have a specific product you’re familiar with and can reuse to a degree. You can develop this product in house, or you can learn how to extend an existing product. Code reuse and standards are more easily found here than in pure services.

Although the most obvious implementation of this model is with “enterprise solution” businesses, some boutique firms create products to narrow in on niche markets. This model frequently employs significant numbers of non-programmers because the software itself may not represent the bulk of the value added. Despite high revenues, this model has some pitfalls:

• Expenses tend to be high due to the wider array of expertise needed.
• The complexity of services offered can lead to scope creep and unrealistic expectations.
• Clients can still request unpleasant work.
• Unless you’re developing your own product (which is more expensive), the whims of external software authors may hamper plans. Crucial features may disappear along with support for older versions.

Products

Rather than doing custom work for specific clients, it’s far more profitable to build a product and sell it over and over again. The incremental costs of selling more copies of the product are negligible. Aside from providing support, maintenance costs are also close to nil. This results in an extremely high profit margin. When the product is marketed appropriately, the revenue potential is also great. Microsoft, Adobe, and Intuit are companies that have roots in software products. While financial rewards of this model are obvious, it also presents the highest barriers to entry:

• Startup costs are staggering. Millions of dollars can easily be sunk into building a software product before the first sale is ever made.
• Although you do not answer to the daily wishes of individual clients, the features you offer must be flexible enough for the majority of your users to accomplish their tasks.
• Completing a software product does not guarantee that it will sell.
• Software products are environment dependent: it can be difficult to test software under all of the configurations customers will have.
• Bug fixes are distributed slowly and may not be applied correctly.

Products distributed as services

Developing a product is very expensive, but this can be offset early on if you offer the product as a service. The big advantage to using this method is that your customers receive the benefits of code updates instantly; code reuse and profits are inherently high. This method is also the most efficient at leveraging network effects: when people can easily connect through your service, your software becomes more valuable with little extra effort on your part.

Your customers usually don’t need any special environment to use your service, aside from a live connection to it. You have complete control over the code environment. Services also tend to have simpler interfaces or ones that are user defined. Data storage typically occurs on your end, making it trivial for users to change hardware on their end. Google, 37signals, and many other Internet-based services released over the past 5 to 10 years fit this model. Products distributed as services may appear to be very attractive, but they are not without downsides:

• You must maintain the hardware where the code resides as well as network connections. When any of this fails, customers cannot use your service.
• Your code has little or no access to the client’s hardware. Personal computers can easily handle an advanced calculation or data operation for one user, but the same action on your server multiplied by tens of thousands of users at once is not cost effective.
• Revenue levels are lower than those of a pure software product. In exchange for reduced functionality, customers expect your service to be low-cost or advertising supported.
• Although storing data on your server makes it easy for users to change their hardware, they lose control over the data. This is a problem for businesses in sensitive industries or users with security needs.
• Users cannot keep old versions of your software. If you take away or change a feature they rely on, they must wait for you to either add it back or provide an acceptable alternative.

More analysis and examples to come…

In January, my New Year’s resolution was to make more resolutions today: Chinese New Year. Solely because Chinese New Year is more than a month later.

So here goes:

• Go electronic/automatic with as much of my record keeping and business handling as possible. There are a lot of things I could be doing electronically but have still been doing on paper or through the mail. Also, I need to come up with a better system for handling recurring tasks and scheduling. If it comes down to it, I may end up with one of these or these. (sigh)
• Rewrite the Daily Message tutorials, Podcast Suite, iWebCal, and my book to catch up with Joomla! updates. The latter should come out first.
• Validate all of the markup on jlleblanc.com. Last year, I finally got on the whole semantic web bandwagon and haven’t fallen off yet. What was the catalyst for all of this? jQuery. When I saw how it was all CSS selector-based, DOM programming and the benefits of validated markup simultaneously made sense. The pursuit of validation is also helping me maintain Section 508 compliance at work.
• Blog more and worry less about writing essays. When I started blogging, I actually wanted to start a site where I would keep a repository of opinions on specific topics, refined over time. This doesn’t really seem to work as people are much more familiar with off-the-cuff blog posts.
• Incorporate.
• Launch a major web-based service. Oh, so you’d like to know what’s cooking at Chez LeBlanc? You’ll just have to wait and see