Eric's Nuxeo Blog

Open Source vs. Proprietary Software Platforms: the Market's Perspective

Matt Asay, in the good post "Open source is a platform, not a product", is claiming the end of the platform wars because open source has won. Clearly, open source platforms are winning. Just take Eclipse (development apps and desktop apps), Java, Android, etc.

But saying that open source platforms are winning doesn't mean the platform wars are over. I would say the contrary. Platform wars will continue, and this helps innovation (if the wars stop, then I would worry actually). We'll see a lot of open source platform wars. Competition rules the world! :-)

The question is: why are open source platforms winning? I don't think it's because of their flexibility. Flexibility is a feature of a software platform open source or not. Being open source doesn't give you inherent flexibility, goodness or ease of use. Of course, flexible platforms win, and often they happen to be open source. But not always. :-)

I think the core reason lies in the intrinsic economic efficiency: open source is a better way to produce software platforms from a market perspective. It's just more efficient at the macro-economic level, factoring cost and fostering collaboration. Hence, it wins. Period.

I believe the economic efficiency aspect is key in the success of open source software, especially for platforms. And it's not pure magic. Open source licensing scheme and open development models enable collaboration between self-interested entities, which can combine forces as they need within a clear legal framework, and such without a complex initial collaboration setup and big contracts negotiation.

And as platforms are inherently meant to serve a wide range of needs and people, open source reveals its superior nature: it enables great collaboration between actors using the platform, hence aggregating their work to advance the platform.

This virtuous cycle is clearly shown by great successes such as the Eclipse Platform (the more vendors joined the game, the more Eclipse became the de facto platform for dev tools), Apache projects, Wordpress as a blogging platform, Firefox and WebKit as browser platforms (on different fronts), and the list goes on...

And, open source doesn't kill innovation. Quite the contrary - thanks to the inherent openness of the model and the competitive nature built-in (forks are an extreme example) – open source fosters great innovation.

So yes, as Matt says, for any given market segment, open source platforms win, are about to, or at least represent a significant share. But it's not because of their flexibility or because of their open source license. It's because the open source licensing scheme catalyzed by an open development model bring so much efficiency that it beats any proprietary competitor.

That's economic reality, not software architecture. And it's a lot stronger!

Commercial Open Source — Or Just a Free Demo?

I’m reading a lot recently about “Commercial Open Source” being the next great thing in the software industry. I’ve just read the presentation “Talk Slides: The Commercial Open Source Business Model” by SAP Labs's Dirk Riehle. It’s a great presentation that really captures the vision and strategy of some high-profile companies in the so-called “Commercial Open Source” arena.

In summary, the “commercial open source” business model is based on the 3 pillars:

1. a GPL (or GPL-like) software tagged “community”
2. a proprietary version of the GPL software with some “proprietary extensions” sold using a traditional license
3. a serious dose of communication efforts to explain how open source magically creates cheap great software for everyone (and that in fact you’re not really selling it) and generates a ton of leads allowing you to get to market faster and cheaper

Core myths of the “Commercial Open Source”

Here is how I analyse the core speech of the current "Commercial Open Source" model. I would be happy to hear about your opinion.

“Community Editions” you mean… “Free Demo”?

I don’t get the fundamental difference between offering a “low-end” open source version of your software and offering a free but proprietary one. Especially when I read that the “Community version” is for “developers, hobbyists and small deployments ‘cause it’s cool and fun tech” while the “Enterprise version” is for “enterprise deployment ‘cause it’s full of tests and stable code.”

Hmmm… how do you turn an untested, unstable software into an enterprise-grade, rock-solid software with “some extension”? Well, you don’t. :-) Either your software is well-tested and rock-solid, or it’s not.

If you just want to create a product line with different features depending on varying customer size, that’s fine but let’s call it this way.

Open source software generates leads, right?

Wrong. Freely downloadable apps generate leads. Free trials generate leads. Smart marketing efforts generate leads. Having access to source code does not generate leads, at least not when you are offering applications (it might be different for middleware or dev tools).

Want to generate leads? Create great software and offer free trial and downloadable software.

“It’s not proprietary software, it’s giving reason to buy when people use the software”

I love this one! Seriously. Of course customers need a reason to buy. That’s why they buy. :-)

The reason to buy is called “license fee for usage right”. It’s been around for 20 years and if you want to give people a “reason to buy” your software, just use a “license fee” for usage and maintenance. That is what it's designed for — it will save you a bunch of marketing dollars.

Open Source is good for Communities

It helps but it’s not enough. And it’s not limited to Open Source.

Openness, honesty, good software and good marketing create community. Ask Atlassian, Google, Twitter, Salesforce or even Microsoft. Not open source, but great communities and vibrant ecosystems.

“Commercial Open Source” or “Ashamed proprietary software”?

There is nothing wrong with selling “usage right to use binary software” (or more often called “license fees”…), which is what all “Commercial Open Source” vendors are doing. It doesn’t prevent you from creating great software, building a community and be nice. It just requires a bit more effort.

It's time to go public and add some clarity to all this. There is nothing wrong selling proprietary software, especially when you're contributing a lot of open source code (I’m a great fan of Atlassian and Day, in this respect). It is nothing to be ashamed of. Just be clear and focus on your software's competitive advantage rather than its open source "nature."

