I don't know how I overlooked this article in InfoWorld last month about open source in France but it is an interesting read. My only qualm was that the article should have taken regional realities into account, i.e. North American. Instead it focused solely on the U.S. when bringing Canada into the picture might have shed additional light on the points made. Nonetheless, facts are facts and France headlines a Europe that as of today, is light years ahead of the U.S. in terms of a general openness to open source adoption at a national level. Why is this? In my experience interacting with a number players (vendors, third party integrators, customers) on both sides of the Atlantic, there are several factors at play:

More comfort closer to the cutting edge. Initial success with open source leads to more
mission-critical investments faster in Europe. For example, from an operations perspective, I've noted less apprehension related to making major migrations to open source platforms like Linux. While the use of leading open source development
tools such as Eclipse and Subversion, is roughly the same, adoption
of open source testing tools such as Selenium, FIT/FitNesse, and soapUI is higher and closer to leading edge in [Western] Europe.

More interest in making strategic investments. In the US, widespread momentum to continue to push further exploitation of the opportunities afforded by the open source movement has yet to take hold across the board. As an example, I see the current level of
interest in using open source technologies in the infrastructure layer
for application services and data services, e.g. business intelligence (BI) and enterprise service bus (ESB)
capabilities, as being dwarfed by the quality of options available.

Progress is prized similarly to "readiness." I was able to contact one enterprise architect from a fairly large IT shop in France who described an
enterprise-wide initiative at his company to bring a full
stack of open source software to user desktops. He was adamant that the program's progress
has been slow and rife with challenges associated with migrating users and installations from existing
Microsoft productivity tools to open source alternatives. And no, the company doesn't think that Microsoft is going anywhere anytime soon. They are just aware of the benefits (and savings) to be realized by taking a long term approach to opening their desktops.

Still, any subject related to cultural and political differences is never so easily transcribed that a single article or blog post can do it justice. So while there is a certain comfort in the fact that source code and application binaries transcend national boundaries and cultures with
relative ease, the reality is far less objective. There are few absolutes with regards to even technology adoption. And the following should be considered:

Regions prove more diverse than general trends. For those who've noticed, [North] American decision-makers tend to remain more concerned about the
potential downsides of open source than their European counterparts, but this doesn't qualify as grounds to fully quantify adoption.

Open source adoption remains a nebulous term. Quantifying use of a fully open source project is still more art than science. As a result, we've yet to reach a point where fully reliable usage rates can be produced...especially for entire regions.

Worldwide consumption still exceeds participation. Organizations worldwide have yet to realize the benefits to be gained by contributing to vibrant open source ecosystems. This consumer-focused stance is typical of most large IT organizations. In short companies, across the world are still focused
primarily on consuming open source and maybe
establishing dedicated internal support teams. I eagerly await the day this changes.

What can be taken from the article is that the French, from a national level down, have demonstrated very high levels of open source acceptance. That doesn't mean that the French sell the most open source products or can boast the most open source companies. Neither does it mean that France is suddenly the pre-eminent hotspot for open source activity across the globe. It simply means that the country has set an example for others to follow in its footsteps.

After reading Matthew Aslett's followup to Matt Asay's original entry on the problem with open source revenue models, I started churning my wheels upstairs. And while I won't offer a futuristic view of what open source revenue models will look like in 20** or beyond it is obvious to me that their evolution shouldn't be held to expectations set by a proprietary software world view. Still, it strikes me as odd that the boundaries of thought surrounding the open source world don't seem to reflect the stark differences between the nature of the business and software development models employed within the two domains.

It's my perspective that the assumptions and guiding thought patterns garnered from the business of [proprietary] software are too inflexible to hold across the board for open source. The debate over revenue models is a perfect example. As I see it, sustained open source growth will not occur by mirroring what works for the Microsoft's and Oracle's of the world. Instead, open source success will, more than likely, be defined by how closely revenue models are to the realities of 1000's of companies like this one. So while we can recognize that it's the ReadyTechs of the world which represent the bulk of open source consumption by companies, questions about where monetization fits in are still outstanding.

