Open Source Unleashed

OpenSolaris, the evolving nature of openness and its implications

While the hubbub and associated ripples generated by Roy Fiedling's departure from the OpenSolaris community probably had more to do with the fissures in Sun's open source fortress that it supposedly exposed. Since I'm not close enough to the OpenSolaris team to comment on its internal state of affairs I hesitated to weigh in about whether this is a positive or negative indicator for the community and Sun in general. Obviously, the departure of someone with Roy's credentials will be felt, my only question is will Sun seize the opportunity to better establish a governance identity?

Nonetheless, Roy's contention over Sun's approach to open source governance/decision-making doesn't just highlight key issues and challenges tied to the open source software model. Namely the fact that the open in open source should not be confused for a generic identifier that guarantees a finite set of characteristics. As the model matures, it makes sense to expect that the number of differences between disparate open source efforts will only increase positively over time. However, the reality that different evolutionary paths will materialize from the unique forces (internal and external) exerted on individual project communities seems to go unnoticed. In the same light, some of the words commonly used in conjunction with open source will continue to become too broad to leave to interpretation. As an example, Roy pointed out the following:

"What is the point of creating the OpenSolaris Community governance if the community isn’t even allowed to decide what is called OpenSolaris? This isn’t an abstract discussion of trademarks. It is the fundamental basis for making technical decisions of any kind for the project."

It remains difficult to effectively criticize Sun (or anyone else) for choosing the path it has with OpenSolaris so long as the commitment to transparency is a priority. However, from the looks of things a key member of the OpenSolaris Community Advisory Board (CAB) didn't have the same understanding of what open entailed. More than anything else, Roy's departure is symptomatic of critical gaps in communication, whatever the specifics. Such a gap isn't unique to open source and is more often the rule as opposed to the exception when it comes to larger organizations. Unfortunately, open source thrives when external and internal communication is clear and driven by the variety of flattened hierarchies that are typically extinct within those same large corporate organisms...all of which seemed to fall under the CAB charter. 

So it's mildly surprising to learn that the individual tagged as a representative of the general open source community was never made aware that his concept of open decision making differed from Sun's understanding of the same term. If the Sun team never had any intention of granting substantial input into the technical decision making process, that's their choice. Only the company should have taken care to cleanly express the desire to retain control (in general or in regards to specific matters), since the CAB was founded with a perceived air of, not just representation, but also participation in the governance process. There should have been absolutely no motivation to project anything other than the actual outlook on these matters...the definition of transparency.

My perspective is that the open source umbrella has unfolded enough to cover a healthy variety of flavors, colors and combinations (and I don't have any reason to assume this won't continue). So while there is still lively debate about whether certain licenses can be considered open source, other elements associated with a community aren't subject to this type of either/or judgment. Personally, I have no problem applying the open source label to a project that makes its proposition (what it is/isn't as an open source effort) crystal clear and sticks to it. Roy's position seems to be that this is exactly what didn't happen with OpenSolaris.

Obviously the community isn't going to fall apart anytime soon. All the same, it does provide cause to wonder how much of openness is being spun for the purposes of perception management. Hopefully this fallout will incite Sun to assert a cohesive position on how the OpenSolaris community will proceed as a decision making body and continue to demonstrate a commitment to that angle.

Technorati Tags: OpenSolaris |  open source software | community governance |  Sun Microsystems

On Red Hat moving forward

In order to make good on a seven-year goal to capture 50% of middleware deployments for portals, service-oriented architecture (SOA) and application servers and services, Red Hat has been advocating its "Enterprise Acceleration" initiative designed to help enterprise customers shift the center of their middleware universe to architecture based on JBoss Enterprise Middleware (JEM). Half of all enterprise middleware workloads by 2015 is a formidable goal, to say the least. However, Red Hat has pointed to a growing level of dissatisfaction with inflexible/monolithic proprietary middleware as support for this target. The stated strategy focuses on: expanding the JBoss Enterprise Middleware portfolio, stimulating the partner ecosystem, sponsoring new projects in the open source community and introducing new measures to ensure performance and interoperability.

To be realistic, one major caveat in publicizing this brand of far-reaching goal (time-wise) is the fact that, by 2012 very few will remember, let alone hold Red Hat to it. On one hand the quarterly focused, bottom line Wall-Street types could care less what Red Hat says it's going to achieve 94 months from now...short-term profitability, stock price and market share count for more (plus, this safe harbor provides a good deal of legal shelter). On the other hand, any and all viable players in the middleware market will be setting their sights high for 2015...it's a competitive necessity.