“Commercial Open Source” is not the business model of open source

There is no such thing as a business model of open source, by the way. There are many reason companies are producing open source software (from Microsoft to Google, from Oracle to RedHat). The only common fact: it’s a tsunami in the industry. Everybody’s using it, software vendors being the firsts. And many are producing some.

There are a lot of reasons to produce open source and a lot of ways to make money leveraging it, as some brilliant analysts and bloggers already said (two notable reading: “On open source business strategies (again)” by 451 Group’s Matthew Aslett or “Making Billions with Open Source, Revisited” by Redmonk’s Coté).

Here is how I would summarize it:

1. Proprietary software (!): Build and distribute proprietary software leveraging open source ones (be it complete apps or just extensions). Take Day Software, quietly producing tons of good open source infrastructure components, they sell a great proprietary app. Or IBM with Geronimo / Websphere. Or Oracle. SpringSource and most “Commercial Open Source” companies fall into this category too. I think it’s the easiest way to make money out of open source.
2. Support & Packaged Services: Sell support as subscription and high-value packaged services (monitoring, inventory, etc.) for open source software you’re producing. JBoss was the flagship in this business with quite a success making money with it. This is Nuxeo’s business too.
3. Proprietary distribution: assemble open source software into a proprietary stack. It’s all open source software, but the recipe to assemble the different components together and deliver a coherent and supported stack is kept secret. This can also include some “proprietary services” such as automated updates or monitoring. This is RedHat’s business. Sun seems to look toward this way too (see Solaris and the recent WebStack).
4. Proprietary tooling: sell proprietary tools that help running / operating / managing open source products. These tools are usually development tools, administration tools or deployment tools.
5. SaaS: package open source software to deliver apps as a service. This is the business of managed apps hosting (to make apps run) and packaged services (to deliver great customer support and business domain knowledge). This is also Nuxeo’s business.

So in the end, what’s the key point? Is it doing open source no matter what for the sake of hype or is it solving problems by delivering great software and/or services to customers?

I wish people of the Commercial Open Source arena would focus more on the later...; cause it does not diminish their contribution to open source overall nor does it diminish their company’s greatness and value. For the best of the open source industry. These times are about transparency and openness after all...

What do you think? I have spent 10 years in the open source software industry, building a company, living through short-term hypes and various business models. And I'm still learning. :-) Would be really happy to discuss more about all this.

Cheers,

EB.

Open Source Think Tank 09 - CIOs Panel: excerpts & comments

The round-table about “Open Source for CIOs” was co-led by Carol Rizzo from Kaiser Permanente and Michael Gallagher from ABN-AMRO. Both have successfully brought some open source software in their organization. This round-table was the right occasion to actually give some feedback on this experience and explain what’s the main issues with the current state of the open source industry, from a CIO point of view.

This talk was really enlightening about what we might be missing in our market approach, as an industry. And was pretty funny, too. Read on if you’re interested by the main topics for me and some personal opinions, of course.

Michael Gallagher, SVP Enterprise Architecture, ABN-AMRO

Michael Gallagher started as Chief Architect in a subsidiary of ABN-AMRO, and begun to introduce some open source in the development strategy of his team. He is now SVP - Enterprise Architecture of ABN-AMRO.

What has been achieved:

• An Open Source policy to define a framework to use open source software in the IT environment

• A managed central repository with all approved open source components available for developers. The repository is managed and a team is now in charge of updating packages, monitor new interesting components that might qualify to be added, etc.

• Related processes for risk management and adding component to the repository

Executive, while no being direct sponsors, supported the project and enabled the change.

Open Source is now widely used by the development at ABN-AMRO and is bringing a lot of value: more agility and flexibility in the developments process, cost reductions, etc.

ABN-AMRO IT dept is now going up the stack, onto the applicative level.

Carol Rizzo, Chief Technology Officer, Kaiser Permanente

The project started for a simple reason: many tactical apps were developed by the users with a variety of unapproved and unsupported proprietary products;   products that were not scalable or supportable, thus making the applications difficult to support.  The IT dept and the management must be able to support the applications and direct the technology environment future to assure cost efficacy and supportability. This needed to be balanced against the users desire to build innovative decision support systems they believe they need. Those tactical apps, often play a major role in the organization's mission. But it was time to assess the risks (legal, maintenance, legacy) and be able to support users.

Hence, those achievements:

