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.
There has been some discussion recently as to whether FOSS competes with commercial component offerings, and whether Adobe is unfairly competing with its own developers. Well, the answer is maybe, and maybe. The confusion is partly due to a lack of definition as to what constitutes a commercial Flash component, which lies at the heart of the matter. In the case of Adobe unfairly competed with Grant Skinner, well… read on.
Whether FOSS constitutes competition with commercial components, it all depends on what type of commercial components we are talking about, which is the crux of the matter.
First, let’s define what is not a commercial component. Components developed under no license, or under a FOSS license is not commercial, whether they be pre-compiled SWC-type component, a component with sourcecode, or a component which is really just part of a larger open source library.
Types of Commercial Flash Platform Components
1. Amateur or ‘Throwaway’ Components:
A throwaway component is more of the “Monster Template” or what I derogatorily call “FlashKit”-style components. It’s more of a one-shot use component, often with an incomplete API, sometimes not very great encapsulation, little documentation, no support, and cheap. Great if you’re a beginner-to-intermediate developer and you need a quick fix, but not very useful otherwise. Most times these components should be released open source, if not due to their incompleteness, then because even if it is just a few bucks, often you’re just paying for some-dude’s-experiment. Commercial software needs to be up to certain standards IMO, or it should be free, and even then.
There is no question that FOSS and future Adobe framework offerings will compete with these kinds of components — but did you honestly think anyone would actually pay for them anyways? So they’re not really a factor.
Most of the controversy about competition, either from Adobe or from FOSS, is due to a confusion in the difference between what I call a “mid-level” and an “enterprise” component.
2. Mid-level Components:
A mid-level component, in my view, can be either a mashup widget, in that its innovation or rather uniqueness lies in doing something new in the realm of webservices or connectivity, like a Google Map widget. It is also common for mid-level components to be enhancements or extensions of existing Flex or Flash components, including some media players, because they enhance what an existing component architecture already does, or provides a better version of an existing Adobe or open source component.
There is a big difference between a throwaway and a mid-level component: mid-level components often have a well-crafted API, sound documentation with examples, sometimes even the source is included. And with some of the better companies, responsive help forums, and/or email support is present.
3. Enterprise-level Components