Regardless, a closer look gives reason to consider that the enthusiasm exhibited by Red Hat senior leadership and associated week's ambitious goals regarding JEM, might be more than PR wire fluff. Recent activity surrounding JBoss technology indicates that it is, indeed, at the core of a rapidly maturing middleware business for the company. There is also a noticeable fit with the expressed strategic focus associated with the Enterprise Acceleration initiative, serving as early evidence that company direction is indeed aligned with stated objectives in the near-term.

Over the past 6 days, announcements of partnerships with companies like iWay Software, Hyperic and SeeWhy have hit the wire. Obviously the timing was far from coincidental, but it sufficiently backed the commitment to expanding a partner ecosystem that will need to grow by a factor of two or three in the process of meeting the aforementioned Red Hat objectives. Both the iWay and Hyperic partnerships addressed an area that will be critical for the JBoss Enterprise SOA platform moving forward: the budding overlap of enterprise Java and the Web 2.0 generation.

The indelible effect that rich internet applications have had on web-driven application development is practically undeniable. That being said, SOA will encapsulate these realities as it evolves, meaning any and all platforms which claim to tackle this space must do the same. The iWay partnership, in addition to enabling integration with more than 400 databases and applications, strengthens the capability with regards to building rich, Web 2.0-esque apps. The jointly developed management platform project, dubbed RHQ, went live last Thursday led by Red Hat and Hyperic. RHQ will serve as the foundation for JBoss Operations Network v2.0, due in late Spring 2008 and is directed at ensuring that features like inventory, data collection, configuration management control and strong alerting and provisioning is available towards meeting the needs of an increasing array of web-driven enterprises.

Red Hat will benefit tremendously if JEM can mature into one of the key players in the middleware/SOA market, especially in light of the fact that Red Hat Enterprise Linux (RHEL) continues to make headway of its own. As it stands now, Red Hat hasn't been able to effectively cross-sell JEM to as many RHEL customers as was expected by outsiders when JBoss was acquired, despite the fact that those same customers are in the midst of building reference architectures to deliver the applications and services their businesses need. If the gap between JEM and RHEL can be closed without slowing down the latter, the open source enterprise computing stack envisioned by some will be all that much closer to reality. 

The above is particularly interesting since Red Hat's progress as it relates to the above will have a significant impact on how its success story will [continue to??] play out. While the investment community is well already aware that the company has recently experienced a decline in share value, the stock is trading around $18.06 and in highly volatile times, like those today, more than a few will be undervalued. Knowing this, investors will be searching for "bottom feeder" investment opportunities characterized by consistent performance from companies that tend to fly under the radar. If Red Hat can make good by bringing forth the fruits of executing its Enterprise Acceleration strategy the company will develop into an investment opportunity during bearish times. This would arm the company with the ammunition and momentum necessary to seize a leadership position in the tech industry.

Technorati Tags: Red Hat |  open source software | middleware |  JBoss | SOA | Enterprise Acceleration

Sorting out the open source mobile platform space

The recent flurry of activity involving Android and the LiMo Foundation at the 2008 World Mobile Congress represents the increasing level of relevance within and influence on the open source mobile platform space for both efforts. The highly anticipated Android platform and the less hyped but equally apropos LiMo platform have come to represent the intersection of the open source and mobile worlds that is a big part of the marriage of Internet and mobile devices. Open source continues to shape the dynamics of an intersection which has been highlighted by the battle between giants Microsoft and Nokia. The latter of which holds a close to 40% share of the cellphone market and an operating system (majority-owned), Symbian with a 70% clip of that market. The less than 10% of the market for mobile operating systems held by Microsoft pales in comparison to Windows on the desktop that's used on more than 90 percent of PCs. A fragmented Linux takes up 13 percent on the mobile front.

On the open source/Linux front, stated commitments to the Android platform, from parties like Verizon and LG, have followed a ballyhooed inception to the world  and emboldened speculation that Google has more than a passing eye on the mobile advertisement space. The LiMo Foundation, a consortium of 32 companies, also made noise yesterday by showing off 18 handsets powered by its platform following chip makers Texas Instruments and Qualcomm participating in demos for handset prototypes on Monday. Of the aforementioned 18, 15 are commercial while two are reference designs and one is a prototype. The companies involved with LiMo weren't fully comfortable with the ownership structure of the Nokia Series 60 and/or Windows mobile platform(s). The fact that LiMo produces real code and gives companies the opportunity to get involved has served as a key selling point.