• Defined a OSS policy that defines how OSS can be used and under what conditions.
• Negotiated an agreement with a vendor who will provide the OSS library, assure there is community support for the OSS, test it, send us notifications of updates, provide tools for discovery and asset management and indemnify the company if there is a legal action.
• Library of open source components that can be used to build applications
• Got a support service and indemnification for this stack (from [OpenLogic](http://openlogic.com) in this case)
• Created a training program for people interested in creating those apps

The operation is now fledgling success: users are adopting the tools and feedback has been really positive.

Unfortunately the dev teams for the central IT dept are slow to embrace the open source world.  Much more communication and training is still required to convince them, but there's hope. :-)

Personal note: I think the acknowledgment of the importance of those "tactical apps" is very interesting. Might be a new market for OSS businesses: help IT to control those apps, while enabling people's creativity.

Now here is some key quotes I’ve selected from the roundtable. They are not straight quotes, but it should reflect the general arguments. (note: I’m not a journalist :-)

Market approach: “get a marketing pitch!”

First major point: OSS need a better marketing pitch, understand what CIOs are looking at and how they buy it. Stop explaining what is OSS. Explain what it brings and what are its benefits.

Excerpt:

Stop thinking that CIOs understand tech aspects! Most CIOs understand business cases, budget management and cost control. Get a marketing pitch, guys!
— Carol

Moreover, procurement dept prefers public company because "the vendor's financials are known and the vendor's ability to sustain and grow the software is still the risk". Procurement want to assess the financial viability of the vendor. And it's easier when the company is publicly traded.
— Carol

A don't tell me about not being locked-in: as long as I have the software installed on my servers and my users have been trained and are using an application, I'm locked in. That's all!"
— Carol

CIOs need to understand what open source actually is and what it can bring to them. Moreover, OSS can be a good way for large corporation to taste Agile, and introduce Agile in their IT dept.
— Michael

OSS is very subversive for IT processes: it bypasses easily all IT firewalls. But that could be damaging for OSS. Find a way to get in with the processes. Help IT to use you. Explain the dynamics explain what you can do for us. Explain why your approach can change things.
— Michael

Even if a bit provocative (but I like it), I think it touches the right points. I agree on most of this and this matches a position we’re defending at Nuxeo since a long time: focus on your business and “open source” is as much a business as “proprietary”. ECM is our business. OSS, our development and distribution model.

I would disagree on one point: vendor lock-in. If the software is actually open source, it does not reduce the “software-lockin” but it actually reduce the vendor-lockin, especially if the later fails. If the software is mature-enough (importance of the community), you will have alternatives to change the vendor / service-supplier. This is maybe the biggest benefit when using OSS: you have an option which is not even remotely available with proprietary software.

And on “publicly traded” and vendor viability I would say that it’s not related to open source but more to large software corp vs. small ones. And if we take our field (ECM), a strong balance sheet does not really gives any inssurance of stability: vendors can be acquired by larger ones. And in that case, you’re lock-in depends on the acquirer… Except if you choose open source, where you’ll have options anyway, thanks to competition.

About IT Department

IT dept are struggling maintaining a diverse jungle of apps, while trying to cope with new users’ needs and staying up to date on the tech innovation front. They will face huge transformation and open source might help in the mix.

Excerpt:

80-90% of IT budgets are assigned for maintenance. You can’t innovate with this. And existing apps are already paid, they don’t cost so much. Change means more money. Hence, often IT can’t deliver fast enough.
— Michael

“Shadow” IT departments are created within the organization and deploy apps, because they need it. And IT doesn’t like this. But, there here for a reason. Understand why and adapt the service delivered to answer those needs. Don’t fight them blindly. IT has to change to deliver more innovation to their users.
— Michael

The fact is many IT departments are focused on control instead of focusing on enabling. Tech is clearly enabling, IT dept should adapt themselves to become an enabling organization inside the company, and drive change. Not fear it.
— Carol

Technology has come to organizations and people understand its power. Thanks to Microsoft with Excel and Visual Basic, people have started to innovate and create interesting business applications, everywhere. Don't prevent this, it's a huge advantage for an organization. IT needs to be able to support and catalyze those tactical apps, that can be very powerful to improve the organization's performance.
— Carol

This one was really enlightening because I didn’t see all of this this way. But it makes a lot of sense. I think I’ll have more to say on this later:-)

That’s all for the excerpt of the roundtable. A lot more has been said, of course. I just captured was I thought was most important.

Thanks a lot to Carol and Michael for sharing their (deliciously irreverent?) views on IT role in organization in general and open source in particular.

One of the outcome of the Open Source Think Tank 09 was the ignition of a “Open Source Trade Association”. This might be an answer to some of the issues and advices Carol and Michael gave us today.

*To come: Business Case III — Proprietary software vendor: to switch or not to switch?*

Hope this helps,

EB.

Related articles by Zemanta

• Free market, Open Source and risk mitigation (blogs.nuxeo.com)
• Open Source Think Tank 09 - Business Case "Open Source for SMBs" (blogs.nuxeo.com)

Open Source Think Tank 09 - Business Case "Open Source for SMBs"

Image by The Library of Congress via Flickr

This business case was really interesting as it’s involving an actual software user and a critical environment of deployment.

Company “A” is a medium-sized manufacturing company who needs to upgrade their enterprise software to better conduct business with partners, vendors and customers through a more seamless sharing of data and user friendly interface. Company “A” would like to remove a large dependency on a single vendor and is willing to take some risks to lower costs and reduce vendor lock-in, but is not sure how to weigh the risk vs. rewards of a different approach using multiple smaller open source vendors or how to direct/influence their principal integrators or solution providers to support that route. Company “A” wants to keep control of the solution, and therefore has decided to keep the solution in house, not hosted at a remote 3rd party vendor site.

Our group was pretty diverse: two large vendors (open source and proprietary), three small ones (open source) and a "top-CIO", which made the discussion interesting...

First recommendation: don’t start with this! ;-)
It’s pretty tough to start implementing Open Source with your ERP when you’re a manufacturing company. Start with less critical systems to get skilled, refine and assess the process.

