Joeflash’s Enigmacopaedia

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

Enterprise level components distinguish themselves from mid-level components in two ways:
a) a robust support and licensing model;
b) a uniqueness or completeness from a technology standpoint.

Enterprise components often have an encryption-based licensing model, phone support, and they don’t automatically give away the source unless you pay a premium for it.

Most times, the enterprise “component” IMO is actually a component set, or self-contained component framework on its own. This aspect on its own may present a little gray area with mid-level components, unless… you combine that with enterprise-level licensing and support. And collecting a bunch of (albeit well-made) components into a “sales package” and marketing it as one item does not an enterprise component make. What enterprise component sets also need to have is uniqueness. Which IMO means that they fulfil enough of a specialized niche that Adobe or some developer is not likely to ever spend the effort to incorporate those specific features into one of its own open source frameworks.

In some cases, mid-level components are unique and build functionality “from the ground up”, i.e. from the base AS3/Flash API, but they still lack reliable support and documentation that would otherwise place them in the enterprise category.

The iLOG Elixir component set is a case in point: it has enterprise licensing, pricing, support, and aside for any partnership agreements between IBM (who now owns them) and Adobe, is specialized enough that Adobe would not waste its time incorporating them into the next version of Flex. Another example might be if the OpenFlux component (framework) were an enterprise component — assuming marketing, licensing and support were present: it builds on the Flex framework classes, yes, but it does things in a radically different way than Flex 3 ever would, because in fact it’s a parallel framework methodology, in that it extends only certain low level Flex classes, and not the finished components. Okay perhaps that is not a terribly good example, since Open Flux was inspired by the pre-alpha spec for Flex 4, which means that it will be obsolesced by Flex 4, and it’s not commercial in any case.

To tell you the truth, apart from the iLOG components, I could not find too many examples of enterprise Flash or Flex component sets out there. And maybe that is because of the FOSS movement in Flash Platform development, maybe it’s just because it’s challenging to create a viable offering solely on these types of components, I’m not sure.

However, there is another kind of enterprise component, belonging to the SAAS category, which on the surface seems to overlap with open source components. For instance, you have components which are more like webservice connectors or extensions on existing open source components — but — they are tied to a proprietary SSAS or server technology, such as the Nitro-LM service, the SalesForce components, or the Ribbit for SalesForce component. The components themselves may even be free, but you’d still have to sign up for the service to be able to use the component. So I am inclined to lump these into the enterprise category.

It is also 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. Apart from superior documentation and support, high performance is the icing on the cake which many IT or senior-level developers are looking for in a serious commercial component, and is one of the primary defining characteristics of an enterprise offering.

The Free and Open Source Software (FOSS) threat

As for the FOSS threat to commercial components, and Adobe competing with commercial offerings by releasing similar features into one its open source frameworks, well, I can see it in some cases, and in other cases, not.

In most scenarios, FOSS is definitely a threat to amateur components, and could very well be to mid-level components as well, simply because many of these components are mashups or extend existing open source frameworks. Enterprise components, by their very definition, are unique and specialized enough that it’s unlikely that they’ll be incorporated into an open source framework, and in the case of SSAS components, are tied to a proprietary technology or service, so they can’t be open sourced or replaced with an open source component, unless someone duplicates or reverse-engineers the service or technology behind the component, which does have a precedent.

Mid-level components which charge enterprise-level prices but which do not provide enterprise level features and/or support is just bad business. The good news about open source competition means that hopefully bad commercial offerings such as these will be improved or fall by the wayside because of it.

But in most cases, I don’t think FOSS is a threat to the enterprise category of commercial components.

The Case of Adobe vs Grant Skinner

However, there’s no guarantee that if a component is considered to be an enterprise offering, that an FOSS offering won’t compete with it. In the case of Squiggly and SPL, many people, myself included until I gave it more thought, think that Adobe is not unfairly competing with Grant for the simple reason that spellchecking is a feature which seems so common sense as to be inevitable as a feature of some open source framework or other, and it just happened to be from Adobe. However, it’s not as simple as that.

On the one hand, SPL builds upon the core Flash API, is a unique product, is built for high performance, has great support, with the enterprise licensing and price tag to match. So it’s definitely an enterprise component in my view — why should some open source framework with no support be unfair competition?

On the other hand, I think this is actually a case of unfair competition by Adobe, principally because Adobe was already licensing SPL in many of its own internal projects. So developing an open source framework with features identical to SPL could be construed as a conflict of interest, a way of Adobe getting out of its licensing agreement with Grant’s company. Even if that was not the starting intent, and it really is a case of the-left-hand-not-knowing-what-the-right-is-doing at Adobe, it’s still a pretty questionable business practice. At the very least, Adobe should have offered Grant the opportunity to contribute to the new open source framework, which would have gone a long way to keeping good relations with Grant’s company. As it is, if I were Grant I would think twice about licensing another product to Adobe using its own technology.
Bad move, Adobe. Throwing up your hands and saying duh, sorry, we didn’t know…
is not nearly good enough, not by far. If you want to foster (or at the very least allow) a viable commercial component ecosystem, you’ll have to do better.