Despite its status as a relative newcomer, Android has demonstrated that it intends to be more than Google branded vaporware. Texas Instruments official Ramesh Iyer demonstrated a prototype with Android running atop its flagship, OMAP3430 multimedia applications processor. The claim was that IT was able to p8ut Android on top if its processor in less than a week. Qualcomm validated Android's associated ease of application development by showing off a game developed by engineers in a couple of hours. The hope is that Android will spark a wave of mobile applications from the development community and lead to the next generation of smartphone that combines Web-enabled applications with standard voice features by freeing the power of processors. All by empowering developers to customize applications rapidly.

Thus far, Google has positioned Android as a completed operating system. Whereas the LiMo foundation has been active incorporating components from its member companies in an effort to provide a platform made up of existing, proven components. In this way LiMo is sharing the costs and risks involved with creating a cost-effective platform for all involved parties. Initially both efforts will have to sink or swim in an already fragmented market where primacy depends on device penetration (getting onto a majority of devices)...at the very same conference, Vodafone CEO Arun Sarin called for consolidation in the number of operating systems available.

Meaning while there is definitely room for the Linux category as a whole, Android and the LiMo platform may struggle to exist side-by-side over the long-term, especially since the initiatives overlap  in many ways (see: the number of companies participating in both, including LG Electronics, Motorola and Samsung). As a result, the yet-to-be crowned early leader will be able to push the other effort towards the margins of relevance more quickly than is otherwise the norm. A quick swing in momentum for either side might tip the tides of consolidation for the Linux market in that direction. Therefore, it's critical that both retain as much progress and traction out of the gate as possible.

Technorati Tags: Google |  open source software | LiMo Foundation |  mobile phone platforms | Open Handset Alliance

Apache Synapse graduates

Even if the announcement that Apache Software Foundation (ASF) granted Synapse separate, top-level project billing last week didn't generate major waves of uproar of reaction and commentary, it remains a significant move to the overall state of a burgeoning open source SOA arena. Initially, after first catching wind of Synapse in early spring of last year, I was thrown off slightly by some of the divergent descriptions/understandings of the effort that were floating around the web and as is the case with incubated open source projects it was a rapidly changing code base looking to grow in a more concisely defined direction over time. Since this is normally the case with early stage open source efforts especially those that set out to tackle broad scale areas of competency like SOA, visible progress of this variety being made is encouraging for the future.

As of the current 1.1.1 release, Synapse is positioned as Paul Fremantle, Vice President of Technical Sales at WSO2 Inc. put it "a high performance, easy-to-use, Open Source Enterprise Service Bus (ESB)," an upgrade from the lightweight XML and Web service mediation framework that it was earlier in its existence when it provided three main functions: managing virtualized connections, service management and message transformation. Previously, it was useful for exchanges made through SOAP-based Web services where management of the exchanges were available through the WS-* protocols. Now support has been extended to numerous open standards such as HTTP, SOAP, FTP, SMTP, XML, XSLT, XPath, JMS, Web Services Security (WSS), Web Services Reliable Messaging (WS-RM), and more.

The above helps Synapse cover the key segments of service oriented architectures, namely:

• Execution and integration services provided through interfaces.
• Message routing, transaction, and related services/interfaces used by services.
• Service assembly foundation.
• Management, governance and control capabilities.

Plus, as an ESB the above is offered in a familiar manner that more amenable than the aforementioned mediation framework identity. It was a tad bit strange when the initial explanations of what Synapse brings to the table went, it looks like an ESB, works like one...but isn't quite an ESB. I never figured out whether that was supposed to keep the Yet-Another-ESB tag at arms length while its identity was formalized (through incubation stage) or what? I'll go out on a limb and assume that perhaps ASF noted this distinction to prevent the which one is it...Synapse or ServiceMix conversation from flaming out of control. Yet from what I understand about both, ServiceMix is built atop JBI while Synapse is designed as a simple, high performance ESB that prizes low overhead and scalability minus the JBI foundation.