But well, the business case is here, so okay… let’s take the challenge. ;-)

A. Can open source change the way enterprise software (especially ERP) is evaluated, deployed and serviced? Suggest one approach company “A” can take to utilize smaller open source technology components instead of purchasing the majority of the software solutions through a single vendor. What are the first 3-5 things to do to support your approach?

Open Source can certainly change how the software is evaluated. Just because it opens new horizons, risks and possibilities. As any other business innovation, basically…

So here is what we think are the must-does:

1. Get someone skilled on board, be it an external consultant or an internal resources. You need someone to guide this process and avoid the obstacles. He/she needs to be knowledgeable is all aspects of the project: business case, it projects, open source. Or build a team to merge all those skill if the project if big enough.

2. Get an Open Source Policy and a Common Infrastructure Stack: either you want to start an integration work for your ERP or take an OSS platform, you need an OSS policy (licensing, contribution, etc.) and a “standard stack” (what are the core tech choices: you don’t want a tech mashup instead of a well engineered tech stack) of components to guide the RFPs and/or your tech team in their choices.

3. Take care of Open Standard and software architecture: if you start integrating components, it’s the right time to make sure you’re building on open standards and on a well-defined and well-engineered software architecture. If you choose a platform, it helps too anyway. [Personal note: it should be the case regardless the open source or proprietary nature of the software. It’s just a good practice for your organization.]

B. Typically, mid-sized companies deploy the technology their SI or solution provider recommends. What are the top three (3) things a mid-sized company could do to incentivize channel partners (SIs, solutions providers) to accelerate development and deployment of enterprise solutions based more on open source components?

Well, money is usually a good incentive… ;-)

1. Explicitly ask in the RFP to have — at least — an alternative technical platform leveraging open source software

2. Constraint the budget allowed to license fees. In the worst case you’ll get a better deal on license costs. In the better, you’ll spend less and more wisely: actually adding real value (that actually matters to your business) to the software. And the SI will think it’s good for him because he’ll get more on implementation and support.

3. Highlight that developing an open source skill in its existing practice will give him a competitive advantage compared to other SI. And other company of your field might also consider this way if your experience is positive.

C. Are the decision factors and priorities (e.g., acquisition costs, vendor lock-in, maintenance costs, risk of software failure running the business, risk of vendor going out of business, etc…) the same when comparing traditional ERP solutions vs. multiple, open-source based software solutions? If different, name the top 2-3 factors that would be prioritized differently.

Well, from a business perspective, it’s alway a balance between cost, gain and risk. From that perspective, it doesn’t change actually. But there is new factor you need to take into account:

1. Check the community size and the actual software adoption in the world. This give resilience to the open source software. This resilience is a protection from vendor failure (or acquisition) you wouldn’t hope for proprietary actors (small and big). If the main vendor/maintainer fail and there is a market for support and innovation around this software, the market will do its work and players will propose services and maintenance. The community is key here, it gives you a way to be sure of the resilience the software will have, hence drastically reducing the vendor lock-in.

2. Assess that the SI can actually deliver support for the software. Require he gets the right contract from actual maintainer of the core software. You don’t want to be stuck because the software has a bug and the SI cannot deliver the right skills to fix it. Open Source Vendors exists for a reason. ;-)

3. Benefit from the speed of innovation you can get from open source: influence the roadmap, ask for generic features to be contributed back on the main code line (hence reducing the specific code you’ll maintain), understand how you can benefit from ongoing work on the software.

D. Is a SaaS model always preferred for an SMB company looking to utilize open source enterprise applications due to the high risk integration costs? Under what circumstance would SaaS NOT be a preferred alternative for an SMB with similar dynamics?

General answer: don't seem to be interesting for the case, but would need to dig into it. And it would require a complete business case only for this.
One key point, though: do not loose the flexibility of the software and the control on your data that the open source approach is giving you.
[Personal note: using SaaS for your core ERP does not make sense to me except if you don't need customization and flexibility and that your completely trust the provider to not loose / keep your data.]

Done! :-)

I tried to represent what was said. If I forgot something, comment. And if you have reactions to those results: same.

Happy implementation!

EB.

Related articles by Zemanta

• UK Government backs open source (news.bbc.co.uk)
• Open Source Think Tank 09 - Monday Report (blogs.nuxeo.com)
• Gartner: open source software 'pervasive' (theregister.co.uk)

Open Source Think Tank 09 - Tuesday & Thank you!

Image by Julie, Dave & Family via Flickr

Today's been the last yet most productive day. Very intense. We had two brainstorming sessions on Business Cases, one great talk about "Open Source and Fortune 500 CIOs" (by two of those top CIOs) and one open discussion about doing marketing as an Open Source Industry. And the results are actually so interesting that I'll report/discuss them in separate posts.

The lunch was pretty innovative. Much like speed dating. Open Source Speed-dating! (I should go to a VC with this idea! ;-) It fostered networking and worked pretty well. I think many people discovered great companies and great people, exploring this new horizon in the software business.

The afternoon lead us to the second Business Case of the day and to an open discussion on whether we should or not do some marketing as an industry as a whole, using some kind of trade association, focusing on open source business. This question comes back on the table for the 3rd year in a row. But now the answer is a loud and definitive: yes. Some work started on this, let's see where it goes now. But things are moving around this. And I think it might be a major step onto global awareness of CIOs. Something huge has been ignited today, hopefully... :)

