Sep 02, 2014
You might have noticed that I haven't been posting here much over the last year. More likely, you haven't noticed at all. Blogs are often like that. They come and go depending on the whims of the blogger.
The reason for my silence is that my focus has shifted from pure content management to lean product development, web application development, and cloud-base architecture. At Lionbridge, I have been helping to build a business called Lionbridge onDemand. It has been a little over a year since our first sale and I am in a constant state of amazement about how things are growing. Like most of my projects, we followed a lean product development model of launching a minimum viable product and continually improving it to support the needs of our growing customer base. In this case, we started with a tiny website to translate videos. Since then we have grown to the point where:
-
We now have a wide array of services that support nearly 40 different content types. We even have services that do not involve translation at all such as proof reading and CRM data cleanup.
-
There are enterprise sites for many name-brand clients. It turns out that large organizations are full of individuals who prefer a simple consumer style eCommerce experience. With onDemand Enterprise, we can quickly create a custom site for a corporate account. These enterprise sites have the same simple "consumer" feel but they also have the ability to offer custom services and can tap into corporate payment channels.
-
We have a Public API with a developer program. We started with an API for eCommerce systems to translate product catalogs; but then we grew into a full featured translation API that can handle our full complement of content types. While there are other translation APIs out there, ours is unique because it exposes different translation services ranging from pure machine translation to professional translation by subject matter specialists.
-
We are now a global team working around the clock to deliver projects with industry leading quality. We have operations specialists in North America, Europe, and Asia. Managing a service like this requires a special mix of problem solving skills. This is content management at a level of complexity that I have not seen before. The process requires the constant attention of highly skilled and conscientious individuals.
The last point is my favorite. I am currently en route from Warsaw, Poland where I have spent the last five weeks working with the operations core team. It was an incredible experience to meet the people that I had only known through email and conference calls. From the start, I was impressed by their dedication and can do spirit. Now they feel like family.
So, back to this blog. What has made Content Here a worthy endeavor so far was that it provided a useful place for me to explore observations and concepts that I encountered as a content management professional. If I learned something, I would flesh out my knowledge by writing it here. If I did a decent job of explaining something to someone, I would reproduce that explanation here. If that was all blogging did for me, it would have been enough. But blogging provided so many more benefits. In particular, it was a way to connect with other people. I made many business connections and friendships with this blog.
I am hoping that I can continue experiencing these benefits by shifting the focus of this blog to be more aligned with my day to day work. It won't be a total departure from my older posts. My involvement in web development and open source software has stayed the same. But I will probably write a lot less about content management software, product selection, taxonomy, workflow, and other pure content management concepts. To be honest, I feel like there is not much more for me to write on those topics. There will be more posts about my experiences from growing a web business. Topics will include things like working with distributed teams, lean product development, customer support, web application development, and web operations.
Hopefully, along the way, I will meet new people who are struggling with these same topics. The web is a pretty big place so I think that chances are good.
Jan 03, 2011
When talking about open source software, it is often necessary to mention software that is not open source. Most people use the terms "commercial" or "proprietary" to classify the other kind of software. But neither of these words are right because open source software can be both commercial and proprietary.
Commercial means relating to commerce. Many open source software applications are built by software companies for the distinct purpose of engaging in commerce. We even talk of "commercial" as a classification of open source software: "commercial open source software." Open source applications can also be proprietary. Proprietary just means it is owned by someone. It is up to the owner to decide how much he wants to share his property. Putting an open source license on a software application doesn't make it a public good. An open source license is like any other license in that it states terms of use. You need to own the software in order to put a license on it and enforce it. The owner of an open source licensed application can also change the license to another license that either does or doesn't qualify as open source.
Given the inadequacy of "commercial" and "proprietary," I find myself using the terms "closed source" or non-FOSS (FOSS is an abbreviation for Free/Open Source Software). Non-FOSS is probably more accurate because many software companies practice a "shared source" model where they make the source code available to their customers. This doesn't meet the open source definition but it does invalidate the description of being "closed." If we want to be be totally technical about it, we could call software that isn't open source "OSDNS" (Open Source Definition Noncompliant Software) but that doesn't exactly roll off the tongue.
As academic as this little naming exercise appears, I think that it does reveal the nuances of software licenses more than "good open source, bad proprietary." Open source is just a classification of software licenses — a classification that is not always useful when it comes to assessing the suitability of the software. Open source licenses don't make software better, altruistic, communal, collaborative, or anything else. The ecosystem that supports the software defines what it is. The license is just one aspect of how the ecosystem operates. Interestingly, there is a meme within the Plone community to move away from the "open source" branding to something like "community shared development," which intends to focus on how the software is developed and managed (rather than its licensing) and differentiate from commercial open source.
Jul 19, 2010
Roberto Galoppini has an interesting case study on selecting an open source project management tool. In it, he describes his SOS Open Source methodology for filtering open source projects by looking at a number of factors organized into three categories: sustainability, industrial strength, and project strategy. The case study doesn't go into much detail but Roberto has built a tool that aggregates quantitative and qualitative project information from a number of disparate sources and builds scores. I saw a demo around 6 months ago and was impressed by the graphs he was able to create. While this technique cannot be expected to make a technology decision for you (you need to know your requirements and to have hands-on experience for that), it can be used to filter down the market and help you decide where to invest your evaluation energy.
Despite its ubiquity, open source software is still unchartered territory for most technology buyers. That is not to say that most companies don't use open source software, nearly all companies leverage at least open source utilities, libraries, and infrastructure (operating systems, databases, web servers, etc.). Many companies use open source business applications too. It is just that many companies adopt open source technologies in haphazard and spontaneous ways — at least not with the same level of conscientiousness put into an expensive commercial software purchase. While I don't think buyers should put much stock in Gartner's or Forrester's opinion of technology, it barely exists for open source technologies. That point was hammered home in a recent a Olliance webinar when one of the panelists said that Gartner and Forrester offer no value on open source. All the CIOs on the panel leveraged their peers and internal experts rather than their analyst subscriptions.
Ideally, technology procurement should be able to sense if there is something wrong going on with the project. The information is out there and you can get it in real time (as opposed to commercial software companies that only report quarterly). You just need to know where to look. Tools like SOS Open Source provide a useful high level picture to quickly highlight potential issues that should be investigated. It is unlikely that mainstream analysts will be able to develop this level of awareness for open source projects so I think there is great opportunity for these data aggregation tools.
Mar 01, 2010
The Open Source Way is a great resource for developers who want to start their own open source project. It is a wiki of lessons learned and best practices gathered primarily from experiences working on the RedHat and Fedora projects. One page that I find particularly interesting is "How to tell if a FLOSS project is doomed to FAIL." The format assigns "fail points" for common (and uncommonly stupid) mistakes that project leads make. Making a few of these mistakes doesn't doom your project but making lots of them definitely stacks the odds against you.
While it was written from the perspective of a Linux library developer, the list also contains useful information for other types of open source projects. I was hoping to add some content around project leadership but I was discouraged to see that I was not able to create an account or contribute to the discussion page (FAIL!). Here is what I would have added:
-
There is no road map showing planned improvements to the software
-
The project leader(s) is(/are) not transparent about decisions [ +5 points of fail ]
-
There are no guidelines for contributing to the project [ +20 points of fail ]
-
The project does not have a way to attract and incorporate new contributors [ +10 points of fail ]
-
The project does not have a system for recognizing/rewarding contributions [ +5 points of fail ]
Jan 04, 2010
I have finally gotten around to reading Clay Shirky's excellent book Here Comes Everybody
. I love Clay's writing style and the way his perspectives make me think. One of the points that really resonated with me was about open source. But before I get into it, I should say that when Clay talks about open source, he is really talking about community developed open source (not commercial or institutional open source). Readers of this blog know that the designation "open source" simply means that it is licensed under an OSI certified license. "Open source" says nothing about how the software was developed. Given that disclaimer, Clay nails it when he describes the advantage of community developed software:
The bulk of open source projects fail, and most of the remaining successes are quite modest. But does that mean the threat from open systems generally is overrated and the commercial software industry can breathe easy? Here the answer is no. Open source is a profound threat, not because the open source ecosystem is outsuccessing commercial efforts but because it is outfailing them. Because the open source ecosystem, and by extension open social ecosystems generally, rely on peer production, the work on those systems can be considerably more experimental at a considerable less cost, than any firm can afford. (from page 245 of the hard cover version)
This quote comes from a chapter called "Failure for Free" that discusses the importance of failure for innovation. The key point is that traditional companies can't afford to really innovate because they must limit their bets to initiatives that they feel have a high likelihood of success. Innovation winds up being constrained to small tweaks to things that are well known. Real breakthroughs are rare. Community development doesn't make better ideas but it reduces the cost (and risk) of trying ideas that at first seem unlikely to succeed. Out of all this experimentation comes unexpected successes. Even the failures provide useful data that can be turned into future successes.
When open source critics see the volume of incomplete or dead open source projects as evidence against the sustainability of open source, they are missing the point. A low success rate is critical to real innovation; but that is hard to understand by someone for whom failure is discouraged or not tolerated at all. It is widely accepted that the best design for an experiment is one with a 50% chance of failure: if you know what the outcome will be, the experiment is not worth doing. But if the cost (in time and resources) of the experiment is zero or close to it, the ideal failure rate is much higher.
While we have seen many examples of community developed software out-innovating its commercial peers, this phenomenon has very little to do with open source. An open source license can create an environment that invites contribution by reducing the risk that one will exploit and unduly profit from another's contribution. But what is more important is how the software is managed. Most successful open source projects have adopted an architecture consisting of a core that is tightly managed for stability and quality and is extensible by adding modules. The bar for module code is considerably lower than core code. This allows an open and dynamic community to experiment with new ideas. The community not only bears the cost of failure but it also brings in new perspectives that the core maintainers don't have. Some of these extensions will be absorbed into the core or will become part of a commonly used bundle. Others will wither and die.
This pattern of stable core and innovative fringe does not have to be unique to open source. It doesn't really matter how the core is licensed if entry into the fringe is open. The one area that open source licensing helps with the core is in achieving a level of ubiquity that attracts a community. High licensing fees or the bottleneck of a traditional software sales process can limit the size of the user base and discourage contribution. The community developer needs the promise of a large user base to justify the time investment of contributing his work. But open source is not the only way to achieve a large user base and there are plenty of examples of commercial software and SaaS user communities that have a successful code sharing ecosystem. One company that is particularly successful is Salesforce.com. Salesforce has created a very powerful API and module packaging framework. More importantly, they have priced the product to penetrate small-medium sized companies and non-profits. In particular, the Salesforce Foundation makes the product very inexpensive for non-profits. These strategies have infused the customer population with lots companies that are highly motivated to share. These customers are active both within the AppExchange community and also integrating 3rd party open source projects like Plone (see Plone/Salesforce Integration) and Drupal (see Salesforce module).
On the flip side, there are plenty of commercial open source software companies that not been able to leverage community development. There are two primary ways an open source software product can prevent community development from flourishing. First, there can be factors that limit adoption of the core like in the case of open core products that discourage the use of the open source version. Second, the architecture can be monolithic so the only way for an outsider to add a feature is to fork the codebase. All a software producer has to do is solve those two problems. The supplier doesn't even really need to provide tools for sharing code. If the install base is large (which usually means the software is useful) and the architecture is modular, developers will find a way to communicate and share code. They can use services like Google Code, GitHub, or SourceForge to collaborate. Too often companies put code sharing tools in place without solving those two problems and then complain when they don't see any activity. In many cases, the user audience is too small to support a contributing ecosystem. In other cases, the incentives are not lined up appropriately. Shirky calls the three ingredients of a collaborative community: promise, tools, and bargain. The promise is what the contributor can expect to get out of participating; the bargain is the terms and rules for participating. Open source licensing helps with the promise and the bargain. The open source promise is that others may help improve your code. The open source bargain is that people can't take exclusive ownership and profit from your work. Some communities, like Salesforce and Joomla! have thriving commercial extension marketplaces. In those cases the promise and bargain are different but they are very motivating.
Any widely used software application, if it is appropriately designed, can benefit from community development and the benefits are not limited to the successful contributions. Perhaps the biggest value of community development is increased innovation through reducing the cost of failure. In order to harvest this value, a company needs to actively monitor, analyze and participate in its community. There is a goldmine of information sitting in the chaff of failed contributions as well as the modules that do gain traction. Companies that ignore this value do so at their own peril.
Oct 14, 2009
In case you have not been following the open source blogosphere, there is an interesting discussion happening around a new term called "open core." Open core describes the strategy of building a business on selling commercially licensed software with open source licensed components or companion products. Open core companies tend to use third party open source components and distribute some of their own components (not the complete solution) under an open source license (typically the GPL because that is the most protective). Matthew Aslett has a nice breakdown of what is and what isn't open core; although I disagree that the subscription model is open core when the vendor requires a subscription fee to use the software.
This strategy is in contrast to software companies that primarily offer a free open source version of their product and make their revenue entirely from support services (such as technical support, maintenance, training, implementation). eZ Publish and Hippo are pretty good examples of pure open source companies. The term "open core" was coined by Andrew Lampitt and all the chatter around it shows how much it is needed. The market needed something to distinguish the two types of companies: open source and open core. Nicholas Goodman makes the observation that it doesn't make sense for a company that only sells proprietary software to call itself an open source software company. Now each type of company gets its own descriptive classification.
Many of the "household name" open source software companies follow the open core model: Alfresco, SugarCRM, Pentaho, Magnolia... to name a few. The viability of the open source version varies from company to company. Magnolia Community, for example, is full featured enough for most typical uses and is as well maintained as the Enterprise Edition. In other cases, the Community Edition is deliberately hobbled to encourage an up-sell. In other cases, the licensing is just confusing. For example, Alfresco's Enterprise Edition is officially GPL licensed but you need to pay an annual subscription fee to use the copy that was compiled and tested by Alfresco, Inc. — and they won't sell you support or allow their partners help you unless you are using the version they compiled.
From a market perspective, the "open" companies that were established with venture capital tend to be open core. This makes sense because venture capitalists make big investments and are looking for big returns — bigger than what a pure services company can hope for. To get VC money, a start-up would have to position itself as a software company that needed to build product with scalable sales and decent margins downstream. Services companies don't work that way. A services company can make money from day one but shouldn't expect hockey stick growth and low variable costs. A successful service-based software company may also need huge market penetration to create a big enough market to sell services into. It is a matter of multiples. If for every 100 users you get 1 paying customer, you better have millions of users. Many software categories do not have that market potential. For every 1 CRM instance, a large company will probably have 3 CMS instances, 30 database instances, 60 web server instances, and 100 operating system instances. This is why RedHat can be more open to unpaid use than SugarCRM.
So, what does this all mean to the buyer? As I mentioned in the Open Source Web Content Management in Java Report, it is important to understand the vendor's business model to judge the viability of the company and the total cost of the software that you will bear. Differentiating between open source and open core will add some clarity to a confusing marketplace with complicated licensing models.
Aug 12, 2009
Nuxeo CEO Éric Barroca has an excellent post that breaks down the hype and decodes the marketing speak around commercial open source software. He doesn't name names but he does call out some of the claims and language of some commercial open source vendors. The general message is this: software vendors should focus on making great products and be clear and direct about what they are selling. There is nothing wrong with selling proprietary software or charging license fees — just be clear about it. Don't call a license fee something else to give the appearance that the software is free. Éric also gives a lot of credit to commercial software vendors that contribute to open source (like Atlassian, Day, and IBM) without making a big deal about it.
Jan 13, 2009
As potential customers start to evaluate open source software in the hopes of reducing costs, some are surprised to find the savings is not what they expected. This is not a "free puppy" scenario where the software is so "needy" that it costs you more to maintain it. Rather, this is a case of the products that commercial buyers are most likely to recognize and consider, operate and behave like commercial software companies. These high profile open source vendors are typically established with a substantial venture capital investment and have obligations to grow revenue quickly. They are building infrastructure (sales and marketing organizations, documentation, customer support) to compete with commercial products. They are careful about protecting their intellectual property. They pay salaries to people who don't code.
The screen shot above shows part of the Alfresco registration screen that you need to fill out to get access to a trial download and various information about the product. Because they collect this information, they probably have the sales and marketing staff to contact the people who register. Not all commercial open source companies operate in this way. Many just put their stuff out there with the hopes that potential customers qualify themselves and come forward if they have a need that a business relationship (support, custom development, training, implementation resources, etc.) that the vendor can satisfy. Open source software companies are spread across a spectrum ranging from the classic commercial software model to something that more closely resembles community open source.
It is not surprising that commercial open source companies that behave like traditional software companies need to monetize their customers like traditional commercial software companies do. In many cases, these companies depend on selling commercially licensed versions of their software products. These products can be cheaper than their commercial competitors but they don't have to be. In theory, the open source development model saves money by reusing free, externally developed components rather than building everything yourself. But this strategy is not exclusive to open source software vendors. Just look at the number of closed source web content management companies that use the TinyMCE WYSIWYG editor or the Velocity template engine.
I have written blog posts (here and here) and reports describing the different twists on open source business models. These concepts are important to understand because they frame your role as a prospect and customer. The most common strategy is to sell a commercially licensed "Enterprise Edition" that you need to pay an annual subscription fee to use. The absence of an up front license cost is nice but, like with SaaS, the annual fees can add up. It is up to the vendor to decide what happens if you stop paying for the subscription.
Offering a free, open source licensed version of the software is what qualifies the vendor as an "open source software company." But, depending on the company, this product (often called Community Edition), may either range from window dressing to a core part of their strategy. Some open source companies generate revenue by using their community edition to penetrate the market and create opportunities for other services such as training, support, or up-sell. Other companies actively discourage the use of their community edition products. How viable the community edition is for your business depends on both your requirements and how the software vendor treats the product.
If a software product has a commercial license or is otherwise identical to traditional commercial software, it doesn't really matter that it is marketed as open source; it is commercial software. By extension, if a software vendor only really supports the commercial version of its product, it is a commercial software vendor regardless of how it markets itself. The industry is confusing this way because it classifies software not by the license of the software itself but by the claimed business model of the vendor. I have to admit that I am as guilty of this as the next guy.
If you have been looking for a traditionally licensed (closed-source) software product (with all of the benefits and costs that normally go along with a software purchase), why not consider the commercially licensed products from open source vendors? There is no reason why the services supporting the product would not be comparable to a similarly priced traditional commercial software product. From a sales support perspective, you can expect an experience that is comparable with a low-to-medium price ($30,000-$70,000) commercial application. You won't get any Super Bowl tickets but you will get the attention of a sales engineer to help show you the benefits of the platform - at least over WebEx, in person if they are local or the deal is big enough.
If you are looking for an open source product that you can save money by self-supporting (with the help of a community), there may be some commercial open source products worth considering. Be aware of the positioning of the open source community edition. In some cases the community edition is intentionally unstable and unsupported but, in many cases, the community edition is production quality software that benefits from the investment in its commercial brother. Just don't expect a commercial software sales experience.
Magnolia has a nice program for helping prospective customers evaluate their software. They have a commercially (visible source) licensed Enterprise Edition (EE) and a GPL licensed Community Edition (CE). Because CE is on the same code line and is tested the same as the more feature-rich EE, it is a legitimate option for real websites. Under Magnolia's evaluation agreement, Magnolia staff will perform the role of a software sales organization by doing demonstrations and answering questions. In return the prospective customer agrees that, if they choose Magnolia, they purchase EE. This saves Magnolia the potential risk of investing a sale and having the customer turn around and go with the free version. Potential customers that are looking for a commercial software sales experience get one and are sold a commercial product. Customers who want to invest their time and explore the different options get supported through open source avenues (mailing lists, issue tracker, etc.).
Being branded and marketed as "open source" doesn't make software inexpensive or good or bad. Open source business models simply create opportunities to unbundle the various aspects of a solution and package them in different ways. Open source vendors are experimenting with ways to package and charge for their solutions. Some companies are generating revenue from their free products, others are basing their businesses solely on their commercial products. These nuances may seem confusing to someone who is accustomed to simple comparisons of features and price in an otherwise homogenous marketplace. However, an understanding of these options is becoming increasing important to today's software buyer.
Apr 16, 2007
Last week, I was in San Francisco at the Gilbane Conference on Content Technologies. Like all Gilbane conferences, I enjoyed attending the sessions and getting together with my friends in the industry. My panel was on "Different Approaches to Purchasing a CMS: Open Source vs. SaaS/ASP vs. Licensed." (my slides). Speaking with me were Kevin Cochrane (VP of Web Content Management at Alfresco) and Jim Howard (CEO of CrownPeak). If you didn't make it, here is what you missed....
I lead off with a presentation saying that commercially licensed software, SaaS, and open source software all have their strengths and serve different kinds of customers doing different kinds of things. I got a good amount of head nodding some good note scribbling but I didn't change anyone's world. (If you were there, tell me if I changed your world.)
Then Kevin got up and the man was on fire. His presentation was about how traditionally licensed proprietary software was dead and open source was the wave of the future. He was banging on the podium (so much so that the moderator whose laptop we were borrowing was concerned for her computer) talking about the corruption and arrogance of commercial software. Kevin was one of the early guys at Interwoven and recently left to join Alfresco so he had the authority of an insider whistle-blower. He even pulled up a picture of a Gandhi and the quote "First they ignore you, then they laugh at you, then they fight you, then you win." Kevin got the audience pretty fired up and lots of people were asking how to get Alfresco.
I think one of Kevin's best points was the different economics of open source software. Commercial software is a sales driven business. Sales people stand in between the customer and the software (sometimes creating a barrier) and earn big commissions on every license that they sell (maybe not the $1MM bonuses that Kevin talked about but they can be pretty high because the variable cost of a license is very low). The open source model uses open source licensing to distribute the software. Anyone can download it and form their own opinion of whether it is a good fit for their business. Customers can also decide whether they would get value out of a support and maintenance package that the open source vendor sells. That said, not all companies are well positioned to participate in this kind of sales process. Many customers like having sales guys and sales engineers to bring the information to them. They like someone to do demos for them and to fill out their 30 page request for information (RFI). I would say that this kind of company would not be a good candidate for open source. To realize the benefits of open source, you need to be more proactive and can't rely on a sales team to bring the product to you.
Jim talked about how content management vendors should take more responsibility in customers overall success with content management - not just focus on the success of the implementation. He talked about how companies succeed or fail with content management after deployment when they are trying to use and adapt the system. I agree with his point that SaaS is very well positioned to facilitate ongoing success with content management. They can, for example, monitor who is being naughty and nice with the system or whether the software is being used at all. Of course, different SaaS vendors are going to provide different levels of hand holding. Not all customers want or would be able to afford someone observing every action, poised to intercede at the first sign of user confusion.
I think open source and proprietary software companies could do a better job providing this support as well. My old colleague Nathan Rawlins and his employer, Serena Software published a book Web Content Management for Dummies. Aside from the fact that all the screenshots are of their Collage product, the book is product-neutral and has some very good advice. Open source projects do their part with community generated add-on modules. Plus, the absence of license costs frees up resources for things like training and coaching. There is also an opportunity to build communities of business users that might derive a similar benefit to what the developers enjoy. The Drupal and Plone communities are talking about these opportunities and are having mixed success.
Jim also raised the very valid point that managing content management systems are expensive no matter what way you slice it. In addition supporting the infrastructure (servers, rack space in a data center, bandwidth), you also need people who can monitor the system and correct issues as they arise. Some companies already have these resources. For example, at Optaros, we already had the infrastructure and the staff who knew the technology. Those kinds of companies tend to derive less value from the SaaS model because they need to make the investment in people and infrastructure whether they host their CMS or not.
Those who were hoping to see contention between the panelists were probably disappointed. No Springer-style bouncers were needed. Kevin said there are many customers that would do better on a SaaS model than to use open source. Jim said that SaaS is not for everyone and some companies want the control and responsibility that open source allows. If they do this session again, I hope that the Gilbane folks put someone from a commercial proprietary software company on the panel. Put Kevin up there with an Interwoven sales guy. That would be fun.
Sep 12, 2006
John Newton's blog post on the commoditization of ECM was so good that I nearly stood up and clapped when I finished reading it. In this article, John talks about how ECM has become commoditized - not to the point where the business problems are easily solved but rather to the point where growth is flat and differentiation is vendor size rather than functionality. As with most commoditized markets open source brings an opportunity to put in infrastructure that provides basic services at reduced cost so that resources are available to invest in integration and deployment.
Alfresco is not afraid of the fact that "size matters" in this mature market with EMC, IBM and Microsoft dominating. He believes that open source gives Alfresco an advantage over the heavyweights because of reduced product development and marketing costs and faster innovation cycles. It is interesting to hear Alfresco talk about open source because they are both consumer and producer of open source and they benefit from both sides. As a consumer, they were able to quickly build their product using best of breed open source components from external projects that they can collaborate and partner with (just like any enterprise can). As a producer they are able to have a longer, more cost-effective reach because their software is freely downloadable: "Open source is therefore able to go farther and broader than even Microsoft to places that commercial software has not been to before, especially Enterprise Content Management."
In drawing parallels with other infrastructure markets, John points out the relational database software and the Java application server markets. Both of these matured into their present state of a massive consolidation of the commercial market accompanied by real opportunities for open source vendors as demonstrated by the success of MySQL, JBoss, and RedHat.
Great blog. I encourage you to read it if you have not already done so.
