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
I always wondered if this day would come. Now, hopefully, it just might.
Following is a reply to a post on the Open at Adobe blog entitled Is dead code ever a good line?
If someone cares that the program continues, and is will to commit their resources, why shouldn’t the code be released? If the code is good enough, and doesn’t include other properties, why not release it? If a community is available to control and govern it, why not? If the product was good enough to build a market on its own right, why should we believe it can’t continue?
So, to both of my readers
, what do you think? Should dead code be released? Are there examples of it working, or failing? And what do you think are the steps that would help us decide?
I knew exactly what I would write. The same thing that’s been on my mind since I started doing serious actionscript development back in 2002, and the one reason I switched to being a Flex developer:
“I think the answer is hell yes, particularly in Adobe’s case.
I’m going to take a moment and gripe about a typical situation which underscores the importance of this point.
I can think of a few situations in the past where open sourcing the code for the Macromedia Flash v2 (i.e. MX 2004) components would have saved a lot of developers, including myself, from a lot of pain and grief. The fact that Macromedia had abandoned the v2 component code back in 2005 (maybe earlier?), and yet would not open source it, left the Flash development community with little alternative than to use 3rd party component frameworks, because patching up holes in the component framework was simply not a legal option. I remember back when the v2 components were released, a few bright stars in the community found fixes and patches for them, but were unable to distribute this code because of the closed policies surrounding these components. This made a lot of people extremely unhappy.
None of the alternate component sets were satisfactory, because none of them were as complete or feature-rich as the v2 component set. And so we waited for someone, anyone to step up to the plate. We waited for MCOM to complete its vaunted component set, which would supposedly save us all from the bugginess of the v2 architecture. But by the time they were released, Flex 2 and AS3 was just around the corner — why bother?
I say this not to gripe for the sake of it, the past is the past, but to emphasize that Adobe should never, ever, EVER repeat this mistake ever again. This one goof nearly killed component-based development for the Flash Platform back in the day, only to be saved at the 11th hour by Flex 2 and AS3. So obviously
MacromediaAdobe has learned since then.
Many of us cheered a massive hurah when Adobe announced plans to open source the Flex SDK. Alas, we were now saved from a fate worse than death by having to use closed source components. To the Flash developers in the trenches, the ones who sweat blood and tears to make Flash live up to its potential, we are glad not to have to hack our way through closed code with a chainsaw just to build good apps. Thank you for opening up, and later open sourcing the Flex SDK.
But lot of developers working with legacy AS2 code are still not happy. I’ve even seen development teams violating the EULA and decompiling the entire component architecture, just so they can fix a few things and put out a stable version of their application. So it would be a bit of an understatement to say that it would be a saving grace for them, or if nothing else offer some sort of closure on the issue for the rest of us who have moved on, if the
MacromediaAdobe Flash v2 component set were open sourced, at long last. Better late than never.
And while you’re at it, Flex 1 & 1.5 and all the cool MM Dev Kit components that rarely saw the light of day outside of Flex 1-land.
Adobe, if you really want to embrace the open source movement, you need to do this, for your loyal community of Flash developers who have stood by the technology through the years and helped nurture it to what it is today.
A plea from a passionate Flash and Flex Developer.“
Everyone who feels the same way that I do, lend your voice here or on the Open at Adobe blog, and maybe we can finally get that train into the station at long last.