After all this work, volunteers have been kindly invited to another wine tasting session at a nice Napa Valley's vineyard, for a casual closing party. Was relaxed and entertaining.

SO, now the event is closed, what the general impression? I would say: inspiring, hopeful and productive yet fun. I had the chance to meet quite a few very interesting people and to start some interesting discussions. Let's see where it goes, but the event is a clear success from my perspective.

Thanks to the Olliance Group, to the sponsors and to all participants. I'm excited to see you again in Paris for the next session of the think tank and see where we'll be. Growth is around us, for good! ;-)

I'll be posting more detailed post on the two business cases and the talk of the day in following posts. Don't hesitate to comment or drop an email if you'd like to get more information.

Thanks Napa... onto Paris now!

EB.

Open Source Think Tank 09 - Monday Report

[Update: for french readers, a translation is available here]

Well, it’s actually day 2 of the Open Source Think Tank 09, but I wasn’t able to attend to the whole first afternoon because of some travel trouble. Apparently I wasn’t alone: the audience grew by 35% today ( this from visual impression, not real data). I’ll report on the insightful talk by Mark F. Radcliffe in a specific post about legal aspects of the OSS ecosystem.

Overall I think the audience is skilled, smart, experienced, very available and open to the discussion. And we're all here because we're involved in the business of open source. The level and the number of my fellow attendees show how much the open source ecosystem has grown for the past 2-3 years. There is serious business being done here, more than ever, and it's just the beginning.

So, to get back to today’s session…

Business case “how to a business leveraging an open source project?”

We started with a “Business Case”, where the audience is divided in workgroups (of 6-8 people). Each group works to answer a set of questions and when time's up each group presents the results to the audience. It’s interesting to compare the results, obviously, and highlights the differences, that are usually interesting takes / ideas.

Today’s business case was about “Start a software company from scratch, leveraging a popular open source project”. Here is an extract:

Company “C” is a recently established venture-backed commercial open source company looking to capitalize on a very successful open source GPL-licensed project with a large supporting community. Company “Cs” application is principally a commercially supported version of the project, with development focused on productizing the project and developing plug-ins that make the product more directly applicable to a specific set of customers they are targeting.

The community is mostly developers from a wide variety of backgrounds – about half are individual contributors to the project, and half are contributors from companies that see a potential use for the technology within their company and for their customers, both end users and SIs and ISVs. None of the key developers is interested in “new” employment, feeling they can best run the project from their current positions. Company “C” currently does not employ any of the major contributors. Company “C” has developed a product roadmap that extends the product into a fully functional set of applications targeted at global retailing. They have received very positive feedback from several beta sites that have deployed the new applications. Company “C” however, has not formalized the sales and marketing strategy beyond a few “proof of concept” beta sites and is looking for guidance on how they should launch their product in the face of a community that has no established relationship with Company “C”.

The first reaction to this from open source vendors was: “I want to talk to that VC guy!” because investing in a company wanting to build on an open source project without being involved whatsoever in its ecosystem is pretty bold move… :-)

To complete this, most of the groups made the following assumptions:

• what the company is really doing is making a vertical product on top of a generic platform

• while being GPL, the project allows to build proprietary plugins / extensions

• there is no other company involved in the project that might offer a similar product / service

From this, here is what came from the groups about the following questions... [note: I'm summaryzing, the main points resulting from the brainstorming. I might have forgotten / misunderstood some, so don't hesitate to correct / comment.]

A. How should Company “C” approach the community? What are the 3-4 must do?

1. Get involved without antagonizing the team: communicate often, be honest, explain your intentions and where you’re going [Personal note: I think this is valid when starting any business, OSS or not]. Also, keep a low-profile and do some work. For example starting with some “easy but boring work” that nobody took the time to do, might be a good start. And again, communicate, keep  the core developers posted about your experience, successes, failures, feedback from actual customers/end-users. Developers usually like to know how people actually use their product.

2. Get goodwill: proposes bug fixes, propose extensions / evolutions, participate in architecture debates. You might also pay some consultancy work from core developers. Your work needs to be of  interest to the community, some of the company’s plugins might be open source too.

3. Have a distinctive identity: don’t steal the project’s popularity (by using its brand without asking for permission), differentiate your offering by addressing a different market than the project’s one, do not compete with an already established and recognized company

4. Become a contributor: if you’ve followed the previous 3 items, there is good chance you’ve got committer-level access rights. If not, since the core team cannot be hired (it’s in the assumptions), you can try to hire non-core developers that are yet involved. Offering them to work full-time (or a lot of time) on the project might close the deal and let them be more involved, getting more weight in the community.

So globally, it’s like most things in life. Don’t be rude, stay open and fair, work hard. That’s all it takes. People involved in OSS project are normal human beings, after all. ;-)

B. How critical is it if the open source project leaders don’t commit to incorporating Company “C” contributions in a timely manner? How can this best be managed?

Is it surely critical if you can’t get your patches in the product fast enough. You can manage it by talking with the core team openly about this issue. Understand why your patches are not going in faster: might be a problem of process, quality, doc, direction, etc. Fix it and you’ll get your patches in. If you’re doing a good job and that it’s just a lack of resources from the core team, there is a good chance you’ll get committer rights.

