Larry Augustin Angel investor and advisor to early stage technology companies.
Jeff Waugh Passionate about the philosophy of Software Freedom and the business of Open Source.
Ismael Ghalimi Founder and CEO of Intalio, creator of BPMI.org and initiator of Office 2.0
Ivelin Ivanov Member of the JBoss core team as well as Director of Product Development.
Vinnie Mirchandani Founder of Deal Architect, former technology industry analyst (with Gartner), outsourcing executive (with PwC, now part of IBM) and entrepreneur (founder of sourcing advisory firm, Jetstream Group).
David Rossiter Runs an IT PR agency focused on helping companies communicate with IT industry analysts.
My last post addressed the nature of open source evolution and the [increasing] risks of generic strategies within the context of industry maturation. However, I did not delve into an analysis of the risk of focus simply because I felt that the topic might warrant another blog post to itself. Along those lines now, when there is an unprecedented level of activity in the commercial open source sector, more than ever, it's appropriate to work towards an understanding of:
What the risks of open source focus are
How they are affecting industry maturation
Where they fit into the competitive dynamics of commercial open source
That being said, focus of any variety carries its own set of cost-benefit realities. In the case of open source focus at this stage, of what is turning out to be a disruptive period, in the history of the software industry, there is undoubtedly a slice of profitability for vendors that accept both the risks and rewards of the model. However, as the open source marketplace evolves so do the forces enacted upon its participants. As such, the risks of open source focus haven't necessarily transformed, only the associated implications have shifted.
This shift, from my perspective, will serve to create a new class of truly hybrid vendors that develop software in thoroughly open and transparent communities but also offer other products and/or components that are proprietary. Some might scoff at this assertion since what was described sounds exactly what a number of commercial open source vendors have been/still are doing for a while. However, these hybrid vendors of the future won't only look to monetize across different versions of the same product (i.e. community & enterprise) but over a portfolio of offerings that consists of those offerings that are fully open source and those that are closed source...without losing sight of their commitment to the open source software model. This evolution will be driven by the following risks of open source focus:
Widening cost differential eliminates the advantage of focusing solely on open source.
Narrowing differences between desired products and services within the marketplace.
The economics of a one-sided software portfolio.
Not that the above risks will bring about the end of commercial open source by 'forcing' vendors to sell proprietary software, only industry maturation will present a number of business opportunities associated with doing so...in much the same way that proprietary vendors are utilizing open source without fully opening up. It will be interesting to see how this affects the definition of what it means to be an open source/proprietary company as well as customer expectation for both.
Over the past two weeks or so I've participated in briefings with, but not exclusive to, the following companies: Concursive (formerly Centric CRM), Funambol and Nuxeo. In parallel, I've been preparing my predictions for the open source software marketplace in 2008 which has entailed analyzing industry-wide trends and maturity indicators. Doing so, has led me to the conclusion that there is a decided movement in the shift in the leadership landscape amongst commercial open source business models preparing to move into 2008.
This shift is being driven by maturing business models as well as the dynamics of industry evolution. The outcome is that the generic strategies (along with the associated risks) previously conducive to growth, begin to erode as a defense against competitive forces. As a result, companies move to mitigate these risks through a number of methods. Below is a breakdown of two of the three widely recognized risks of generic strategies (excluded is the risk of focus) as it relates to the open source marketplace:
RISKS OF OVERALL COST LEADERSHIP Even as open source software continues to be associated with lower costs, the burden of maintaining cost leadership is deceptively difficult...especially as a firm seeks growth and expansion. The risks as they related to open source are:
The rapid pace of technological change that drives commoditization. What plays the role of disruptor for established vendors can serve also as an inhibitor to market opportunities for newcomers, i.e. price points must start lower and large segments of customers become highly price-sensitive. We're seeing this take place with MySQL as they attempt to continue to grow in the face of the challenges presented by competing in what amounts to a commoditized product category.
Rising quality of freely available software. As the functional gap between free and commercial open source closes, it becomes increasingly difficult to provide the added value necessary to entice free users into becoming paying customers. Oftentimes this happens naturally as a result of tending a thriving open source community that centers on free versions.
Becoming too reliant on cost-value proposition. Low costs tend to sell themselves but the nature of open source TCO is multi-varied and the entire value equation shouldn't be brushed aside. Too much attention on lower costs at the expense of being able to identify required product and marketing changes is not a positive.
A decrease in price differential. Inflation in costs associated with a growing operation can often eat into price differential margins. For open source vendors this does not bode positively for competing against the brand value and/or other evolving approaches to differentiation from far larger vendors. While this is easily offset by maintaining investments in their open source communities, there is no hard guarantee that the cost savings passed to customers will remain proportional to operating expenses.
RISKS OF DIFFERENTIATION
Cost differential overshadows brand characteristics. Ideally, being open source should never overshadow the value of the software nor the development model. However, oftentimes being openly (see: freely) available turns awareness away from open source brand characteristics and provides a cover for potential customers for whom price is less of an issue to look elsewhere. In this regard, projects like httpd from the Apache Software Foundation (ASF) have walked the thin line between remaining relevant as a leader that just so happens to also be free.
Buyers no longer need high levels of differentiation. JBoss(Red Hat) has reached a similar point, where it no longer is competing to differentiate itself from other open source application servers. Buyers and potential customers typically know what to expect from JBoss and aren't necessarily interested in how it does A, B or C better than GlassFish.
Open source narrows perceived differentiation. A perfect example of this is JasperSoft and Pentaho. Mostly these two are grouped side-by-side as open source Business Intelligence (BI) competitors when in actuality there are stark differences between the two platforms starting with business models, pricing and licensing. However, because they're both open source they have to work just that much harder to achieve a comfortable level of differentiation.
This post marks me jumping on the Open Source Census (OSC) bandwagon in support of an ambitious but desperately needed effort. Deemed "a global, collaborative project to collect and share quantitative data on the use of open source software in enterprise," at its web address, OpenLogic is sponsoring what amounts to the first, of what should be many more, wide-reaching efforts to quantify the traction of open source software behind enterprise walls. I'll start by commending Kim, Stormy and Co. for stepping forward and taking the initiative on this matter. If executed well, the OSC has the potential to inject data into the conversation about open source penetration. Currently, there are far too few reliable reference points capable of serving as numerical baselines for quantitative analysis, trend forecasting, and the like.
Actually I think the responsibility of collecting the type of data outlined by the OSC should fall on the shoulders of the entire open source community. I applaud OpenLogic's approach to stimulating participation with incentives but it strikes me that they aren't the only ones who will benefit from the data once compiled. Over the long haul, collecting data of this nature will require that open source communities take the initiative to lower the barriers to collecting this information. I've attempted to highlight the value of extracting relevant information about the free user in the past outside the context of the OSC. Ideally, the OSC would entail mostly the collection of usage data from the communities instead of directly from the enterprise. Because in my honest opinion, commercial open source vendors should be collecting this data religiously on their own. If they're not, it leads me to wonder how well the grasp the reality that data about users of open source software is a critical piece of the sales lead picture.
As a result, as the OSC comes into its own I think it will prove beneficial to work with communities to organically integrate better mechanisms and strategies for similar collecting data subsets into communal frameworks. And not simply for the purpose of sharing the load because we're in this together, but also strengthen the overall efficiency of translating downloads into dollars...something that's at the core of successful commercial open source.
The OpenDS situation Whether this series of events digresses into a full-fledged open source nightmare for Sun remains to be seen. However, it is clear that a lack of communication and commonly agreed upon execution exposed what was initially an internal fudge as a publicly-visible stain on the company's open source friendly title. Before grasping how this reflects on Sun as an open source company, it is critical to separate the term of democratic from that of open source. Unfortunately for a great many 'purists' this proves exceedingly difficult, especially when it comes to a large organization like Sun. However, as long as the expectation that open source implies democracy continues to persist, there is bound to be uproar whenever the dynamics of top-down corporations collide with open source communities.
The bottom line is that, of all the characteristics that an open source effort should exhibit, democratic is not one. If that sounds backwards, consider the benevolent dictator model. Last time I checked, all dictators (benevolent or otherwise) wield a brand of unilateral authority such that democracy (in the true sense of the word) need not apply at all. Yet this can prove OK so long as a strong sense of meritocracy, open discussion/debate and low barriers to participation remain present. What In the OpenDS scenario, it's also worth noting that Sun has far more to lose than gain by recklessly alienating any of the company's open source community in which it is substantially invested. Did the company handle issues regarding OpenDS efficiently? No. Were the lines between participation as an employee and as a private citizen clearly outlined in advanced? And should they have been? No, and of course, respectively. Yet with that in mind, Sun's purported behavior speaks to inadequate planning and botched execution as opposed to a thoroughly ingrained strong arm tactics.
Another Apache Juggernaut? For anyone keeping track of the emergence of open source in the enterprise development arena, it's old news that Tomcat has emerged as an epicenter of the trend towards lightweight Java architectures on the server-side. This isn't directly relevant from a dollars and cents perspective since its producer, Apache, is non-profit. However, Tomcat continues to serve as the key component in the penetration into enterprise data centers by an increasing array of open source software players like the SpringSource, Terracotta and Hyperic. Unfortunately, there aren't those handy NetCraft stats to quote in support of the fact that Tomcat has grown into a juggernaut in its own right.
ESTD and open source software I've commented on Savio's thoughts on integrating free users into the paying customers base. However, my perspective is that his viewpoint is critical to coming to grips with the realities of commercial open source. While I can't speak for him, I take his points on this subject as coming from an objective angle and not an oppositional/critical one. In reality, it is and will continue to prove an extremely tough game for commercial open source companies to grow their revenue figures along the same lines as proprietary counterparts. That's not to say it can't or won't be done, but making it happen will entail far more than continuing with business as usual. In effect, it's going to take a huge dose of innovation at a strategic, business and technological level. Something I expect fully to occur, but a tough task nonetheless.
Forging ahead with open source software support and services It is worth watching uptake of the SourceForge.net support and services marketplace in light of the steadily expanding pool of qualified providers. Corralling this diverse basin into a single integrated site will prove challenging, indeed. Most importantly, SourceForge.net must find ways to stimulate an actual marketplace such that the service does not devolve into a static directory of old ratings and broken links. In a way, the marketplace must address similar challenges that any of the projects hosted on SourceForge.net does: courting a community of users, encouraging participation and remaining relevant as the open source model continues to undergo successive waves of evolution.
In yesterday's post, the first of this two part series, I began by making mention of the Verizon announcement stating that the company is set to support Android-based phones. And I, like many others, am interested to see if a Google Android will mature into a bona-fide open platform for mobile device development. However, I'm also aware that innovation is never a given, even if openness is embraced entirely. Similarly, there are governing dynamics for achieving open source success that will set the tone for Android's trajectory and progression. In this post I will continue with the last five (5) of these nine dynamics.
Representative Decision Making The term "democratic" is regularly used to refer to brand of decision-making employed within open source communities. This line of thought tends to categorize communities like the Linux kernel (where Linus Torvalds retains the final right of veto) as less democratic. However, that particular expression [literally "rule by the people"] isn't quite reflective of how decisions are made and authority is actually exercised within a healthy open source community. It is closer to governance by consensus where imposed authority and top-down decisions are tempered by thoroughly integrated forms of consensus building that prizes discourse in the open over autocratic commands.
Self-Reinforcing Participation Even as the debate over the viability of cash-motivated contributions takes place, the opportunities and value of participation stands pat. Obviously offering cash is the quickest path to generating a buzz across a larger segment of individuals and potentially enticing some to participate. Be that as it may, sustained community development occurs as a result of highly-qualified parties choosing to continually participate over the long haul. Once an individual proves him/herself qualified (through consistent contributions to the community) he/she is rewarded with recognition, the option of assuming a more prominent role (unofficial or official) and/or more opportunities to learn and develop new skills. This creates a self-reinforcing cycle where growth is realized through participation and more growth opens the door to more opportunities to participate.
Continuous Improvement and Low-Cost Maturation Open source projects have long lived by mantra of "release early and often" as a governing principle for release cycles. Typically, the opportunity to accelerate the rate of improvement for software is a key driver for adopting this approach in earnest. On the other hand, openness ensures that the changes, releases and branches are all transparent to the extent that tracking, managing and referencing them can be done without hassle. As an open source project matures, the lowered cost of building and testing variations (gained through these tasks being distributed across the community) improves the prospect of assuring security and quality control. This is key to enabling a project to embark upon the path of evolving into a solution that meets user needs and requirements.
Selective Barriers to Participation While the general concept is that open = no barriers to participation, some barriers are necessary to maintain a sense of governance and structure. For instance, a newcomer should be granted full access to relevant information and source code, yet no such blind permissions should be granted for modifying official, or even unofficial, distributions. This might seem intuitive to most, yet on some levels the decision to carefully cultivate or entirely eliminate barriers can prove complex. For example, some community support forums require that users register using a valid email address before posting in the discussion area(s) while others allow anonymous pseudonyms. Whatever the case, any such barriers should do nothing to decrease the willingness to join an open source community.
Communal Ownership and Access It can't be argued that at the foundation of an open source project is its license that dictates the terms of attribution/usage for the software asset in question. One of the main purposes of licensing is to protect a valuable common resource against misappropriation, both internal and external to the community. Additionally, it is important that licensing appeal to a sense of fairness while also remaining aligned with the core realities of community-driven development. The optimal community-centric outlook prizes participants as co-owners and promotes forms of sharing the rewards and responsibilities of ownership equitably across the board.
This is the second part of a two part series, view the first part here.
News that Verizon took one more step closer to an "open" network by embracing Android, Google's new software platform for mobile devices and handsets, caught my attention for a number of reasons. First of all, I noted the magnitude of a commitment from Verizon to a platform sponsored by one of its main rivals in the upcoming 700 MHz auction. Especially considering that the company's previous two announcements were being written off, in many circles, as thinly veiled competitive strikes at Google's position in the same auction.
Nonetheless, I thought it was interesting that Verizon even paid lip service to Android, which is still an unproven entity from a number of perspectives. By this I mean, despite the coverage, buzz and sponsorship by Google, Android's outlook will be determined (in my opinion) by how the nine (9) dynamics of open source success, listed below, factor into its growth curve. To most, these might be taken for granted as compulsory, yet their existence remains very much relevant within the context of each and every open source effort.
Standards, Objectives and Solution Evolution As Roy Schestowitz astutely points out, standards and openness should go hand-in-hand. I might go on to add that while interoperability isn't a replacement for standards it is the next best thing when a standard is not available/widely adhered to. After all, there's something to be said for a CRM system that may not be "standards compliant" but still sports interoperability with various Salesforce.com modules. However, standards do help to reduce divergence across the parties involved, by highlighting what needs to be done. This counts heavily, as even the act of "solving a problem" can become vague as time wears on, whereas implementing a standard instills in-context awareness of exactly what is being done and why. Coherence in execution is the reason that while successful open source projects are often started for any number of reasons, as time passes there is one overriding characteristic: they all take the form of an evolving solution that aligns with a well defined set of objectives.
Modularity Driven Problem Decomposition Open source has proven to effectively handle complexity by introducing a corresponding level of modularity to the equation. This facet of efficient open source development is particularly useful in that it promotes agility and flexibility of design and implementation. Complex software development can be done in parallel across a geographically distributed community flexibly and independently. The value of modularity can be introduced as reusable libraries, extensions or plug-ins.
Visibility into the Collaborative Process Regardless of whether a community is governed by a commercial or non-commercial entity, visibility into the collaborative formula for a project is golden. Since software development is primarily a collaborative task so visibility with regards to the source code, application distribution, documentation, issue tracking and community support mechanisms serves as a window into the core of a project. Newcomers are able to ramp-up quickly, the community is granted agility in the even that participants leave and there is a running historical account of the aforementioned components of the software development process.
Contribution-driven Hierarchies Even within open communities hierarchies are a fact of life. The principal difference between closed gardens and their open-centric cousins is that hierarchal "rank" is typically based on demonstrated contribution to the community. This tends to create more meritocracy-centric structures where:
Individuals can build a reputation.
Trust and status are governed in a communal manner.
New members are better integrated into the overarching community.
I will conclude this list with the final five governing dynamics of open source in my next post tomorrow. Update: View the second part here.
Back in October, Packt Publishing (a UK based publishing company specializing in focused IT books) extended the offer of reviewing titles from their open source selection. I accepted and decided on the following two titles:
"JasperReports for Java Developers" by David R. Heffelfinger
"Java EE 5 Development using GlassFish Application Server" by David R. Heffelfinger
Today I'm sharing my review of the latter, with additional information, about this and other titles, available on Packt's website.
To be clear, I made every attempt to read the book, having had a background in enterprise software development, from a developer's perspective. Especially considering the fact that the book is aimed at Java developers wishing to become proficient
with Java EE 5, who are have some experience with Java. The theme centered on using
GlassFish version 2 to develop and deploy applications. Its author, David Heffelfinger, earned a Masters degree in Software Engineering from Southern Methodist
University and is currently editor in chief of Ensode.net, a web site about Java, Linux and other technology topics.
Overall I thought "Java EE 5 Development using GlassFish Application Server" was a well constructed publication that can serve as a solid introductory foundation as well as a decent reference for GlassFish powered development. I did think that it could have done a better job of integrating an overarching vision of how GlassFish fits into the concept of a Java EE 5 solution at a higher level. Especially seeing how the book cover contained the text, "From Technologies to Solutions." Nevertheless it contains enough information and examples to provide the type of comprehensive breakdown of the GlassFish architecture that an uninitiated developer needs.
The first chapter spans an overview of, getting, installing and verifying a current version of GlassFish. I thought this could have included a clear delineation of the GlassFish architecture in picture format, to better provide a clear account of its composition. Still, I was able to follow the installation prompts and install GlassFish successfully, quite a testimony considering my experience with other tech books that endeavored to provide installation instructions. The second (Servlet Development and Deployment) and third (JavaServer Pages) chapters were useful even if they probably could have been combined into a unified chapter, if only because GlassFish boasts a number of impressive features that arguably deserve mention/added coverage throughout a book of this nature.
The next two chapters covered Database connectivity and the JSP Standard Tag Library (JSTL). The latter of which I found particularly useful considering how lacking up-to-date, developer-oriented usage-based JSTL documentation is. Interesting enough, Chapter 4 contained a section called Final Notes which contained mention of accepted design patterns related to Data Access Objects (DAOs). I thought that segment should have been longer and duplicated across every chapter in the book. My reasoning is that since application server architectures are implementations of a Java EE specification there is heavy overlap between design patterns and other accepted best practices. It would have been useful to have a couple of paragraphs shed light on that reality.
Chapter 6 (JavaServer Faces) and chapter 7 (Java Messaging Service) were, in my opinion, two of the better written chapters throughout the entire book. The section in chapter 6 about integrating JSF and JPA was a timely cross reference that provided applicable practical insight into pulling the view and model components of an MVC web application together. Chapter 8 (Security) was well-placed but could have used more information about the security behavior of a Java EE container towards providing a clearer picture for developers of what happens in a simple web application. Reading through this chapter was also the point where I realized that it would have been tremendously useful to see a compilation of to the JSR's that are implemented by GlassFish as a reference.
The last three chapters: 9 (Enterprise Java Beans), 10 (Web Services), and 11 (Beyond Java EE) did not disappoint even if Chapter 11 probably could have used additional information about topics, i.e. GlassFish JBI, beyond the scope of core Java EE. Also, it might not have hurt to make mention of SOA accordant, GlassFish-friendly components like OpenESB in either the last chapter or an Appendix.
If you're considering using GlassFish as the basis of your Java EE 5 development this title is absolutely perfect for scaling that initial learning curve and getting up to speed on GlassFish version 2. For administrators or developers who don't want to reduce the time it takes to get comfortable and productive in the book will be a really big help. It's straight forward and allows readers to really jumpstart their efforts right away.
Next week I plan to post my review of JasperReports for Java Developers.