Eric's Nuxeo Blog

Can Day Software Propel Adobe Towards a More Open Business Strategy?

As most involved in the broad content management market, I’ve seen the news of the week: Adobe acquires Day Software, the hot WCM vendor.

I have known and respected Day for a while: they deliver neat technology, have a clean business model and contribute significantly to open source. Plus, I appreciate the people I know from there.

Waking up on Wednesday and seeing the news starting to pour in my tweet stream was a big surprise. I thought about it a bit over the breakfast. My take: great for them, I know some people in the industry are going to hate it, but won’t be change much for Nuxeo and for the open source projects Day’s people are leading. So sent some congrats, a dinner invite, and went on my day waiting for the analysis and industry reaction overview from our great CMO later in the day. Which, in turn, confirmed my take. All good, move on. :-)

I’ve been asked a few time about my opinion and gave it. Until the last time when I thought “but what if Adobe doesn’t follow the Day way?”. Because many people have talked about Adobe closing more of Day’s technology and I don’t buy it. Developers working on the open source project are well respected, they will continue to work on those projects be it for Adobe or for an other company. So that wouldn't be a problem.

The question that started puzzling me is: What if Adobe goes onto a more open way? First reaction: That would be huge!

Imagine, for a second, that Adobe open source the whole CQ5 product. You have:

• CQ5, great WCM software considered as one of the best in its category (the best?), available as open source

• Day’s team, a team that knows how to ignite and lead communities

• Adobe’s marketing war machine to let the world know

You get a winning product, with the capacity to transform the WCM market. By commoditizing this technology, Adobe would hit hard its competition in the WCM market. Despite the fact that it would unify some of the opens source WCM crowd, EMC/Fatwire, Autonomy/Interwoven, OpenText/RedDot/Vignette/Obtree and friends would be under heavy attack.

Adobe could concentrate on monetizing global service offerings: Omniture, Livecycle, end-to-end workflows for medias, acrobat.com on steroids, more online services, etc. Commoditizing the core WCM technology would keep the competition busy and let them make money where they hardly have any meaningful competition, innovate more with new services spanning and leveraging the wide reach of their offerings. We also would see an ecosystem thrive on CQ5, providing the ignition — for free — Adobe needs to enter the market. Kinda the Google way, after all.

Actually the more I think to this and after having read Adobe’s plan for Day, I think it’s the best way to achieve it. If they truly want to create a platform for customer engagement management, this is the way. This is how the industry builds big platform nowadays, by open source software.

All this for a mere $240M and -$50M in revenue addition. That would be the slam dunk that Laurence Hart doesn’t see coming! :-)

Am I crazy enough to think that Adobe will execute this? No. And I haven't thought all this thoroughly. But that would be really fun to watch! :-)

Onto some real work now,

EB.

Business of open source: my take on "open core"

The “open core” debate has been around since the inception of the model itself, and gained significant adoption among so-called “commercial open source companies”. The debate is heating a bit these day, and I got inspired by 2 recent blog posts from Brian Prentice and Matt Aslett. I advise to read both posts to understand the reactions bellow. :-)

I think a lot about business models leveraging open source as it’s what makes our business run and I’m deeply convinced that "open core" is fundamentally flawed. This conviction has been formed by real world observations: running a real business for several years now. And I’m happy to see high-profile analysts reach the same conclusion with a sharper analysis and better process! :-)

About Sales & Marketing Savings

James Dixon from Pentaho argues — not suprisingly — that open core is the right model because it reduces the sales and marketing costs to distribute the software. And that might be true. But it is not linked to open core neither to open source, intrinsically. It’s linked to the internet distribution model and the rise of the web as a way for new and small companies to become known.

I would also add that I think the open core market is less powerful as a distribution model than a freemium (or free trial)-one based leveraging proprietary software. The reduction in sales and marketing spend is more related to the online distribution of the software than the open source aspect of “a software core”. So, of course, when you distribute a software online, you have to make it easy to install (hence improve packaging compared to traditional proprietary offerings). But it is really linked to internet-enabled distribution, not to the open access to the source code of the software.

Atlassian (or Skype) might be the flagship of success for this model... without being open source at all (but while contributing to it)!

About the “open core” model

