Open Source Unleashed

Sales leads, open source business models and the $100M quandary

The challenge of selling software that is essentially provided without cost is a complex, indeed. Savio Rodrigues and Matt Asay have both posted their thoughts and perspective on a subject that doesn't seem to have a consensus opinion associated with it. Unfortunately (or fortunately), I'm not comfortable attempting to 'clear the air' by expressing something of an authoritative viewpoint. What I am comfortable doing is, examining the varied complexities related to nurturing a business model constructed around open source software. So I'll take a stab at doing just that.

Savio mentioned how the majority of open source software users are "locked into the free price base," which is a well documented reality that isn't about to change overnight. Some might even argue that this free user base is a foundation structure for successful open source and I would have to agree, to a large extent. However, I have to wonder how this affects customer acquisition strategies for commercial open source vendors? Even if an overwhelming majority of customers begin their experience as free users (with a comparatively small number  converting to paying customers), is the transition from free, unpaid user to that of paying customer taken for granted as a natural progression?

In my eyes the motivation for/circumstances behind pursuing a business relationship after engaging an open source community is anything but a natural occurrence. Is it a logical decision? Is there value in doing so? Yes on both accounts. All the same, to consider it a mere consequence of developing good software in the open and distributing it free of cost is a bit naive. For this reason, I have to question the logic behind Matt 's assertion that moving from,

"...isolated, departmental implementations (low dollars) to company-wide deployments (big dollars)...is the natural progression for any successful commercial open-source project."

Matt continues to say that,

"[Invading] the enterprise through free downloads and let[ting] the positive experience percolate throughout an enterprise until the CIO pushes a site-wide license."

This, too, might qualify as a stretch, if not a crass generalization. Yet this is the predominant view of exactly how open source works to win customers and generate revenue. Reality is a bit more complicated than the sort of 'silent penetration' mentioned above. By the time open source has penetrated the enterprise, associated visibility into the evaluation process becomes asymptotic to zero. Follow-ups become next to impossible, and since expiring trial periods are non-existent there are no reliable mechanisms for tracking it. Therefore, as Matt's post attests to, "leads" materialize almost solely based on impetus from the end use spectrum. Which, in a way, takes some of the wind out of the sales process.

These facts are worth considering within the context of debate surrounding the prospect of an open source company reaching the $100 million mark. Reaching that level implies that it's feasible to generate as much revenue with an impaired ability to discern and reach large chunks of an unpaid user base (the most reliable source of potential customers). This ignores the unfortunate reality that software (even open source) is still bought and sold. Yes, proprietary companies are inclined to ramp up sales teams to hawk their products and yes, it is a competitive advantage that open source companies aren't shackled to doing the same, but the $500k+ deals that don't happen by way of traditional engagement [driven by vendor outreach] through a sales team are the minority. Likewise, until the procurement process fully adapts to the realities of open source, relying on technology to sell itself will make the $100 million mark a barrier for most.

Technorati Tags: JBoss |  open source software | business models |  revenue generation

Open source participation as an IT investment

I've attempted to explore the nature of participation within open source communities before. However, I've come away feeling as if I didn't convey exactly how/why actively participating in the open source software development life cycle is valuable. Currently, participation in open source communities is viewed through the narrow lens of perception as more an act of goodwill instead of what it actually is an investment. So while the topic of TCO/ROI for open source software has been dissected, debated and analyzed over and over, the boundaries of creative thought surrounding the notion of an investment in open source have remained static.

The nature of open source software ecosystems is such that the dynamics of contributing or "giving back" takes on added dimensions. Contribution is commonly viewed as somewhat of a nice thing to do in light of "getting the software for free," much the same way that users contribute monetary funds to the producer of free software. However, this perspective stems from a narrow understanding of the governing dynamics of open source software. A donation is rendered out of compassion whereas an investment is made with the expectation of a commensurate return. Contribution to and participation within open source communities should be classified as closer to the latter, even if the resource invested is not monetary. In essence, the same clear-minded cost-benefit mindset that drives commercially driven exchanges should also be at the heart of engaging an open source community, especially within the enterprise.