C. Is it important for Company “C” to take control or fork the original project? Under what conditions might this be the case?

General consensus: never fork for any reason.
Especially when it’s done like a “declaration of independence”. It will attach a nasty reputation to the company and you’ll have to make a lot of effort to get rid of it, plus do the usual amount of work required to make an OSS project successful. So it’s usually a very bad idea. [Personal Note: I’m not aware of any successful fork from a community project, so take this recommendation seriously].

There is several ways to work faster than the project, is you need to. First, you can maintain and make public a “vendor branch” of the core product. And anyway, you’re gonna need it, technically, to work easily and propose patches. Making this branch public and how you advertise it is the key here. Present it as an “experimental branch” or as your “dev branch” from which you can propose consistent patches and let people get involved with your work and contributions.

So don’t fork and work openly on the code. If you’re producing good code, there is a good chance other people will notice it and it will give you traction and weight in the project.

D. Under what circumstance would involving a standards body make sense?

Simple answer from all groups: “none”. :-)

More seriously, a standards body might make sense if you want to standardize an existing protocol/model, which might be the case as the project we’re are discussing is already mature and popular. An example of this is Jabber Inc. standardized its Instant Messaging protocol after having worked with it for a few times and open sourced the implementation. And it was a wise decision, creating value and growth for the company (as well as for all vendors/users that are leveraging the protocol).

E. Can you identify one or two situations where prioritizing the community over its product roadmap (and customer base) may make sense for Company “C”? What are they?

Interesting question, too. The answers were pretty much the same, here:

1. If you’re proposing a contribution and you get the answer “Good idea but I would prefer to see it done on another way, could you change this before I integrate it?” from the core team, it makes a lot of sense to do it even if it delays your product a bit.

2. Keep aligned with the core product and avoid maintaining a fork, which can be the easy way when you’re in a rush for a delivery. Don’t forget to reserve time to keep up with the development of the core product, and port your patches on it. It’s a short term pain / long term gain.

And keep in mind: what strengthen the community strengthens your business.

Talk from Mårten Mickos and Mike Olson on “Exit & Acquisitions”

For the newcomers to the OSS ecosystem, Marten is the former CEO of MySQL (acquired by Sun for ~$1B) and Mike is the former CEO of Sleepycat (acquired by Oracle for an undisclosed amount — where undisclosed sounds like a nice one).

It was a great talk about selling an (open source) company to a large corporation. How the process starts, how it has been managed, how it feels like to sell, how life changes, how it feels after... and many other topics! I won’t transcript the whole talk here, because I’m running out of time. :-)

It was a very interesting, inspiring talk and discussion. Enjoyed it a lot. Thanks to Marten and Mike for sharing their experience.

Wine Tasting & Dinner

I wasn’t able to attend to the wine tasting session scheduled in the afternoon, because of some important business commitments. But I heard great feedback! (no kidding…)

The dinner was pretty good and allowed me to engage fruitful / funny discussions with some great people of the OSS world. Sharing experiences and vision about open source business, or just talking about where I should go next time I’m in L.A.

Not sure I can put names here because of the (wise) blogging policy of the think tank, but it was fun and interesting. Thanks to all the people at the table (and others too, btw).

So far, great experience. Interesting discussions. Don't hesitate to comment on this post if you want to get involved / react to the discussion that has started here, in Napa.

See you tomorrow, for the next episode! :)

EB.

Open Source Think Tank 2009 (and meet up availability)

I’m landing in San Francisco to attend to the Open Source Think Tank 2009 taking place in a nice hotel in Napa, CA. (I know, it’s going to be a tough time… ☺)

More seriously, it’s the first time I attend to this think tank and have great expectations: the world’s economy is a mess, the IT industry is changing, Open Source is maturing. It’s going to be very interesting to discuss business models, delivery models, patent issues, sales process, etc. with major actors of the world’s OSS ecosystem. And after reviewing the impressive attendees’ list, I confirm there a lot of smart people in this resort for the next 3 days. Must be fruitful and highly stimulative.

I’ll try to keep twittering about the event and posting feedback / thoughts on this blog.

If you’re also attending and would like to meet, don’t hesitate to drop an email. And if you’re not attending, I’ll be in California for the week so if you’d like to meet somewhere in the valley just drop an email too.

See you there,

EB.

PS: BTW, I highly recommend Virgin America. First yet great experience.

Free market, Open Source and risk mitigation

Image via Wikipedia

I had an interesting chat at lunch with Christophe Laganne (eWeek Europe) and Olivier Rafal (IT News) about various updates from nuxeo and we quickly came accross the Autonomy acquiring Interwoven topic in particular, and software market consolidation in general. I had a chance to expose my views about risk levels and risk mitigation when investing in software (“investing” as in “choosing and deploying a software platform to run a critical part of your business”). I thought I could take this opportunity to develop a bit on this topic, here.

Risk mitigation is a major concern for CIOs when choosing the software that will make (part of) their business run. Choosing this kind of software (and with ECM this is usually the case) is a life-long wedding. Risks have to be well considered and mitigated if something goes wrong or it can result in a really painful, if not fatal, experience.