With an open core model, you have to exclude/remove features (hence value) from the open source software to in order to preserve your business: you could be forced to even limit innovation in the open source branch because it could damage your business. It does not leverage any benefits that should be derived from the open nature of the code — which is the very core aspect of open source. It only leverage free distribution not the open aspect of the source code.

I would add that a subscription-based model (where subscription is for maintenance and support services) is superior on the long-term because it drives the company to align and organize itself around the value created for its customer. The more the customer deploy and benefit from the software, the more revenue goes to the vendor. So I think it’s a great way to align vendors and users on the same value stream.

Also, using an open source license does not require free download (advocated by open core users): RHAT is, I think, considered as the most successful company in the open source world. Yet their software is not freely downloadable, while 100% open source.

Hybrid?

I read a lot about "hybrid models", based some blend of proprietary and open source software, to justify/support an "open core" model. I don't believe in this at all. Of course, proprietary software is not going away anytime soon. It's a valuable and proven business model that works and can deliver value to customers when properly applied. Same for open source: it's here to stay for good. But the "open core" model offer no long-term benefit for customers: it just blurs the real value of open source for them, only leveraging the distribution channel it implies for the vendor benefit.

I believe in clear business models. Successful companies use clear business models because that's what enable trust from customers. Open core is not one of them: there is no clear line between open source / proprietary, neither serious justification for the customer. Open core is just the good old proprietary model, nothing new here. All vendors uses open source software today!

From a higher perspective, I believe that the whole IT market is moving toward service-based approaches — SaaS paved the way — because it aligns customer value with vendor revenue. That's why we — at Nuxeo — won't use the open core model even if it could increase short term revenue. We're here to stay and we believe that basing our revenue stream on the value we create for our customers is the best way to create sustainable growth.

Cheers,

EB.

What makes Nuxeo ECM different and worthy of interest? (No, it’s not “open source”)

Note: this post follows the previous one about the ECM market and I advise you to read it to better understand the context of this one.

What differentiates you from the other enterprise content management offerings?

I get this question regularly, and too often the expected answer is “open source”. While playing a role, I wouldn’t say that open source is what makes us different. Open source is in our DNA, but that’s not the key for our customers, nor the biggest change we’re aiming to bring to the market.

What makes us different? Our technology, the ECM platform.

This is by far our main market advantage and what we have to bring to the market: Nuxeo Enterprise Platform (EP), our ECM platform. We’ve built superior technology, leveraging an up-to-date Java stack, design pattern and modularity. This is hands down the main reason that we win deals today with enterprise architects and technology-savvy business sponsors.

The value proposition here is simple and compelling — We dramatically reduce the time and the cost of building on top of the ECM platform when compared to LiveLink or Documentum. This is why we won major deals with Jeppesen — a Boeing Company, Orange, BBC, EllisDon, Cengage Learning, Overstock.com, and many more.

We don’t try to hide from architects, we bring them back to the center of the game and give them the tools to answer challenges of the 21st century. To fully bring competitive advantage and deliver the value it promises, technology is important. We believe software is an engineering discipline, at the service of the business.

Of course, open source is deep in our DNA and brings a lot of value, ease and insurance to our customers. But from a decision-making standpoint, it plays a role but isn’t usually a key factor. The same is true for cost. Yes it is important but clearly only satisfying the functional and technical requirements are paramount. Ironically, price regularly plays against us: such as when our competitor friends have the financial resources to buy deals from us when money is key. Hence the best case for us to win is when what we offer is not achievable by the incumbents.

We offer a better ECM platform, enabling a new generation of content applications

On the platform side, our mission is to commoditize the market for “ECM platforms” with standards, widely known technology and great infrastructure. We made a strategic bet 3 years ago on a stack of technology and infrastructure that is now mainstream. So we have a great ECM platform, leveraging open standards and a well-known technology stack, highly modular and flexible. It runs on a wide range of hardware (from embedded devices in planes to large farms with terabytes of data) and serves very diverse needs (from mission-critical editorial systems for press agencies to a highly secure case management system for a nuclear agency or a mobile document repository for an offshore welding engineer.)

The net result of all this is that our platform is the most flexible and modular on the market and is widely recognized as such. This has become a great market advantage for us with the rise of content applications (CEVA/CCA: Content Enabled Vertical Applications / Composite Content Applications - as Gartner puts it and discussed at its recent Gartner Portals, Content & Collaboration Summit).