Yet it's taken for granted that only a minority of total users will ever become active participants within an open source community at one time or another. When the fact is, there is far more to gain from aligning the realities surrounding the specific use of open source and the community behind it than from remaining inactive. Any IT team (large or small) using high quality open source without understanding how/why to interact with the community to influence the roadmap, issue code bounties or sponsor a feature/developer is behind the eight ball. Low/no cost use is only the first layer of benefits to be realized through open source. However, an adept understanding of the other layers prevents the unsustainable and sub-optimal deployment of open source.

Unfortunately, it is the IT budget rather than long-term IT strategy that often provides the window for open source in the enterprise. Too often, once open source has delivered the initial set of lower costs of acquisition the rest of its value proposition is cast aside. At this point the open and transparent ecosystem surrounding quality open source becomes a brand of anonymous, cheap labor. The point is that an implementing enterprise is on the hook to grasp the intersection of the open source model and long range IT strategy. Simply put, IT's focus isn't to be cheaper but to plain and simply support core business objectives better.

The best method of identifying the advantages of membership in community driven technology is to assume an investment-oriented view as opposed to one which is fundamentally risk-oriented. In the same way that when evaluating an investment risk isn't ignored, rather it is accounted for and measured against the potential returns. Likewise, the prospect of contributing to open source communities should also be measured in an objective, judicious manner which reflects the benefits and risks of engaging an open source community. Granted, it helps to have a commercial presence with which to coordinate such activities (Intalio's Demand-Driven-Development is a sterling example of how the costs and risks of product management can be mitigated through collaborative development with a commercial open source vendor) but that's not to say that it remains a hard requirement.

It strikes me as interesting that enterprises are being sold open source primarily on the premise that the availability of source code directly translates into flexibility with little-to-no mention of how the model is capable of generating novel ways of creating and maintaining technology. This is, at once, both a travesty and an invaluable source of opportunity, as the companies which step to exploratory forefront will be the ones that are first to harness the next wave of extreme competitive advantage.

Technorati Tags: IT investments |  open source software | collaborative technology |  Demand Driven Development | Intalio

Tracking the emergence of open source community governance

As a conceptual follow up to my last post, it's relevant to point to a couple of news items which demonstrate how the maturation of open source software is behind the trend towards different varieties of formal methods for representing community sentiment. While it is true that open source is, and always will be, associated with community. And that openness breeds membership/participation, and community is the manifestation of those commonly directed activities, interests and individuals. There are an increasing number of open source efforts which are coming to grips with the reality that while communities form in a mostly autonomous fashion, effective representation of the community must be promoted in deed and done so at a very conscious level.

Grasping the significance of both the finalization of the GlassFish interim governance board as well Novell's kickoff for the openSUSE board of directors requires a better understanding of what community means. From where I stand, community is not only a key differentiator for open source software but also its main asset. By that I mean that the concept of technical communities predates open source and continues to exist outside its domain. However, the open source model represents progress for the notion of integrating shared ownership of IP (in this case, software) into profitable business models. Where, the members/participants of open source communities also double as owners.

For commercial open source vendors, this fact changes the dynamics of what it means to meet the needs of stakeholders. Since customers often begin their open source experience as community members, or at least users, ensuring that the community's needs are being considered is paramount. In the same way that proprietary companies make it a priority to field a competent sales and marketing teams since both serve as the mechanism through which [potential] customers are reached, open source vendors must investigate how well they can discern the pulse of their product communities. And governance boards which include independent community participants are often the best place to start. I'm convinced that while governance strategy is important in its own right, abstract strategy is incomplete without integrating formal community representation.

Oddly enough by representation, I don't mean traditional democracy either (not that I'm against real democratic processes), because even for companies based on the open source model, business decisions should be made by those paid to make them. However, decisions which fail to take into account the needs and perspectives of significant stakeholders within a community are more akin to one-sided rulings. A community (both seen and unseen) is a reflection of your user base and should be handled with care. So affording transparent representation of the community shouldn't come off as a surface deep PR push, i.e. "See we really do care about the community," rather its complexion should be that of a vital link to the double-sided coin of open source success.

Technorati Tags: community governance |  open source software | GlassFish |  openSUSE

Where are all of the community advisory boards?

