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.
After a significant amount of uncertainty surrounding its future/direction as an open source company, Medsphere has gone live with a beta version of their website for the OpenVista open source community. Since writing about some of the legal turmoil Medsphere was experiencing a while back, I hadn't heard any official or unofficial word about what was happening regarding that particular situation. However, after the company reported several successful implementations during January and February of this year, questions regarding the progress of efforts to build a publicly visible open source reference point were once again relevant. Still, my personal efforts to get in contact with a representative from the company proved unsuccessful, so I was actually surprised when I got wind of an open source release of new client and server side editions for its OpenVista® electronic health record (EHR)
It's good to see the company follow through with its originally stated strategy to assemble an open source
community around its platform that will aid EHR adoptions. What's even more interesting is that OpenVista
is actually a 'commercial implementation' of the VistA EHR system
developed by the U.S. Department of Veteran Affairs (VA) and is in use at more than 800 outpatient facilities across the VA. VistA software is already in the public domain, and is available from
the VA without charge under the Freedom of Information Act. In other words, Medsphere isn't just banking on the value of open source code that an embrace of the open source model provides, they obviously recognize the value of having a participating community around the code. As it stands OpenVista's new community editions include enhancements
made to VistA source code which extends its use outside the VA as well as an updated user interface [see screenshots].
Medsphere is looking to feed community borne OpenVista enhancements into Medsphere's commercial
editions, in addition to the hands of various hospitals and health care providers towards driving EHR deployments. It also looks like both the OpenVista Clinical Information System (CIS) and the OpenVista Server will be available under their Medsphere Public License (MSPL) version 1.0 and GPLv2. It's going to be important that Medsphere makes it clear what MSPL means, especially to those most likely to want to adapt/redistribute OpenVista -- in order to make adoption as seamless as possible. I've always been in favor of simplified, plain English narratives that accompany the actual license terms. Of course, it's always critical to have any license reviewed by a lawyer before proceeding, but it helps if front line technology folks who touch it first can get the gist of what it's saying.
Medsphere has taken several steps in the direction of establishing a foothold in the open source domain with a respectable first set of moves. It will be interesting to see how much of the existing VistA community will be interested in jumping on the OpenVista bandwagon now that it's open under the GPL [and MSPL]. The OpenVista community might receive a sizeable participation boost from individuals who have parallel branches of VistA code and are willing to provide further add-on features that OpenVista doesn't yet have. Either way, I'll be tracking it's progress going forward.
As Sun Microsystems marches towards an open Java platform with the pending release of the entire JDK as the OpenJDK project, there are several things worth noting about the future of enterprise focused development with the newly GPL'd Java. Thus far, only the HotSpot Virtual Machine and Java compiler (javac) are available with the rest scheduled to follow in the remainder of the first half of 2007. The availability of the source code for various Java SE components fits in well with the Sun's efforts with GlassFish and OpenSolaris. It also signals a transition from an open source friendly company into a services & open source one. Meanwhile it also significantly affects the many enterprise Java developers who will have to adapt to changes Sun's newly open source product portfolio will have on them as implicit members of a now fundamentally open community.
Lobbies by members of the extended Java community, such as IBM, to fully open up the Java Community Process (JCP) hasn't changed the fact that it is still a Sun-managed process with intentions to remain as such for the immediate future. A distinction must be made here regarding the fact that open source code doesn't exactly equal open standards-making. Neither does a community surrounding the open source code indicate an entirely different direction for the approximately 1,000 member consortium. At the end of the day, the JCP continues to retain control over new features and related aspects of Java technology and the actual specification process isn't what's being opened up.
However, as developers are granted some leeway to contribute to the source code (directly and indirectly) they will also find a larger platform to develop voices within the JCP. As more gain experience as implementers, they will also gain leverage to influence future directions and decisions. This is the nature of the open source model, one which helps to transform [passive] consumers of technology into active participants in its growth. Sun's commitment to open source provides similar opportunities that members of various Apache projects, Eclipse and Spring communities have had for some time now. It matters less that Sun's effort differs in scale and category from the Java libraries, IDE's and application development frameworks available courtesy of the aforementioned, and more that an open community is now an active part of its lifecycle.
Now that source code is available under an open source license, user organizations are freed to push the envelope with the creation of their own platforms to meet specific requirements. A reality that bodes increasingly interesting as Linux on the desktop gathers more steam. Open and closed source Java implementations that have been optimized for Linux and can now come bundled with individual distributions gives client side Java a bit of a decent foothold within what's proving to be a potentially strong market. The same can also be said for Windows, only .NET will still take the cake as it relates to Windows-only development. Once the benefits of having different implementations available becomes further evident, the calls that this makes it harder to ensure Write-Once-Run-Anywhere should die down quite a bit. Plus, having a GPL license as the basis for derivative works will mean very little changes from the developer's perspective.
Maximizing the value of changes to Sun's model for the Java platform will entail embracing the dynamics of the open source model itself. Foremost, it will be useful to track and perhaps become involved in the open source Java projects. The JCP process also provides a forum for providing feedback as well as submitting requests and a newly open model surrounding Java will lend itself to creating a premium on these types of interactions, so it is prudent to evaluate participating. Despite embracing the open source model, Sun is still in control of the Java brand, granting the company a validating say-so over the compatibility of competing implementations. So until something changes, Sun's Java stamp of approval still stands as before.
I was reading some of James McGovern's posts over at his Enterprise Architecture blog and thought it might be relevant to comment on this particular one. The theme is open source vendors who portray themselves to be more open source than they actually are. I'll avoid naming any names (not due to any conflict of interests with Entiva, just out of common courtesy), but needless to say there are several companies who are not as open source as they allow outsiders to believe. I use the word 'allow' because they aren't so much actively lying about their business model as much as they are calling themselves open source despite barely meeting the qualifications. Nonetheless, it's still misleading tactic that tends to set off red flags more than it aides adoption.
That being said, there is still room for products in the commercial open source space which aren't necessarily 'open source' according to the OSI definition so long as the vendors behind them remain totally transparent about that fact. They also need to ensure licensing terms can be understood without introducing too much room to wiggle on the vendor side. Meaning terms should be spelled out within the license as they will be interpreted throughout the product lifecycle. This is taken for granted with 'mainstream' licenses (a la the GPL) as the major implications of their terms have become common knowledge of sorts.
Another issue is that of vendors taking an open source project and creating a heavily similar commercial version all while steadily claiming to be open source. And only after looking into the matter is it even obvious that this is what's being done. Even though being classified as open source doesn't begin and end with one set of characteristics, it does imply a certain degree of open access to a software product. Without it the inherent strengths of the model are pretty much negated and you're pretty much dealing with [lower cost] proprietary products.
Furthermore, what James was most likely making light of in his blog post are vendors who are guilty of not being up front about these subject areas while holding tight to the moniker open source...one which incidentally implies adherence to the OSI definition. Should those vendors feel obligated to absolve from referring to themselves as open source for the benefit of potential customers? Probably not. Should those same vendors be forthright in making it clear of their standing as an 'open source' company? Definitely. However, since it very rarely happens that way, it falls into the lap of those on the demand side to do the research and investigative work. An admittedly difficult task (I know from experience) that really requires a serious license analysis which should take place amidst the context of ongoing communication with the vendor.
To further what James suggested, it might be even more useful to maintain a publicly maintained list of open source vendors and their products, licenses and approach. Included might be a brief description of how 'open' each one actually is.
Spurred by conversation with my girlfriend over the weekend, I've been thinking about different parallels between certain economic/political/social systems and the open source industry. Mainly, I've come to the conclusion that open source (as a methodology, ecosystem and movement) does a commendable job of naturally balancing the different aspects of economic, political and social needs of an extensive group of involved parties. This, the first part of a three pronged series, will explore how open source inherently promotes shared ownership of the equivalent 'tools and means of production' while also driving profitability and reducing costs for established profit channels.
Before starting, it is necessary to state that I am of the opinion that this is a topic which can/should be explored in further detail. The intention here is to stimulate thought and discussion surrounding potentially detailed analysis and investigation. Likewise, this shouldn't be taken as an endorsement or criticism of a particular form of economic/political/social system.
How Did It Get Here? Unfortunately, a great deal of highly interesting dynamics introduced by the emergence of open source are being ignored in favor of forming shallow perspectives related solely to products, companies and services. All of which exist as a result of the very dynamics that are repeatedly overlooked. Nonetheless, there still exists a wide ranging set of implications and potentialities which are very much relevant and beg to be considered. Particularly applicable, in light of increasingly globally-oriented relationships and economies, is how open source has succeeded in endorsing better forms of ownership while also fueling traditional forms of corporate profits and cost reductions.
Going forward it should be kept in mind that in modern-day, information driven economies, ownership, tools and production mean drastically different things than they did 50 years ago. For the record, an increasing portion of value is generated through the manipulation of things like 'knowledge capital' and other forms of non-physical asset. Likewise, the means of production for such entities also differ substantially from the past.
A prime example of this reality is software. While software can take physical form and its production is not entirely 'virtual' it's development has come to rely on very much non-physical means such as distributed collaboration aided by the Internet. The result is that traditional ownership, in the form of direct control of those means of production, has come under assault. Compared to 'widget manufacturing' where the environment in which widget creation takes place - a factory of some sort where its lease, physical property rights, etc. is owned by a personage (corporation, state or even an individual) - software production can take place without regard to a designated physical location. Plus, the means of distributing produced widgets (storage, shipping, stocking) are also resigned to an owned physical presence. Still a requirement today, the sole dependency on traditional forms of production and distribution has been diminished.
Early on, this actuality proved to be a boon to the companies who brought software products into existence. Since it could be produced pretty much anywhere and distributed in an increasingly less expensive manner with minimal opportunity costs for reproduction, the business of software has doubled as a fairly substantial wealth generator at more than one level. Over the last three decades, the rise of corporations such as Microsoft, Oracle and SAP further serve to confirm this position.
Where Open Source Fits In Even still, before the emergence of open source it held true that only some form of business structure could consistently muster the resources in the form of people (developers, testers) and particularly tools to rationalize the costs (despite being relatively low) of developing software (especially those types which other businesses have come to rely upon). Thus companies tended to start-up around an idea (see: VisiCalc) or market opportunity (see: Microsoft) which were later formalized into a product by a company using a closed software development process. Alternatively, open source consists of organic communities jump starting projects which can prove their viability before the concept of a company even enters the picture, if it ever does. A valuable evolution considering the initial and continued attenuation of product development costs that occurs as a result.
By producing a wide array of free and low-cost tools (in the form of software, documentation and other forms of congealed forms of knowledge) using those community-centric models, the open source movement has at once destroyed barriers to and created new opportunities for ownership of those very tools. Even the word ownership, has to be redefined as community driven development has taken the control of production away from select, closed groups and equitably distributed it in a more egalitarian manner. Accordingly, it isn't necessary to have total control in order to reap the benefits of ownership, it's possible to take a contributory role while also leveraging ownership at the same time. The concept of increased ownership through contribution has powered the growth of self-maintaining communities capable of generating value internally and externally.
Keeping with the factory analogy, buyers of proprietary software have slim hope of ever
receiving the benefits of shared ownership in the process of closed software development. They are reduced to passive consumers of a defined output in the same way that factory workers are limited to the role of productive cog within a strictly hierarchal, top-down assembly engine. Full control resides on the side of the proprietary company as much as it remains in the hands of the factory/plant owner. On the other hand, open source encourages ownership as much as it does use/consumption. Users are immediately made stakeholders in the direction, progress and success of the software in addition to being granted the freedom to better determine their own dependence on that specific component.
Mutually Beneficial It might seem intuitive that the increase in the potential for control at granular levels made possible by opportunities to own the associated tools would mean a loss for larger corporations (privatized articles of existence and ownership). However - even within heavily competitive, market-driven environments - easier to acquire tools have fueled the development of even more and better quality open source software, from which a substantial number of large businesses are able to profit. So despite the fact that market share is being both won (by a new generation of commercial open source software company) and lost (by some traditional vendors whose business models are at the other end of the spectrum), open source has harmoniously fueled its own growth while meeting and exceeding the needs of both the individual/small[er] company and the large corporation.
This takes on added significance today as most are left wondering if runaway global giants such as WalMart and Target can coexist in accord with the needs of the smaller business and the individual at a local level. The manner in which global companies of similar force (see: IBM) profit from the Linux ecosystem without marginalizing smaller plays may speak to potential avenues which promote increased mainstream profits without homogenization and/or reduced competition.
The next (second) part of this series will focus on how the open source universe effectively merges community oriented ideals with the concept of private ownership.
Following up yesterday's post, which made mention of some of the reactions across the blogosphere regarding the vendor-formed Open Solutions Alliance (OSA) initial announcement. It's relevant to mention that Unisys and GroundWork have also has joined the OSA force while even a vendor like Microsoft has expressed interest in teaming up. As I stated yesterday, I was briefed last Friday by OSA came away with a pretty good picture of what they're trying to establish.
The mission statement for OSA as relayed to me by Barry Klawans is:
"To expand the market for open
source business solutions through cooperative action and advocacy that
facilitate interoperability, reduce barriers to customer adoption, and increase
awareness of open source alternatives."
At first mention I thought the above sounded good, if only a tad bit broad. OSA can definitely work out interoperability amongst the member vendors, but doing so outside of the alliance is going to be a challenge. Nonetheless, after some additional thought and reflection, on common issues which continue to dog the footsteps of the open source software industry. I came to the conclusion that by scoping the mission in that manner, the OSA can tackle the intricately intertwined problems which require particularly sticky 'cross-category solutions.'
While making some rounds with IT managers at several medium sized companies during Fall 2006, the topic of outreach was consistently brought up when discussing what needs aren't being met by the open source community. The general consensus was that open source companies in particular are failing to achieve the deep penetration within segments that can most benefit from open source solutions. I found that tidbit exceptionally valuable as I remain a big believer that once people know what open source is out there, the quality of products will speak for itself and even sell itself to a great extent, but the word must get out and it must be framed in the context of solving business problems. Right now that information continues to remain locked in esoteric circles of knowledge. That needs to change and OSA has set out to do just that.
Matt Asay, who has quite a bit of frontline experience in the commercial open source arena, feels that the biggest challenge right now is managing the growth of open source and not pushing its adoption. And I agree, partially. Managing growth remains a priority, especially considering the varied dynamics of open source when compared to proprietary software. After all, I spend many a working day [and night] doing strategic engagements on the demand side of things for Entiva Group customers who want to make sure they have their heads and hands around open source. So I know first hand how important this is...
However, the fact remains that I continue to come into contact with one firm after another which expresses some sort of variation of a situation where a certain category of software product was being evaluated and open source alternatives weren't seriously considered due to a lack of available, up-to-date information. On the other hand they continued to be deluged by cold calls, marketing materials, etc. from proprietary vendors.
Now, I'm not suggesting that the OSA turn to similar Dennis the Menace-esque 'marketing' tactics, but I can say that it will serve the open source community well to explore effective methods of advocacy which helps eliminate some of that knowledge gap. In terms of general levels of awareness about open source, there is quite a bit of work to do and not enough who have dedicated themselves to making it happen. After establishing appropriate levels of awareness, an open source product is free to prove itself what it often is, an equal if not better option.
Among other things, this type of business level advocacy is critical in order to cross what Jeffrey Moore so aptly dubbed 'the chasm,' in his now famous 1991 marketing book, as 'the chasm.' See image below (click to enlarge):
For those unfamiliar with Mr. Moore's work,
Slices A and B (innovators and early adopters) constitute 'The Early Market'
Slices C,D and E (early majority, late majority and laggards) compose the 'The Mainstream Market'
The gap between B and C is the chasm.
Despite signals of serious growth and indicators which point to more, in reality open source is in the process of fully bridging the chasm. For every report of company A or government B switching to LAMP or Red Hat, I have a bulk of first hand experience where people want to know what open source CRM solutions are available. Really. Personally, I find it mildly amusing that they've never heard about SugarCRM or Compiere, but the point is that they haven't. And believe me, there are more who aren't even aware that enterprise grade open source CRM alternatives. And they need to be reached if open source is going to go not just 'mainstream' but hit the meat (see: revenue generating opportunities across a large number of segments) of the global market for software and services, where it's only now cut through the fat (see: categorically sparse penetration lacking larger market share capture).
Perhaps OSA will go the way of OSDL? Maybe it will succeed magnificently and set a tone. I can't and won't call it right now, but I do know that its mission is quite relevant and timely. Namely, it is something that needs to be addressed one way or another. Hopefully the OSA's execution and strategy can fall in line as well.
Matt Asay has an interesting perspective on the newly announced Open Solutions Alliance (OSA). While I'm sure Matt has his reasons for seeing things the way he does and I also have my own set of thoughts that I will post tomorrow (I received information about OSA late today that I want to integrate it into my post), so stay tuned. After the ill fated OSDL, I would expect there to be more negative expectations for OSA than positive. However, the success or failure of one such entity shouldn't entirely adjust the expectations to an extreme extent. Plus, there's always room for the next 'anything.'
Total Cost of Ownership (TCO), which used to be the primary angle for justifying the use of open source software, continues to remain relevant even as open source emerges as a disruptive force in the software industry. The explosive growth of commercial open source has made it clear that this new force is something entirely different from 'just another type' of free software. A strong TCO analysis should take into consideration the unique characteristics of open source while steering clear of flawed generalizations about its nature.
Key arguments in favor of open source software
Increased flexibility: Acquiring open source software enables the acquirers to tap into not only a software product but also the surrounding community & vendor ecosystem. Ownership is not limited to packaged binary and documentation, but is extended to the highly valuable knowledge and experiential capital that resides in these distributed communities. A great deal of which is naturally integrated into the quality of the offering, through the collaborative nature of its open development model.
Ease of integration: Since software must always fit into a larger IT infrastructure, integration takes many varied forms. Integration at a technical/functional level involves connecting disparate applications and systems. The ultimate goal being to create and harmonize end-to-end, functional systems. However, as the growth of service oriented architecture approaches have shown, there are other levels of integration which can involve business process, policy and governance. So while open source undermines the possibility of vendor lock-in with added flexibility, it also can be tailored easily to overarching business goals and objectives.
Better growth management: As the time following an acquisition passes, software becomes integrated into the fabric of that owning organization. Having access to source code, can help protect against external events, i.e. changes in support contracts, versioning differences, acquisitions or mergers involving a commercial entity responsible for a product, etc. Increased autonomy brought about through open technology is key to managing growth occurring around it and as a result of its presence.
Support of open standards: Despite the fact that open source isn't synonymous with being standards based, such products have a sizeable incentive to assimilate open standards into their architectures. The value of doing so feeds into all of the aforementioned arguments as much as it eases the prospect of extending an IT portfolio. Regardless of whether that extension is a new addition or replacement for a pre-existing alternative.
Cost drivers in a TCO analysis
Capital Expenses: Open source does just as much to eliminate the ongoing costs of software ownership as it does the initial capital expenses involved. Nonetheless, traditional capital acquisition expenditures can still be required. In many cases, the selection of an open source product is done within the context of a pre-meditated move towards open source offerings. In this case these initial capital expenses can be justified by greater savings to be realized going forward. In other cases upgrades to surrounding infrastructure might be required as a pre-requisite.
Design and Deployment: The time & resource costs of research, design, integration, testing, tuning involved with a product launch are all reduced when dealing with open source. Depending on the asset in question, server and network capabilities must be reassessed and augmented. Hardware, operating systems and applications have to be evaluated for compatibility, if necessary. Yet the option of using select community versions before purchasing a commercial oriented product, will help diminish the required outlay. Even if a commercial version differs from the freely available community edition, the ability to flexibly evaluate proves to quite useful.
Ongoing maintenance and infrastructure: Continuous ongoing operation, requires network monitoring and management tools capable of enabling real-time problem diagnosis and responsiveness. Periodic software maintenance and support contracts plus system upgrades all contribute to the total cost of ownership. Multiple redundant systems, and add-on feature sets can also increase cost. Since all types of ongoing expenditures are spread out over the lifetime of ownership, they must be considered in any competent TCO analysis.
Operations and support: Support ranks as a critical success factor to the successful adoption and ongoing use of any software product: whether the product is aimed at end-users or used administration side, a steady diet of issues can lead to considerable losses in productivity. Commercial open source companies exist, in part, to ensure that different levels of support and indemnification are indeed available. What's more, since patches and/or upgrades will require additional IT resources more is being done (in the form of alert services, targeted information channels) by open source vendors to ensure this process is as seamless as possible.
The TCO Calculator -- typical comparison matrix cost variables
The Swiss drug giant, Novartis, announced that it will make information, about which of the 20,000 genes identified by the Human Genome Project are likely to be associated with diabetes, available over the Internet. Fortune has the story here.
While the main motivator can't necessarily be attributed to the company's support of open processes and business practices, the sheer task of the effort makes the opening of the information most feasible. In this case more eyes is definitely a bonus especially when compared to the prospect of keeping a tight lid on the information but having to stay strictly in-house with the task at hand.
For those who keep up with big Pharma, it's common knowledge that collaboration isn't a new thing except for the fact that this time you don't have to be a billion dollar drug company to participate. Obviously, no single approach is going to magically produce and bring forth a cure/competent treatment, to market overnight. However, it is going to be interesting to see what value opening the playing field to a wider variety of participants will have on the progress made over the long haul.
Still, there's an underlying sentiment that without the option of patenting the raw genetic information, a great deal of incentive to do this difficult work has been removed. More than likely, it is going to take a strong balance between open & closed, community & profit similar to how things are taking shape within the open source industry to bring forth the best for all parties involved. Hopefully, this is a step in that direction.