Content Apps represent a steady move in the ECM market where buyers want to buy vertical solutions, solving actual business problems. They don’t want to pour money into generic technology anymore. We are seeing a new category of ISVs, packaging business knowledge into software to create and sell those content applications (ex: construction project management, clinical facts management for biotech and life sciences, software for control and command centers, etc.). Content apps are a logical evolution of the ECM market toward more vertical, business-ready solutions. And we believe we offer a great development and composition model for the next generation of content apps.

As such, I believe Nuxeo is well-positioned to benefit from this evolution given that:

• Open source software has shown superior ability to commoditize markets, recycling big vendors’ license revenue into a new stream of value. We participate actively in this commoditization, deriving revenue for us and offering better value for the customers.
• Our platform’s flexibility and feature scope combined with the open source aspect of the software ease the life of content app architects and developers. The development model the platform offers is widely recognized and praised. We believe we can enable a new way of building content apps. Easier, cleaner, faster.
• Our business model derives value from applications built on top of Nuxeo EP (thanks to the subscription-based business model we have created).

That’s why we’re here. To offer and evangelize an ECM platform and the associated content apps, responding to the new needs of businesses in this era of information explosion.

I hope this also bring some clarification and will entice people to look beyond the “open source” label. Because there’s a lot more to discover and that could really help your business!

Cheers,

EB.

Is there room for Nuxeo in the mature and crowded ECM market?

While exchanging with a well-recognized and successful industry expert about our differentiators and the market we are in. Since they popup frequently, I thought it might be interesting to publish the answer.

ECM is a mature and crowded market. Is there really room for anything more than a niche player at this late stage in the game?

Hegemonic vendors

At a macro-level, the enterprise content market is composed by 5 hegemonic vendors (OpenText, EMC, IBM, Oracle, Microsoft) and a set of minor ones (~15 notable), after a strong and fast consolidation of this market. Gartner says: 3 top vendors have 52% of the ECM market. The Triad of ECM? ;-)

As many vendors have skipped investment in technology aggregating software from their acquisitions (with the notable exception of Microsoft) much of the current batch of software has been designed 15 years ago and hasn’t evolved much. They have forgotten they are in engineering, not retail. In this world of lean, on-demand, instant-on, the major ECM payers still talk literally in days or weeks to install their software. It’s faster to setup a whole virtual datacenter processing and storing terabytes of data on the Amazon Cloud than setting up a vanilla ECM system!

On top of this technology breakdown, many of these acquisitions have been poorly integrated, to say the least (with a special mention to OpenText on this side). And the pace of the recent consolidation has created a disturbance in the market.

Those two combined dynamics enable new vendors with good technology and the right go-to-market approach to enter the ECM arena, tickle the incumbents and rise, and bring some fresh air and fun to this market.

Perspective shift from customers

We see important shifts in how customers evaluate and choose ECM platforms:

• More and more Architects are actively involved in the choice of next-generation ECM platforms (not only business users / archive managers) and are putting it at the core of their information system. This sets high expectations in terms of software architecture, integration capabilities or flexibility and technology stack.

• They need to update systems deployed in the ’00s because incumbent vendors are not supporting those versions anymore => the cost of upgrading is high and they are looking for alternatives. Often we can offer efficient and better replacement for those systems for a fraction of the price of the ongoing maintenance. Let alone the license fees…

• Given the lack of technical investment and the legacy of major ECM platforms, implementation is complex and expensive => we can do better with today’s technology. Monolithic is no where near the state-of-the-art of software-and Architects care because it directly impacts their ability to make these ECM platforms meet the new business challenges.

Move fast, commoditize legacy, create value with the rest

I really believe that the market maturity combined with the legacy technologies of monolithic players is a key advantage for us: we are disrupting the market by commoditizing the technology (platform) and deriving value from this commoditization.

We target what hurts: the fat and comfortable maintenance stream. We target it with more flexible, up-to-date technology and a company organized to provide superior service for support & maintenance as our customers actually deploy and use our products. That’ll tickle! ;-)

So yes, I’m firmly convinced that there is a room for new players, like us. And timing seems just right for a big one. The market needs to evolve and renew, in the best interest of customers. And they well deserve it, given the challenges of the knowledge era that just starts…

That’s going to be a tough ride. But… feels fun too!

Cheers,

EB.

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.