As a result, open source vendors will become responsible for monetizing channels that connect them to the many companies who've built businesses around open source. Which, to be clear, is entirely different from pushing cheaper (and presumably open) products through the same channels fit with minor tweaks to service and support offerings. Reaching companies that have fully bought and invested in open source is the next step those vendors serious about continued growth. Along those lines, one of the main challenges surrounds constructing revenue streams which are composed of such entities. And typically, the thought has been that businesses don't always need to become customers in order to benefit from open source. Which is true, but isn't a blanket statement. Yes, for those organizations looking to cut IT costs, nothing beats a free product.

However, there are still a significant number of gaps associated with building around community supported open source. Gaps which represent pain points for the companies that choose to forgo purchasing traditional service and support contracts. The dominant mode of thought is that the drop off between free and supported use is endemic to the open source experience, yet I view them it as an opportunity to expand the notion of service and support delivery. If this sounds abstract, picture vendors supporting self-support through highly cost effective, flex "contracts" which would cover the middle ground between going it alone and purchasing the 24/7-type support which can prove to be overkill. Or maybe, vendors could offer the option of a pay-to-join shared space in which to exchange success stories, best practices, successful deployment projects and
architectures for community editions.

Whatever the case, the open source revenue models which plan to thrive had better evolve to create a bigger monetization overlap with their user base. Will this require innovation? Of course. Perhaps even radical (comparatively) forms of service and support delivery. However, all of it should be done within the context of preparing to capitalize on the next wave of open source disruption...instead of being crushed by it.

Here are some interesting tidbits of open source news/updates from the past week or so:

Red Hat Digital Keys Violated by Intruder - Security. Vulnerabilities in operating systems are nothing new. But let's be real for a second, when it occurs at an open source vendor like Red Hat the underlying assumption is that open = vulnerable. Still, this incident does bring into question the issue of certification as it relates to distribution of open source. I mean, if I download Fedora from Mirror #5 located in Country X, how sure am I that Red Hat, the assumed originator of the binary/source code in question, vouches for the contents of that package at that particular time?

Does the market really want open options for cloud computing? I tend towards the perspective that open standards/open source sounds like it has more overlap with cloud computing than it actually does, at the current moment. I'm not particularly sure at this stage in the life of cloud computing that there is enough differentiation between a proprietary and open source cloud to drive preference for either. In essence, I think the market is still sorting out exactly what the cloud is about.

Can Dell capture emerging markets with simplified PCs? I've got to wonder what cultural barriers might play a bigger role in determining if Dell can capture emerging markets. After all, price is only one determinant of success in capturing emerging Asian, African and Latin American nations. The article mentions computing needs, which I think is an apt term on account of the inherent diversity across the different nations in those regions. If the millions of "consumers" who compose these places are simply lumped into the emerging nations category from a strategy perspective, I feel like the results will suffer.

Where will JavaFX lead? The question shouldn't be does Sun have a shot in the mobile arena but how will it fit into the picture. How a mobile app space, one that has yet to mature to the point where bona-fide structural characteristics are evident, does not have room for another player is beyond me. That being said, it's also not clear exactly what JavaFX will bring to the table as an Rich Internet Application (RIA) enabler. Granted, the alignment between Java and JavaFX is a great for Java developers who have been left out of the RIA picture while Adobe, Microsoft and AJAX have provided their developers with capable tool sets. However, the JavaFX development kit simply needs to get out there and assert itself as an option before it's place is clear.

What is Spacewalk? A summary of what the open source (GPLv2) Linux systems management solution allows you to do might go as follows:

A corollary to the explosion of open source within the enterprise is it's evolution as an objective. In that light, open source has evolved from remote unknown/curiosity into somewhat of a key IT objective. Still, as I see it, open source continues as a tactical concern instead of a strategic one. By that I mean, it remains a means to achieving strategic IT initiatives such as building service-oriented-architectures (SOA), bringing enterprise collaboration into play or introducing web 2.0. A reality which isn't necessarily bad/good...only indicative of an actual state of affairs.

Listed below are just some of the strategic IT initiatives that open source, as a tactical measure, fuels:

Web 2.0. Dynamic languages (PHP, Python, and Ruby) along with various opensource Ajax frameworks and tools from players such as Adobe and Laszlo Systems all contribute to

Service-oriented architecture. Opensource
ESBs: Mule, OpenESB, and JBoss ESB help beat a path to SOA but are also supplemented by other enabling technologies including
Axis, ServiceMix and Synapse.