In retrospect, the launch of Nagios Enterprises is notable not only because of Ethan Galstad's previous stance on a commercial Nagios branch, but also because of the new company's outlined approach to integrating a for-profit entity into its ecosystem. The Nagios community advisory board has been established as a mechanism for giving various community needs and perspectives a platform on the corporate operations side. Consisting of some of the brightest members of the Nagios ecosystem, it stands to counterbalance the fact that the dynamics of a for-profit enterprise are not easily aligned  with a truly open source community. The increasing viability of commercial open source vendors has served to obfuscate the complexities of starting/running a community-driven software company. Hopefully the impression of what it takes to attain open source success won't become [in tongue-in-cheek Slashdot style]:

1. Release code as open source
2. Wait until community gets "popular"
3. Start a company offering services and support
4. ???
5. Profit

In actuality, not every popular/good/sticky open source effort will facilitate a viable business model. Nor should there be the expectation of otherwise. Even if the project has attained significant traction within the enterprise, like Nagios, there is no hard guarantee that there is sufficient momentum to overcome the entry barriers for a commercial operation. The open source model may do well to lube/pry open various entry points but traditional competitive dynamics still hold sway. After all, downloads don't necessarily translate into dollars [before or after starting a company] in the same way that open source economies are bigger than they might appear on the surface.

The fourth step in the facetiously diagrammed chart, above, is actually the most challenging hurdle. It entails walking the thin line drawn between commercial success and community commitment. The path of growing a company while tending to a truly open technology community is long and winding. Navigating it successfully requires that certain priorities be set at the onset and kept in place. Community should never become an obligation, rather it should be held in high regards as a capable source of strategic value. As a result the communication channels between enterprise and community should be remain bi-directional and synchronized on both ends.

That being said, I'm left pondering why community advisory boards aren't yet compulsory to doing business as a commercial open source vendor? Perhaps it seems unnecessary in the face of the popular benevolent dictator model, which espouses top-down yet egalitarian governance, and seems to meet the need of community through a central point of authority. However, one role can't effectively replace input from an entire community, especially one that's thriving. To me, establishing a community advisory board works to grant a brand of legitimacy centered on the fact that open source community is just that, real open source. If/when VC dollars start flowing into an open source enterprise it's crucial to maintain assurance that these words haven't become integrated solely as selling points and/or categorical by-words.

Frankly, every open source company needs to begin to push the concept of a community advisory board of some type. As a more complete understanding of the open source value proposition spreads, I'm gambling that a demonstrated commitment to openness is set to become mandatory. Right now, the criteria gravitates around whether the product/code is freely available under an OSI license, which is a start but one that leaves something to be desired. Eventually, an increasingly open source savvy demand-side will establish that a credible commitment to open source is, in fact, a precursor to purchasing support and services. At which point, the existence of a community advisory board will go miles towards validating the strength of any one open source brand.

Technorati Tags: Nagios |  open source software | community advisory boards | commercial open source

Google, Android/OHA and the Elusive Third Screen

Earlier this week Google found the time to let the air out of one room in the rumor mill by announcing, what most thought would be a single gPhone is actually a platform for building "gPhones" called, Android and the  the Open Handset Alliance (OHA). Despite the expressed pining for another tech-heavyweight to make a splash within the mobile device market, a la Apple, the combination of Android and OHA are actually more ambitious than one phone. The Android team did a colorful yet credible job of breaking down Google's perspective on the subject. My take is that Android (an open source platform for mobile developers) and OHA (an open member alliance) make more sense for Google than a headfirst plunge into the device market even if it has the brand strength to stir up notable buzz surrounding a prospective entry.

Initially I questioned if there is the opportunity for innovation and/or differentiation that would attract a fringe (at best) player like Google? Obviously there is copious room for improving the mobile experience, but is one company going to act as the catalyst? Maybe, but truly kick starting innovation in the mobile device arena won't be a single company's cross to bear. Rather it will fall on the shoulders of an inclusive group of individuals, visionaries, companies and organizations. Hence, the OHA. One point worth considering is the fact that open is well on its way to becoming a buzzword, so the level of transparency in action and approach remains the barometer for OHA's execution of its expressed mission.