Either way, now that it's clear that Synapse is in fact an ESB, the challenge for Apache is to cut through this cloud of lingering confusion and carve out space in enterprise application development tool sets. WSO2 stepped forward some eight months ago and ran its own Synapse based ESB against ServiceMix and Mule ESB in two rounds of performance testing, which provided an idea of what Synapse powered platforms can do. Perhaps this should be repeated with direct participation of members from each party (ServiceMix, Mule, Synapse) plus some of the guys from Open ESB? Providing hard evidence that a well-tuned Synapse can stack up to its open source peers tuned similarly for performance might serve as a nice coming out party/current state of affairs for the project.   

Regardless, the driving force behind the Synapse value proposition remains the ASF software development process itself since it's no secret that the ASF is a leading example of leveraging open source in the creation of complex infrastructure. I'm looking ahead for the newly promoted Synapse project to capture more contribution from a wider range of enterprises, vendors and SIs. Even if given the ASF's operating model and the inherently complex nature of a category like SOA, sustained momentum won't hinge on the availability of customer-supportable products. To fill in the gaps, I expect that ISVs and SIs will handle the complex and time consuming tasks associated with integration work. The net result: an Apache Synapse that's well positioned at the forefront of what remains the early stages of SOA technology maturity.

Technorati Tags: Enterprise Service Bus |  open source software | Apache Software Foundation |  Apache Synapse | SOA | enterprise integration

Kepping an eye on the OSGi

SOA World Magazine is running a well-written, informative article authored by Dave Chappell and Khandero Kand, on the Open Services Gateway Initiative (OSGi) that I highly recommend reading especially if you're a Java developer. While the piece is technical in nature it provides critical insight into some of the changes to application development that are gripping the future of middleware. What's particularly compelling about OSGi is the fact that it readily enables a programming model based on some of the core tenets of Service Oriented Architectures (SOA): dynamic flexibility, agility and modularity. Far too often the aforementioned are thrown about carelessly as buzzwords, loosely interpreted to sell a branded product or service. However, in the case of OSGi they are upheld down to the nuts and bolts of enterprise systems, i.e. the construction of software.

As the article points out, the current generation of Java containers is not well suited to support a fully modular SOA pattern. As a result, the prospect of designing and implementing enterprise systems without introducing issues with cross-dependencies, dynamic loading and lifecycle management is certainly complicated. The emergence of an OSGi container is dead set on changing that reality by enabling universal middleware, an ambitious term to say the least, but one that aligns with the expansion of use of the OSGi specification beyond embedded devices. More than just a catchy phrase, the prospect of universal middleware is made real by an intersection between open standards and open source. And if it can build momentum within the context of an increasingly SOA driven world, look for open source middleware to benefit tremendously as a result.

In essence, OSGi is a step towards agile systems of application modules grouped by business functionality available through interface contracts between services. OSGi provides the component-oriented, container framework that is capable of hosting dynamic services that do not have to be registered programmatically while providing the means to track and react to changes in the lifecyle of a service. In anticipation of the realities rooted in dynamic lifecycle problem, the OSGi/Spring combination has emerged as a solution with Spring providing dependency injection and aspect-oriented programming (AOP). Formerly known as Spring OSGi but renamed Spring Dynamic Modules for OSGi, the pattern of extensibility and freeing developer hands/heads to tackle more complex issues that has characterized the growth of Spring since its early days, has taken root in similar ways. Enterprise developers seeking to further simplify application development have taken to this combination, contributing to the significant industry momentum behind OSGi over alternatives like JSR 277.

In a broad sense, OSGi is at the forefront of a movement towards platform agnostic services that are inherently modular in nature. The result? Container independent services that sit above underlying implementations of OSGi. This is another of level of abstraction meant to enable the service based architectures of tomorrow but also an opportunity for the current wave of open source enterprise technologies, i.e. J2EE application servers and ESB frameworks to establish more traction. If OSGi can standardize one approach to SOA from a Java perspective, the doorway for heterogeneous SOA arsenals over single vendor suites will open even more.

Once players like Oracle/BEA and IBM step to the forefront with OSGi containers, the prospect of creating services supported by a standardized, dynamic deployment framework across the nexus of closed and open source offerings will receive a drastic boost. At this point, developers will be afforded the option of writing with the framework instead of against a product-specific approach to enabling SOA...a tantalizingly real opportunity to take a step forward in the Java enterprise application development arena.