Moving forward, I can visualize open source emerging as a strategic interest similar to, while also remaining a tactical driver for, the aforementioned. This as firms realize the inevitability of embracing open models of interaction and the enterprise software model matures to better accommodate open styles of software development. When this occurs we'll witness more participation by organizations in open source communities, more innovative forms of internal self-support as well as bridges to and from platforms like Microsoft's .NET or SAP's ABAP. The latter as both giants also come to a better understanding of where open source fits into their respective futures.

However, before this takes place there must be more awareness of the
open source that is being used on both sides of the equation. For all
of the Java based shops out there, I'd be willing to guess that the majority employ at least some open source.
And I'd also venture to guess that very few know just how much. Since
being aware of its presence will assist in effectively leveraging a
larger scope of opensource
software, it's critical for this to change. The same goes for those
companies dealing with suppliers...how many retain disclosure from
suppliers regarding the amount of open source that is being used in
commercial products? Very few, most likely. This variety of information
might not seem relevant but is actually useful within the context of
determining the value received in exchange for commercial licenses.

Yet the question of exactly how this transition from tactical to strategic will take place, remains. From my perspective, the increased presence of open source as a tactical mandate of sorts will drive the need for stronger open source governance. Which will further implicate closer alignment of overarching IT strategies with the open source domain. Currently, this link is missing and open source fails to remain relevant from a planning or strategic perspective. All despite the fact that there is definite value to be realized through open source on both fronts. The key will be for organizations to grasp that open source can, in fact, serve as a business accelerator.

Since it seems as though questions, which two to three years back centered around whether open source is here to stay, are now focused on what's next for the open source adoption wave. While there are certainly differences that exist cross-industry, there are a number of absolute realities that will govern how fast/solidly open source continues up the application stack.

As adoption strategies mature and more open source products prove to be production quality, I expect further saturation and increased penetration along the lower (categories 1,2 and parts of 3 below) and higher parts (pieces of category 3 and 4) of the application stack, respectively. However, I also expect that the penetration rates for this "upper echelon" of the application stack will be exponentially lower in comparison. For one, I have a hard time seeing how the JBoss model (lower cost, open source disruption) will be duplicated in this phase of open source growth...if only for the simple fact that the technologies involved traditionally take shape as horizontal/industry specific solutions. So commoditization won't play as much a factor as it did lower down the stack.

Open source continues to emerge as a strategic play. As awareness regarding open source shifts, the interest level in how to further exploit it as a competitive advantage has also grown. This coincides with higher levels of interest in using open source technologies for application and data services (see category 3 above). Something which bodes well for open source BI, ESB and portal players.

Lower costs will continue as a main driver. There's no need to expound about this one. So while cheaper doesn't always equal better, cheaper + same level of quality = more value.

Open source consumption (by enterprises) will dwarf production. A number of individuals, including myself, have voiced the value that contribution has within the context of an open source ecosystem. Unfortunately, I don't see the typical consumer-focused stance of organizations changing drastically in the near term.

The desktop remains its own domain. At best I feel that the first significant wave of open source enterprise desktop initiatives are at least 3 to 5 years away. The challenges in this domain center around bringing a full stack of software that will run on user desktops. Additionally, the prospect of migrating users and installations from existing Microsoft productivity tools to open source alternatives remains overtly daunting. So while a number of local and central public authorities across EMEA are open to national and EU objectives which call for increased use of open source in requests for proposal (RFPs). I'm not sure if the open source desktop will experience any residual effects of increased adoption levels within the other categories listed above.

Nonetheless, even as open source moves up the stack, the most challenging aspect of open source adoption is not technical. Simply put, it is the shift that it brings to the enterprise software business model. As concerns about security, intellectual property and support continue to keep a more sustained progression up the application stack at bay. Since at the end of the day, clean code compiles don't overrule the fact that technology adoption is swayed by political and even cultural concerns.

As enterprises look to scale support for a mounting number of applications, I expect that Database-as-a-service (DaaS) options will emerge from the recently nascent cloud computing infrastructures. Already, we're seeing the usual cast of suspects targeting the DaaS arena including: Amazon, Google, IBM, Oracle and Salesforce.com. While smaller vendors like EnterpriseDB, Elastra and LongJump are also in the mix. In instances where traditional processes for database management and deployment are challenged by the need to scale more rapidly in a cost-effective manner, DaaS will prove attractive.

