Joeflash’s Enigmacopaedia

There is no doubt: making it as a commercial component maker is a tricky business, what with open source competition on the one hand, and Adobe being possible competition on the other. Now that we’ve defined the kinds of commercial components in the previous post, with these roadblocks, how do you make it in the current commercial ecosystem?

While reviewing recent discussions over at Grant’s blog while writing my previous post, I was reminded of a few things about successful component companies, which I recently discussed in an email conversation with Jeffry Houser over at Flextras about the matter, who encouraged me to blog about some of the points I brought up.

Now keep in mind I’ve never built a business model around making money developing Flash components, so take this part for what it’s worth; however there are a few things I’ve observed over the last decade in the Macromedia/Adobe/Flash industry about successes and failures in this area.

Most commercial Flash component makers start in one of two places:
a) they begin offering mid-level components
b) they have a successful but related business, and offer commercial components to go with their existing proprietary SAAS or server technology.

We won’t even talk about throwaway commercial components, because as I mentioned in the previous post, they should be open sourced anyways.

Starting a commercial component business based solely on mid-level components, as some have done, offers the benefit of relatively little startup capital (basically sweat equity), which gets you up and running very quickly. However, mid-level components can be challenging to hang a business model on, for a few reasons:

a) If they are “extensions,” (i.e. AcmeEnhancedDataGrid) Adobe could, tomorrow if they feel like it, come along and incorporate those ideas into the next version of the framework. In other words, your components may at some point come into conflict with FOSS components of similar functionality.

b) Which means that someone else could also, if they put in the effort, rip off your ideas, at least functionally, and present unwanted, even “illicit” competition, depending on how much they copied you.

c) The lack of phone support and strict licensing means that IT departments, used to spending big bucks to have added functionality at a minimum of fuss, might not regard it/them as serious candidates for an enterprise app, and may not even bother to dig into the API to find out if it has green threading or loose binding functionality.

The founder/business model also has to take into account that building a business around selling components is not all fun and coding. I’ve seen this happen to a few Dreamweaver ext./AJAX/Flash component companies, and similar rule applies here: once your initial offering is released, unless you’ve got a staff of five from the get-go or you’re working crazy 90-hour weeks, you’re going to be spending most of your time on support, because you’ve now released a software product, and you’re now in the software business, like it or not.

Community MX, where I’m a staff writer, used to offer Dreamweaver, AJAX and Flash components years ago. But we found out that by charging for these components, subscribers expected a certain level of support. Which worked fine when the author who worked on them was still writing for us. But as soon as the author was no longer a steady contributor, support questions on the members-only forums would not get answered in a timely fashion, and so eventually we had to discontinue support for all legacy components, and ultimately an informal decision was made not to produce components at all, because we’re in the business of writing tutorials, not software.

You can head off a lot support overload by not actually releasing your new component/product line until full API documentation and tutorials are available. But you’re still going to get John/Jane Clueless who won’t do their homework and/or needs major hand-holding, maybe they’re in over their head and thinks your component is to blame, whatever. (If you’re a commercial component maker I’m sure you’ve experienced your fair share of these requests already). So the solution is, if they want hand-holding-level support, make ‘em pay for it. And even if you have a solid support package, you’re still going to be spending a lot of your time fielding emails & calls. And if that aspect of the business does not appeal, if all you want to do is develop components and not worry about support or marketing, well… maybe you need to look into partnering up with a service or with someone who likes the business aspect of it more. But chances are if you partner with a person or service right off the bat, your business model won’t be self-sustaining.

The one thing that mid-level component offerings have going for it is that it allows you to set up shop fast, get you feet wet, get a name for yourself in the component biz. Many enterprise component offerings have the advantage of having a company behind it whose main business is not selling components, so they can devote some of their sizable resources to creating a few components, as in the case of an SASS like SalesForce.

So if at all possible, the “mid-level component offering” should be an intermediary stage in your business model while you find VC or startup capital. Doing it part time while you wait for the business to be self-sustaining, can be a bit of a chicken-and-the-egg scenario: you will need more staff to be able to offer enterprise-level components, but you can’t hire more staff until the business to be self-sustaining, which would be difficult if all you’re offering is mid-level components, so you need to make enterprise-level components for the business to be self-sustaining, which requires more staff…

If you’re going to stay on as the chief developer and support technician, then you need to find sales and administrative support. If you’re moving into the business end of things, you need to hire developers who can simultaneously develop new component offerings and provide phone support for your customers.

And while we’re on the topic of support, the best software business models I’ve seen, which applies to components as well, are those that offer tiered level support: get the “lite” package, and you get the component, full docs, public forum support, maybe even 48-hour email support. More expensive packages will throw in source code, 1-800 phone support (during business hours at first until you have full-time staff ;), and maybe a few other goodies.

There is a bit of grey area, between mid-level and enterprise components, and herein lies a bit of a danger for component developers. Some components are simply mashups or enhancements of existing Flash or Flex components, but they may also have enterprise-level documentation and support. And unfortunately sometimes, enterprise-level pricing. Remember the golden rule of enterprise components from my previous post: it has to be unique.

From a developer’s standpoint, I think it’s more than okay if a mashup or enhancement component has enterprise features: just don’t charge me thousands of bucks for something that may eventually be released open source (Grant’s SPL excluded ; ). Your AcmeCoAdvancedDataGrid better be pretty freakin awesome and make my coffee in the morning to boot if I’m going to pitch the client into spending thousands for it, lest I look like an ass who can’t code my own components.

Along similar lines, it is assumed that Enterprise components have been battle-tested in the field for optimum performance, so adding them to a huge application will not run up the memory cache and crash their application due to an incompletely formed API. This is the icing on the cake which many IT or senior-level developers are looking for in serious commercial components. Therefore, if you’re going to market at the enterprise level, advertising performance with test results (graphs, etc), would go a long way to getting enterprise customers in my view.

So the main lesson I’m trying to convey with these seemingly random tips are, if you’re going to make it in the Flash Platform component business, eventually you’re going to have to get into enterprise offerings to survive — that or have another revenue stream — or one day someone will pull the rug out from under you, either from an FOSS offering or another competitor. Or worse, you’ll burn out from providing free support.