I think Open Source can play a lot in software-related risk mitigation strategies, for a simple reason: choosing a successful (as in “actually deployed and used”) open source software and/or vendor is much safer than almost any software from a billion-dollars vendor. I know I have obvious interest in this case, but I’ll try to make an honest argument. :-)

A software is a market

One can consider each software as a market in itself. Choosing a software is entering this market. Vendors, service providers, customers and users are actors of this market.

With proprietary software, when you select a software you enter into a controlled market, ruled by one main actor. The software vendor’s own monopoly. When a proprietary vendor goes down, is acquired or simply releases a non-compatible new version, customers have a risk to be forced to spend a lot of money adapting / migrating (usually meaning re-doing) their projects. And the size of the vendor is a detail: it doesn’t really have any impact on what happens for customers. How would you feel as a Hummingbird customer? Or as a Stellent one? Or as an Interwoven one? I would be worried. And I would be worried too if I would be using software from OpenText, since market conditions have turned them from a predator to an attractive prey.

I don’t like monopoly. It usually hurts — trust me, I’m French, I know a lot about them, we had plenty around… :-).

With Open Source Software, it’s a totally different story. When you select an open source software and/or vendor, you also enter a market. But a free one (as in free market, not free beer ;-). There is no monopoly anymore. When a software vendor goes down, stop supporting a software, change direction or — better for them — get acquired. It actually impacts the market by creating new needs around the software: customers want support, bug fixes, improvements, maybe even new versions or just more confidence in their providers. And as in any free market, clever entrepreneurs can make some money providing those services and products to demanding customers.

Free market at work

3 years ago, we were a tiny open source vendor and our software, CPS, was a successful open source content management platform, based on the Zope app server, widely deployed in the public sector in France and Europe (when I say widely, I mean thousands of instances in production, many of them being still actively used and maintained).

At some point, we were planning to make a major new version of the software, to transform it into a full-scale ECM platform. The choice of the technology came and we considered migrating our code base from Python to Java. Debates were intense and the decision was difficult. But for many reasons we decided to switch to Java. It was a tough move and a big risk for our company, hence for our customers. But we thought it was the right way for us and our customers in the long run. So, we’ve started to work and announced our intentions to the public. We’ve explained the move to our customers, committed on 3-5 years (minimum) support for CPS — Three years later, we are really happy of our decision back then, we've made a tremendous enterprise-grade ECM platform, and we are still maintaining CPS and supporting our customers that are still using it.

After the announcement, some customers and users were concerned about our move, thinking that we would not be enough committed on the support because of our new technical direction. And I can understand that, actually. So what happened? Well, several companies (Nuxeo’s partners or companies hiring some of our ex-employees), started to offer standalone support for CPS and some even sending patches and participating in the maintenance of the software. Free market at work.

Most of our customers kept their confidence in our company — thanks to them — and continued to work with us, but some choose another way. And it’s great. The move was obviously a risky move for our company and it could have failed. But our customers were — and still are — protected from our failure thanks to the good ol’ free market. Even if in that case, good for us, a radical solution hasn’t been required for our customers since we’re still there, live and kickin’ with a great ECM platform. The market has, at least, served as protection of our customer investment and added confidence in our market. Maybe it also helped us to stay committed on the support of our legacy platform.

And there is a number of examples where Open Source has protected customers from vendors’ troubles. Take a look at db4o, acquired by Versant, at Sleepycat and Inno, acquired by Oracle, at Zimbra, acquired by Yahoo, or at Xen, acquired by Citrix. I’m not worried as a user of these software neither as a customer of some of those vendors. It would have been a very different story if they were proprietary ones.

Great benefits for IT buyers

What happens in the proprietary word? If your small vendor decides to rewrite its software onto a new platform and fail: you’re screwed. And what if your big vendor gets acquired by a bigger one: screwed too. Same story if your vendor just wants you to upgrade because you’re 2 versions late and he doesn’t want to support the version you’re running on anymore.

Open Source offers a unique way to secure your investment in software, not relying on wishful thinking but on actual well-known and proven economic mechanisms. And this might be a major improvement brought by Open Source: transform a monopoly controlled market into a free market. Of course, it’s more difficult for vendors but it brings so much more value and confidence to customers, software users, IT buyers.

I really think this perspective should be considered if you need to choose a software on which your business relies to run its operations.

I would be pleased to engage a discussion if you have comments on this topic. I’d love to develop further.

Let them free! ;-)

EB.

Seth Godin on competition: support it or fear it

Seth Godin has a great and insightful post about competition:

Some businesses prefer to catch you when you have no choice. They use market conditions or even patents to ensure that they can be the bully. I'm not sure that there's anything wrong with this, but I'm certain that it is a deliberate choice.

Other businesses, like Amazon, do better when they have lots of competition. Amazon has made it easy for other vendors to use their technology platform and even to sell items on their site. Why?
Because they understand that more competition brings more attention, more business, more commerce. And since they are organized for volume and are eager to compete, more competition helps them.

Seth is talking about Amazon's strategy vs the one of most online merchants. But he might be very well talking about open source vendors vs. proprietary ones...

Internet fosters competition. As open source does. We (open source vendors) like competition. We were born in this environment. We get our customers by providing value to them and we are keeping them by not stopping to. Unlike proprietary vendors, used to old ways: get customer through a low-priced entry ticket and lock them thanks to an overpriced exit ticket. It has worked long enough.