In general, DaaS can be defined as technology that provides a database on demand at lower costs. Basically, a database offered through the cloud on a pay-as-you-go basis. By providing demand driven access to data storage via standard like REST and SOAP, I can picture DaaS evolving into the entry point for enterprises wishing to migrate to larger cloud-based infrastructures. In parallel, open source database vendors are faced with the opportunity and threat represented by this model. Why both? Well, DaaS use cases overlap with those of the current wave of open source databases. However, the DaaS model also represents somewhat of a natural transition for open source database vendors to extend service portfolio. Currently, the gaps met by open source will begin to be met by a new generation DaaS offerings.

Application development and testing. Developers often face a lack of database resources as they seek to thoroughly test applications. In many of these instances open source databases have become the defacto option that enables developers to grab a database and perform functional testing without minimal stress. DaaS has the potential to offer on-demand database resources that reduces the hassle and cost associated with an on-site database.

Web 2.0 offshoots. The notion of departmental collaboration has greatly benefited from Web 2.0 apps that speed the sharing of data, ideas and information. While email is still the primary collaborative tool of choice, newer Web 2.0 offshoots are making headway. Developing these types of applications will become even more feasible with the availability of a lightweight manner of storing and accessing data from a centralized location, that DaaS represents.

Data archives. In the majority of cases, only 20% of production is consistently accessed. The other 80% of data is mainly used as fuel for historical reporting and compliance efforts. Open source databases continue to provide a low cost alternative to tape, one which scales better in terms of scan and retrieval. DaaS will do the same.

SMB applications. With application requirements that mirror those of larger organizations minus the IT budget, resources or physical infrastructure, this has been touted as a natural fit for open source. Still, the SMB marketplace hasn't quite proven to be the promised land for open source vendors in general. Plus there is an opportunity for software-as-a-service (SaaS) vendors who are already dead set on further penetrating this market, to offer DaaS within the context of hosting not just data but also application development tools for building smaller apps.

In that light, open source database vendors might find their sweet spot in the marketplace encumbered by any number of DaaS alternatives from a host of players both large and small. The size of the DaaS market is anyone's guess/IDC's job to predict so it remains difficult to project what type of effect this might have on the open source database market itself.

However, to determine the trajectory of and effect upon open source I'm looking for EnterpriseDB and Sun as key indicators. The former will make a play with its Postgres Plus Advanced Server Cloud edition offered through Amazon's Elastic Compute Cloud (EC2) and Simple Storage Services (S3). All of which amounts to a full-featured, dedicated hosted relational database which can be setup, maintained, backed up and monitored through a web based graphical interface. The Sun-MySQL offering should shape into a serious contender as Sun has been somewhat of a pioneer with the Infrastructure-as-a-Service model (use of Sun servers and storage at $1/CPU per hour). On that note, it wouldn't surprise me to see Sun yank the MySQL DaaS offering on the Amazon EC2 cloud as it ramps up a more comprehensive offering in the near future.

Still, there are key shortcomings that the DaaS model must address, namely: security, response time for data access/update, and integration with existing applications/platforms. And it remains to be seen whether DaaS providers can scale the way their SaaS cousins have proven capable of. Will the model ever take hold as anything more than an add-on for database vendors? Only time will tell, but one thing's for sure: the evolution of DaaS will definitely leave its mark on the open source database landscape.

Last week I got an email from Paul Breach over at IBPhoenix who was kind enough to supply some comments about my post on the database market. Paul stated that,

Its true that there is no single cohesive face for Firebird, and this is a situation I have tried to rectify a couple of times, unfortunately that issue is part of how Firebird was born. As an
abandoned child of a failed open source attempt by Borland. Because of this no single company "owned" the code, so we had to rely on volunteers to get the project going.

Now the project is run by a project admin team, consisting of those who
are most active within the project - "true democracy" :-). The project is financed by the Firebird Foundation and a company called IBPhoenix. IBPhoenix was a company I started at the time when Firebird was open sourced.

So there is a company behind Firebird that offers professional support, training etc etc and the people who work for it are all actively involved in the project in various ways. I for example look after porting to MacOSX, Solaris and HPUX, we are also responsible for the windows builds, release notes and QA.

So should anybody argue that we cannot offer fully supported production deployments, then I would argue that they were wrong.

I decided to post these comments because they help portray a key dilemma facing a number of open source projects that have managed to stick around and establish a respectable level of critical mass. For example, Paul mentions the circumstances under which Firebird was formed and came of age, i.e. how the project was volunteer driven after being abandoned by Borland. The result: an egalitarian-centric project that doesn't rely on an individual face to represent it.