Still, Google is slated to play sizable role in the evolution of the U.S. mobile 'third screen' which stands at a unique crossroad in the history of the U.S. cellular industry. Currently there are just as many hurdles to be navigated as there is potential to be realized. Presently, mobile operators continue to function as vanguards over the third screen, blocking badly-needed innovation in defense of outdated telco business models. The result has been far too many closed gardens and an unhealthy obsession with extracting value in place of creating it for the end user. Google has demonstrated that it grasps the implications of this status quo and did well to express interest in facilitating a 700 MHz system adjusted to its specifications. However, pending of the outcome of its planned $4.6 billion bid, Google has yet to fully elucidate its plans to establish traction as a front runner in the race for the third screen.

At this point it remains to be seen how a dose of open source disruption will affect the U.S. mobile ecosystem that's ripe for transformation. Specifically, it's important to understand how Android will fit into Google's strategic outlook for gaining momentum within the mobile industry. I see the follow as particularly critical:

• Add mobile-focus to the Google ecosystem. Android should emerge as the epicenter of the mobile side of Google. The trajectory and time line for the development of a healthy layer of partners and participants, i.e. the OHA, is still an unknown.
  
• Follow the widgets (or gadgets). Google refers to them as gadgets but their overriding characteristic is that they have yet to produce much in the way of. However, what passes for useful functionality as it relates to the traditional browser can be introduced as a significant step forward within the mobile arena. Wherein, the ability to inject behavior to data, encapsulate services and add some extra punch to existing applications is sorely needed.
• An uninterrupted Google brand. Unfortunately the tendency to view the mobile Internet as a discrete entity from the Internet still exists. In reality, they are one and the same. Google must own up to the prospect of seamlessly transmitting its presence to the third screen without relying too heavily on the fixed/mobility differentiation. The Google experience in whatever form it takes (not just search) should be Google regardless of the medium through which it is accessed (within reason).
• Emphasize localization. Just like in real estate, for the mobile world it's Location, Location, Location. The possibilities surrounding mobile communities are exhausting but in order for them to flourish the demand for local information and context must be met. Currently the value of these communities is tied to PC-based access methods. As Android matures I can envision the Google platform extending to include an increasing array of services which aid in this direction.
• Redefine mobile innovation. Unfortunately, the U.S. mobile industry has thus far strangled innovation both intentionally and unintentionally. On the other hand, Android is being billed as a type of innovation accelerator so while I'm high on a focus centered on empowering mobile developers, I like its potential to lower the barriers to innovation even more. The first step of which is enabling developers to impart more flavor to the mobile experience.

I'm looking at whether Google has the wherewithal to channel initial waves of experimentation with Android into the larger cohesive OHA community/ecosystem. Unlike some of the company's other open source efforts, this one can't remain in perpetual beta for an indeterminate period of time. While the sheer scale and ambitious nature of its goals require realistic expectations they also entail a sharper, results oriented approach.

Technorati Tags: Google |  open source software | Android |  Open Handset Alliance | mobile devices | mobile innovation

Mixing it up with a snapshot of the BI stack arena

Last week I received an email asking why I don't do more to mention/compare/contrast proprietary products and companies as it relates to my those of the open source variety. My initial response was laughter considering this blog sports the name Open Source Unleashed as well as the ample coverage of proprietary entities available elsewhere. However, after thinking on it a bit I figured it might be worthwhile to throw in a post or two to break up my open source monotone. Therefore, below is a categorical look at Business Intelligence (BI) vendors (listed in alphabetic order within each category):

Blended Approaches

• HP
• IBM
• Teradata
• Sybase

ERP-centric

• Infor
• Lawson
• Oracle
• SAP

Business Process Solutions (BPS)

• Applix (Cognos)
• Cartesis (Business Objects)
• OutlookSoft (SAP)

Visualization-based

• iDashboards
• Tableau Software
• Visual Mining

Open Source

• JasperSoft
• Pentaho

BPO-based

• Coremetrics
• Omniture

SaaS players

• 1010data
• SeaTab Software

Appliance providers

• DATAllegro
• Greenplum/Sun Netezza

Platform-oriented

• Microsoft
• Oracle

Traditional, pure play BI

• Actuate
• Business Objects
• Cognos
• Information Builders
• MicroStrategy
• SAS

Lightweight BI

• BOARD
• Dimensional Insight
• DSPanel
• FAST Search
• RSinteract
• InetSoft
• InforSense
• LogiXML
• Panorama
• QlikTech

Point solution providers (through acquisition)

• Allen Systems Group
• OpenText

Technorati Tags: business intelligence |  analysis | vendor categorization