Technorati Tags: SOA |  open source software | OSGi |  Spring | middleware | enterprise systems

Springing forward with Tomcat

Perhaps it was the preceding post Sun-MySQL buzz or the tidal wave of speculation surrounding a potential Microsoft-Yahoo merger that served to overshadow last week's SpringSource-Covalent announcement. However, regardless of its "press index," the merger marks not just the joining of forces by two notable players in the open source landscape but also the synthesis of two technologies (Spring and Tomcat) that have played a sizable role in the evolution of enterprise application development over the past three years. While the Spring portfolio has garnered the lion share of consideration as the new face of enterprise Java development, Tomcat has quietly become a staple in the same arena. And as it stands, finding a Java developer who hasn't heard of Tomcat is like, well, finding one who can't tell you what Spring is. A fact that few claimed to dispute, only that Tomcat has historically played the role of a well-kept secret instead of an up-and-comer.

Still, as the Covalent business model bares witness to, Tomcat has also found a home in more than a handful of data centers. Nonetheless, Tomcat is consistently classed for it isn't as opposed to what it is. Thrown into the same category as a JBoss or even a Geronimo (WAS Community Edition), Tomcat is mostly overlooked as a smaller, not feature-poor open source application server, when in reality it was never developed to be an fully-fledged app server. Yet for those, who continue to associate enterprise application infrastructure solely with the traditional application server, Tomcat isn't ready to approach the holy grail of "enterprise-readiness." In light of the presumption that scalability and uptime is gained through hoofing the app server route, it's interesting how easily accepted that reality that Apache httpd powers countless scalable LAMP apps while Tomcat's ability to do the same for Java apps is barely granted a passing murmur. In actuality, Tomcat continues to be used behind a fair share of non-trivial web application. Maybe not to the extent that its ASF brother has, but certainly proportional within the boundaries of the Java web development.

Still companies with products positioned around the Java web container have taken note of how a significant chunk of their service and support business involves Tomcat-driven applications and infrastructures. Enterprise penetration was certainly high enough to warrant the acquisition of the leading support and service provider for Tomcat to be snapped up, not by a threatened giant, but an emerging open source player, like SpringSource. Perhaps this move will pave the way for a more complete top-to-bottom lightweight stack for Java development similar in composition to LAMP...who knows?

So as SpringSource and Covalent  work towards merging operations under one roof, it will be interesting to note the growth curve for Tomcat as a commercially viable commodity...especially with regards to Spring powered applications. I fully expect an ascertainable jump in decisions to standardize on Spring-Tomcat now that services and support subscriptions are available from a single source. Which might not constitute a direct threat to an Oracle or an IBM per se, but is certainly the source of cohesive commercial momentum for open source in the enterprise.

Technorati Tags: Tomcat |  open source software | SpringSource |  SpringSource | Covalent | enterprise Java

Is the MySQL acquisition an open source crystal ball?

Glyn Moody's piece over on the Linux Journal highlighted what is becoming a common suggestion following the MySQL acquisition, i.e. that the purchase of one of the most successful commercial open source companies foreshadows the "fate" for similar outfits. To credit Glyn's perspective, there is a noticeable rash of acquisitions that have begun to characterize the face of "open source success" as of late, each of which has generated a fair share of coverage so there's not much need to rehash details at this point. However, in spite of the tendency to note solely that "big proprietary guys" are buying the "upstart open source kids," consideration of the effects of such mergers and acquisitions should not be limited to a proprietary VS. open source/winner-loser perspective.

Interestingly, the increasing number of corporate divisions composed of formerly independent open source firms speaks more to an industry-wide transition than to the co-opt of one model (open source) by another (proprietary). By that I mean, openness has begun to emerge as a critical feature of software ecosystems that are intent on effectively competing in the marketplace. When coupled with the trend of consolidation that has gripped the entire software industry it has resulted in the buyout of several notable open source companies...a direction that will continue over the next 12-18 months but also one that isn't relegated to the open source space. In fact, Oracle's purchase of BEA does more to validate that this is definitely an industry-wide condensation phase if nothing else.