Decidedly, this form of "true democracy" continues to work well for the project. However, it also creates the false perception (in the minds of outsiders) that the project lacks clear and decisive leadership. Maybe I should have rephrased my initial comments on it by saying that the project continues to appear as if it lacks a cohesive face and/or supporting vendor. Obviously this isn't the case (as Paul pointed out), but in the absence of something that essentially "represents" the technology, it becomes the default assumption. At the end of the day it's rarely a negative when a person and/or identifiable company culture is associated with a product. After all, they can serve as integral aspects of any brand.

If anything, the Firebird community, like so many others in the general open source community, will benefit from painting a clearer picture of its structure. Why? Because a stronger link between Firebird => Firebird Foundation => IBPhoenix immediately dispels the notion of a not quite viable database floating around in the atmosphere. For those who won't ever experience a hands-on use of the database this does count for something. The effect that expressing that there is more than one group of people involved/interested in an effort can be quite powerful. In fact, it can add a layer of instant credibility just like that.

My take on what Paul expressed to me is that, part of the equation involves understanding that a project like Firebird should be gauged differently...especially considering the non-traditional model it employs. And honestly, the fact that it may not register on most folks' radar does not directly qualify as a weakness. So while I still believe the project has tremendous room to grow, for all intensive purposes it still exhibits most of the core elements of open source success.

As a precursor to OSCON this week, Forrester stepped forward with a new report titled "Market Update: Open Source Databases," one that tags the current market for open source database market at $850 million, with growth to $1.2 billion by 2010. I haven't seen the entire report but I did get around to reading the excerpt available on Forrester's web site. I'd sum up my thoughts on the future of open source databases by saying that they will continue as a tool of choice for applications that are ants in comparisons to the sledgehammers of the database world (Oracle, IBM). Obviously, Sun's strategic vision for MySQL will play no small part in this picture. However, open source databases will fuel a great deal of the innovation that has yet to surface (think cloud computing, corporate Web 2.0 and improved forms of content management).

New types of applications that have yet to breach mainstream are already being developed atop open source databases. We saw this with MySQL and web applications and we'll continue to see a similar relationship develop between open source databases and application developers who sit closer to the cutting edge. Additionally, I'm looking for more and more consulting houses to begin offering implementation services for open source databases as the demand for newer types of solutions emerges. Still, it will remain difficult to determine just how big the pond is for open source databases since they will continue to power a great deal of applications in anonymity.

I also fully expect that open source database vendors will begin to better harmonize the potential of their communities with business models. As it stands, the open source community is the place to go for support with non-production deployments. And there are more effective ways to align this with the delivery of 24x7 premium support. Tiered layers of support patrons could emerge as a monetization vehicle that serves user who don't want to sign up for the traditional support contract but want a fast track for feedback to questions and issue resolution.

I've got the feeling that we'll also witness the emergence of Ingres as a more noted player in this segment. In the past, it has lacked the visibility of a MySQL or PostgreSQL/EnterpriseDB. However, since splitting from CA two years back, it has continued to build out a comprehensive set of database features. Still, the company needs to figure out how to gain back the implicit sense of credibility that being associated with CA brought it amongst the enterprise crowd.

Along the same lines I see Firebird retaining its occult-esque status with a subsection of developers who recognize its value as solid technology. At the current moment, Firebird lacks a cohesive face and/or supporting vendor so it continues to fly under the radar despite its relative strengths. It won't be able to establish enough penetration outside the developer community until the prospect of fully supported production deployments becomes a reality. Then again, I'm not so sure that's the ultimate goal of the project.

Now that MySQL has decided to ready the final Release Candidate (RC) for version 5.1 instead of moving forward with a General Availability (GA) release and Michael Widenius has extended an bug filing call to its user community. I've been thinking about where MySQL stands as an official 5.1 release has been pushed back. For all it's dominance as the glue for LAMP stacks and engine for Web 2.0 infrastructure, my thoughts on MySQL have little to do with Sun's $1B acquisition or whether it can topple Oracle DB. Rather, they're focused on core realities associated with the product itself. Namely:

For those who remember, MySQL 4 left a bad taste in the mouth of more than a few. Not that anyone expected it to be perfect but the lack of so called "advanced" features like triggers, sprocs, udf's were a turnoff. To this day there is a healthy segment of PostgreSQL users that swear MySQL is an amoeba in comparison, and most base this assertion on having used MySQL 4...seriously. A lot of this is understandable, version 4 lacked support for things like nested SELECT's so it's to be expected that some folks' experience was less than ideal. Unfortunately, those who fled MySQL before the 5.0 was available missed out on some notable additions, including syntax changes that moved it closer to ANSI standards.

The 5.1 GA will be the first widely available release with native XML functions. I'm waiting to see if there's any indexing support behind all the xPath.

MySQL has consistently trumped PostgreSQL with it's ease of install, maintenance, and lower levels of complexity. Still, MySQL lacks what some would call the basic ability to store a timestamps with greater than a second accuracy. In the operational world a database that can't do that would be considered a step away from Access. At least milliseconds are required and microseconds are preferred. Note: MySQL currently recommends stripping the sub-second information from the time sent, storing it in another column, then implementing a view which combines them back. However, for functionality that classed as basic this comes across as overkill...especially when the database's calling card is simplicity.

Apparently, before being bought by Sun, MySQL AB were already contemplating making the move to more proprietary tools. From what I've been told, it was agreed that this was a natural progression that would enable them to monetize pieces of the pie. Talks were set in motion and the decision was left on the table...then Sun purchased them. After the acquisition, Sun didn't see the need to/benefit in proceeding down that path in the near term but took heat as some fingered them as the original source of the idea.

At the end of the day, the delay of version 5.1 GA will afford us with a look at what the priorities for Sun's adopted open source child are at this point. The state in which 5.1 hits the ground running will reflect how Sun intends to position MySQL moving forward. My hunch is that we'll witness longer gaps between releases as more focus is paid to QA, testing, certification and feature stability than in the past.

Lately, facing the prospect of picking up blogging after some significant time away from it, I've been pondering the topic of inertia. Most are already familiar with the term, but underestimate how this fundamental principle is applicable outside classical physics...even when examining the topic of attitudes towards open source in the year 2008.

For those who've witnessed the growth of open source from fringe movement to full-fledged force, it goes unnoticed that most decision makers continue to harbor woefully outdated ideas and perceptions about open source software. Part of this might sound absurd at first, so to better illustrate my point here are some categories of interest as my experiences have revealed to me:

Totally unaware - Have never heard of open source (a fringe minority).

Not interested - Have heard but not motivated to even consider it.

Interested but inactively so - Might read, discuss or even inquire but nothing further.

Leaning towards exploring - Actively informed and interested but still several steps away from a pilot.

Actively exploring - Already piloting.

Adopters - Been there done that.

I suffices to say that categories 2 and 3 claim the vast majority of the enterprise crowd. Part of it is that within the modern enterprise (especially larger ones) higher degree novelty = higher degree of risk. So while time might be the absolute test for all things (over the long haul) it's still safer to fall within accepted boundaries (in the short term). Meaning open source isn't just competing on grounds of functionality, price and "value" but also against organizational inertia. The patterns, habits and assumptions built atop years of playing in closed gardens is a strong force, to say the least. Even as open source has proven itself "good enough" where it matters most, these ingrained habits and viewpoints represent another hurdle.

To overcome this, open source must represent enough gain to soften widely-held doubts about the model itself. Once again, these concerns might sound a bit 2003-ish but are still relevant today in 2008.

Security of the software - The association with open code bases and vulnerability still exists.

Availability of service and support - A great deal of open source packages don't have a supporting organization behind it...nor should they.

TCO - Not just monetary costs but those resource and knowledge based.

Legal issues - Self explanatory

Viability of the open source communities - Can communities be counted on to deliver consistently? Will open, collaborative software development model stand the test of time?

Complexity of adoption/learning curve - What exactly does it take to establish tailored policies, governance, etc.?

Product maturity - The one concern that will gradually dwindle based solely on the passing of time.

Where the above have been shown to be addressed, open source has flourished (commercially and otherwise). Where one or more of these doubts linger, growth has been substantially slower and/or sporadic. Unfortunately, the inactive passing of time during which open source "sticks around" does not guarantee that the above will be proven moot. Neither does the financial viability of individual open source vendors. It will take a concerted effort to continue to push the open source model with the objective of chipping away at some of the misplaced concerns that linger.