Old times are gone. The software industry is growing up, as customers are demanding for more. Lock-ins have lived. Open source is one of the results of this evolution. And part of the solution: stimulate competition to make solutions more efficient. The Operating System market got its stimulus (Linux has transformed it), followed by web app servers and many more. Now the mobile market is getting it too (in no particular order: Google releases Android as Open Source, iPhone's OS is heavily based on open source software, Symbian will be released as Open Source, Palm embraces Linux, Linux becomes a mainstream mobile platform). And I'm at the right place to see (and help) it coming to the shores of ECM.

The future, for vendors, is about leveraging competition, not preventing it. And I'm thrilled to see this coming!

Let's compete!

EB.

On Open Source's business models and broken toys

For several months now, the new hype for some “Open Source VIPs” (usually people having been involved in some form of “Open Source activities”) is to tell how much Open Source is not pure anymore (now that it is generating business and is widely spread and done by successful companies). How badly the Open Source model is hurt. And to what extent the model is broken, dead, not working. The last example is this article from Stuart Cohen in Business Week gives me a nice opportunity to express my views on the topic.

So for those who think the model is broken, please read on! For others, please read on too. And for both, comment if you like, I value you opinion. :-)

Alive and kickin’, Open Source’s stronger than ever

Time to go back to fundamentals. Hence, here we go… Let’s imagine Open Source software were not working, here is how you would notice:

1. You wouldn’t get much email delivered into your inbox

2. You wouldn’t be able to surf the web, and would sadly abandon facebook and 95% of your web apps (the one you now can’t live without)

3. You wouldn’t be able to use the Internet at all (since your computer wouldn’t be able to even find servers’ addresses)

4. Most of your enterprise network would just be broken (remember the tiny box with Linux inside…)

5. Most of your enterprise apps would be down too, anyway (Yes, Java and PHP are OSS)

…funny day at the office, right? Kind of a remake of “The Day After”… ;-)

You’re using open source code everywhere, for most of your daily tasks involving computers (or mobile phones, game console, etc.), without noticing it (see, it works… ;-). It’s become the blood of the software industry. From tiny, yet critical, bits like network protocol stacks, compilers, print servers, http servers, mobile phone firmware or OS kernels (Linux, anyone?) to large enterprise software like Eclipse IDE, MySQL, Java, OpenOffice.org, Firefox, and a dozen more (including Nuxeo, of course!).

OSS being there, live and kicking, someone has to produce it. A model must exist: Open Source code does not magically appear from nothing. People are producing it, and the vast majority of them get paid for their work.

Proprietary software’s dead: there is no pure proprietary software anymore

Most proprietary software rely on, embed or leverage OSS bits. Same for software available as SaaS. Even Gartner states that by 2012 more than 80% of the code released by software vendors will include open source bits. Still, from my experience, it’s way bellow the truth…

Given this, there isn’t a big step to state: As there are more “pure open source” than “pure proprietary software”, the Proprietary Software model is broken.

Is it? No.

And, by the way, there isn’t one proprietary model. There are many. Same, there isn’t one open source model. There are many! The world is diverse, business models too. And that’s good.

Proprietary software models delivers value. As do the Open Source models. Actually, this is the key point: the value delivered to customers. And it’s not enough highlighted in those endless “proprietary vs. open source” trolls.

It just seems that OSS models are delivering more value for less money than their proprietary equivalent. But that’s another argument. ;-)

Not pure enough…

One thing I can’t stand to hear is “this open source software is not pure enough”. Pure enough. Period. Or “this open source software is not real open source”. Real. Period. “Real”, “Pure”. Hey, It’s not weed, man. It’s software! And business.

You know what? The exact same code can be proprietary or open source. Its licence defines it. There is no notion of a “purity-level”. There is an OSI-approved open source licence or not. End of the story. All other considerations are business-related considerations. And it is really important, but does not impact the “open source”-ness of the software.

What matters then is the behavior of the company, the price of a deployment, the level of support offered, the list of features available, etc. As for proprietary software I would say. And it’s normal, those aspects are the ones defining value the software will bring to customers.

And at the end, the choice is made based on the good old value/price ratio. Because this is what matters. If Open Source Software delivers it, it’s great. No matter if it has been created by a pure service company, a big software vendor (like Sun or IBM), a company using an hybrid model, a company delivering proprietarized open source (like RedHat), a non-profit Foundation (usually gathering and mutualizing work force from software companies, like Eclipse or Mozilla) or a pure informal open source group (like for the Linux kernel).

Purity matters for crystal, gold, diamonds or oil. Not for business models in the software industry. Value does. And it would be great if we all could not forget this. Because this is what customers are expecting. Value matters. And as long as value is created, the model is valid. Customers are the judges, and they like it.

Of course, maybe Stuart just want to attract some attention for his new startup trying to sell people the development model that has freely emerged with open source. Business’s good, for sure. But… don’t bite the hand, Stuart, don’t bite the hand…

Keep the faith! ;-)

EB.

Related articles by Zemanta

• Waiting for the Next Generation of Open Source Business Models
• Report Says Pure Open Source Is No Longer a Viable Business Model
• Sun clarifies its open-source model