On a related note Glyn's article briefly mentioned shaken investor confidence in light of recent troubles in world stock markets across the world, but did little to highlight the fact that the public markets in the U.S. aren't exactly a safe bet now that the dreaded "r-word" continues to circle key economic and financial circles. Additionally, since no one is sure how long this economic downturn will last, the prospect of "riding the storm out" isn't as appealing as it might have been 6 to 8 months ago. Along the same lines, as larger, traditional software companies witness the rapidly decreasing degree of sustainability of their closed product portfolios I expect that open source will become complete its transformation from a competitive threat to a feature of overall corporate strategy. And these companies will have to consider the overall costs of instilling openness themselves (a risk-laden prospect) versus snapping it in the M&A markets.

Currently acquisition ranks as the preferred method for adapting to the potential threat/opportunity presented by open source disruption, but it's my perspective that various forms of direct investment in open source ecosystems will out pace a great deal of the acquisition activity by 2010. More companies will recognize the value of aligning with open source efforts outside of looking to buy the commercial operations behind them. This should result in a new wave of partnerships, technology integration agreements and more community involvement by large corporations, one which will strengthen the crop of "surviving" open source vendors.

The bottom line is that the dynamics of industry evolution/change which have shaped open source as an emergent, productive force all operate in conjunction with actions of industry players both large and small. So while recent acquisitions provide great fodder for the blogosphere and news wire, the supposition that they will result in a dying breed of commercial open source vendor is not supported by overarching, industry-wide movements and indicators.

Technorati Tags: MySQL |  open source software | corporate strategy |  M&A | trends and indicators | industry evolution

Meeting the needs of the unpaid on the road to gaining customers

What struck me most about the article on Enterprising Networking Planet about open source support and when you go commercial was the stark distinction made between paying and non-paying user. The article's investigation of the two ends of the market for open source support, namely those who pay for commercial support and those who don't, brings the question of where the two overlap into question. In essence, this proverbial middle ground will drive the next phase of growth for commercial open source support providers. My reasoning is that the needs of both the unpaid and paying user are mostly alike outside the fact that the former chooses to forgo pursuing a commercial relationship with a support vendor. The assumption that those using open source in mission critical/production environments choose to mostly opt for support doesn't hold much water especially when you take a peek at the unique download numbers for most commercially supported products in relation to the number of paying customers.

Yet this mostly anonymous crowd of non-paying users represents the exact source of growth opportunity for commercial support providers. However, engaging them shouldn't be misconstrued as "converting" them to sources of revenue. Instead, it's probably more prudent to actually support them as self-supporting users. This might sound contradictory but it's worth considering that while some non-customers will eventually convert most aren't necessarily in need of being convinced to enter a business relationship. One of the main reasons: a great deal of self-supporting users are already aware of the risks and difficulties associated with forgoing commercial support but have decided to bare the burden anyway. With this in mind it is of little consequence if a support provider offers X, Y, Z in the same way that paying customers aren't inclined to let the prospect of saving money by relinquishing commercial support tip the scales in the other direction.

Nonetheless, as the aforementioned article pointed out, reliability underpins a large majority of the decisions to pursue support...especially in the face of troubleshooting and problem resolution. Obviously, non-paying users face the same issues only they have committed to the path of going it alone, one that isn't easy but still proves rewarding if traversed with care. Interestingly enough, this expression of independence does not imply that there is a absolutely no market for support within this category, only that the market is for a different type of support. It helps to admit that any variety of support contract creates an according dependency on the capabilities of an external vendor, which isn't wholly negative but isn't always preferable within the context of choice afforded by open source.

One of the positives presented by opting for an open source solution is being able to acquire quality software in the process of building associated internal competencies. Oddly enough, the intersection between employing open source and building self-sufficient competency is where support providers should examine how they can evolve into a more relevant entity. Perhaps instead of attempting to become the sole source for upgrades, vulnerability assessment and/or migration, support providers should seek to offer a wider array of flexible support (and licensing) options for those who choose to go it alone? Pricing could resemble something similar like car insurance with payments of a low, flat rate (monthly, quarterly, yearly) for emergency/disaster support. Or maybe even pay-as-you go support (troubleshooting, short-term consultation, etc.) that is billed by the hour. This would afford non-paying parties with the option to pursue just-in-case interactive support that better aligns with a mostly self-sufficient approach.

Obviously these forms of support would be offered at substantially cheaper prices than is customary but they would also appeal to more non-paying users thereby increasing derived revenue from an open source user base. For commercial open source vendors that provide commercial and community versions this might take the form of extending this brand of support for the latter. Either way, it's my perspective that the picture of successful open source in the next 5 years or so will include yet-to-be conceived forms of support options that better meet the needs of the unpaid user.

Technorati Tags: commercial support and services |  open source software | commercial open source business models

Will MySQL prove to be Sun's fifth element?

Nearly three months back I asserted that Sun might benefit from addressing  the fact that its open source portfolio lacks a unifying theme/brand. Today, news that the company is to acquire MySQL for $1bn triggered thoughts on Sun's new position as an evolving open source vendor. Undoubtedly, the financial/organizational impacts will be discussed across the entire blogosphere as well as mainstream outlets. Yet, I've come to a hypothesis that MySQL might be Sun's fifth element. All inconsequential associations to the 1997 production featuring Bruce Willis aside, it's worth noting that the buyout does nothing but boost Sun's position as a leading platform provider for the Web economy in spite of Java taking a back seat to LAMP, Rails, et al. Moreover, with MySQL under its corporate umbrella, the company is in possession of a potential catalyst for the continued emergence its own commercial open source ecosystem.

Here are my thoughts on the acquisition:

• MySQL should help to stimulate the relevance of Sun's tooling and Enterprise Application Infrastructure. Look no further than Oracle for an example of leveraging market share in the database market to cross-sell middleware. On a related note, the company will follow a similar approach with the newly acquired BEA suite that it has with Fusion middleware. Obviously MySQL is no 800-pound gorilla but it's not outlandish to envision GlassFish, OpenSolaris and Netbeans  benefiting from the "cross-germination" opportunities made possible by the presence of MySQL. How and where to transform this into profitable engine for open source success is up to Sun's management to figure out.
• Sun will run with the MySQL and Data Warehousing. In addition to integrating current MySQL solution providers into its sales channel strategy, Sun is better positioned to grow the MySQL Data Warehouse Scale-Out Solution set into a bigger player across the enterprise data center landscape than MySQL was as a standalone entity. I'm looking for the company to make some noise there first.
• How will Sun play the LAMP angle? MySQL puts the M in LAMP, after all. And while Sun has already shown acceptance of the Rich Internet Applications & Web 2.0 "writing on the wall," see jMaki, the clarity/execution of its vision for harmonizing with MySQL's LAMP momentum will determine the which opportunities  present themselves.
• Sun as a capable rival to IBM in the cloud computing arena. Cote made mention of this already and to his point I would add, the availability of MySQL might give its utility computing arm added mainstream appeal for ISVs already invested in the MySQL platform.

Moving forward this move might potentially represent an inflection point in Sun's maturation process as a commercial open source vendor. However, I fully expect the company to go through the growing pains of integrating a smaller, distributed team into a larger, and admittedly more stuffy, big corporate environment, a la Red Hat with JBoss...although perhaps not as pronounced considering the differences between MySQL and JBoss culture. Oddly enough, as the acquisition rumors swirled about MySQL, Sun wasn't on my buyers short list. However, upon announcement they are the vendor for whom the move made the most sense and is best positioned to emerge as a stronger combined entity. We'll see if this continues to prove true down the road...

Technorati Tags: Sun Microsystems |  open source software | MySQL | LAMP | M&A

Open source ecosystems and collaboration as the currency of innovation

Thus far I've been able to resist an annually occurring itch to post a set of predictions for the newly minted year. Unfortunately this means I won't delve into how 2008 is going to somehow lead to the dissolution of the proprietary software development model (I don't see the former ever fully occurring) or why a given open source category/product/company is set to become the next world-beater (if I knew that I probably wouldn't be posting on this blog). However, there is, in fact, a noticeable trend which speaks to the how the maturation of the open source model is only one component of the grander evolution taking place within the entire software industry.

After attempting to portray how open source ecosystems can double as platforms, I think its logical to assert that they also serve as organic collaboration networks. Where the more open, flatter structural composition of these ecosystems creates a hotbed for the brand of collaboration that is required to scale in an increasingly "globalized" world. Interestingly, at the core of the seemingly generic term, collaboration, is the seeds for disruptive innovation. Webster's supplies the following as a definition - something (as a device) created for the first time through the use of the imagination. Yet despite the fact that in today's Information-driven world innovation is no longer entirely pursuant to the physical domain, the term continues to be erroneously coined, misused and cliched more than is worth mentioning.

Nonetheless, open source has proven capable of naturally cultivating the germination of disruptive innovation. Perhaps because full-blooded innovation in this current age is synonymous with openness. Simply put, to innovate is to embrace openness and vice-versa, seeing how innovation mandates a high degree of collaboration across the board. And since the relationship between innovation, collaboration and openness is a topic that warrants a dedicated post, at the least, or a book to be safe, it suffices to suggest that if you're not engaged in dismantling barriers to participation you're probably not innovating very effectively.

Yet even as open source has continues to emerge as a reliable method of integrating the principles of openness into the software development model (and the business of software at a macro level) openness doesn't always (more times than not it doesn't) entail open source. So even if the open source development model, in particular, has yet to satisfy the clamoring for radical creativity exhibited by some this doesn't exactly disprove openness as an innovation accelerator, in general. Still, a cogent analysis of how open source has powered disruptive innovation should consider its affect on:

• Software cost-value models. In addition to enabling more cost-effective software to be created, the primary wave of commercial open source continues to shape the consensus expectation for the cost-value ratio's of the majority of software categories.
• Acquisition mechanisms for enterprise quality software. There are countless examples of how open source has contributed to the divestment of monetary barriers from the process of acquiring software used in production environments.
• Investments in the software development process. Direct investment in open source software communities responsible for projects that are strategically aligned with organizational objectives has become a valid option. In addition to the traditional routes of in-house development, outsourcing, third-party customized development and purchasing COTS.

Most classify the above as "disruption" plain and simple, when in fact, it is also a form of rapid innovation...one that just so happens to shift the very foundation of the current status quo. The downstream effect will give birth to a new class of roles geared to leveraging resulting opportunities. In this light, forward-thinking organizations will take advantage of the option to establish themselves as active participants in the open source productive process as opposed to limited inactive consumers of its output (software assets). More of these companies will consider connecting directly to open source ecosystems, engaging and building value collaboratively with the different members therein. In parallel to this trend, leading open source ecosystems will evolve into bona-fide sources of software innovation made possible by a sense of mutually-beneficially collaboration.

Accordingly, I see the following roles assuming new meaning during the aforementioned transformation of the open source model as a productive process. The shift

• Facilitator - The driving force behind the existence of an open source ecosystem. Could be a commercial company or a not-for-profit organization.
• Adapter/Accelerator - Third parties that serve as a form of technology transformers. They account for the bulk of the customizations and indirect uses of open source software. This category is set to swell as open source becomes the engine for new categories of software and software uses. Examples: system integrators, value added resellers, etc.
• Active Contributor - Organizations embarking upon a continuous cycle of IP contribution to an open source ecosystem.

Deutsche Post's decision to enter a collaborative partnership, involving the Swordfish SOA framework, with the Eclipse Foundation is a prime example of such. In this case, Eclipse is the main Facilitator, Sopera an Adapter/Accelerator and Deutsche Post the Active Contributor...not to insinuate that these roles won't be shared in part by all three parties, either. What stands out most is that this isn't a startup looking to attach to the Eclipse gravy train, rather it is the world's largest German logistics company contributing proven, mature technology that has been running for six years. The code initially contained a framework, a messaging plug-in, a service discovery plug-in and a management plug-in...no small potatoes, at all. Meaning Deutsche Post saw, not only, the opportunity to collaborate with Eclipse in enabling the implementation of OSGi-based service providers and consumers, but also the value of doing so as fully open task under Eclipse governance.

Staying on the Eclipse track, we find Boeing contributing code to OSEE. Where the objective is to create an industry-specific framework with a team of Boeing engineers leading the way. Yet the pattern in clear: business needs being met under an open source umbrella using a Connect-Engage-Build approach. When contrasted with mainstream views that interacting with an open source community is the result of goodwill or the mandate to "give as you take," there is a stark difference. These efforts don't mark the good-hearted nature of Boeing nor Deutsche Post, rather they are working examples of a new twist to the notion of traditional IT investments, led by companies which understand that there's more to gain from accepting an actively productive role in open source ecosystems.

Eventually I fully expect a monetization model to sprout around these activities where all participants begin to embrace and integrate these relationships and roles more closely into their business models. Interestingly enough the barriers are hardly technological, i.e. there is a substantial number of technologies at the center of open source ecosystems, but momentum-based, i.e. how much acceptance is necessary to overcome latent inertia.

Technorati Tags: Boeing |  open source software | open source ecosystems |  Deutsche Post | Eclipse Swordfish | OSEE | IT investments