Tag: Community

Would the commercial open source software you depend on survive a zombie apocalypse?

2596483147_58d6bae3b1_mPick a commercial open source software product that’s important to you. Now imagine that there’s been a global zombie attack. Fortunately, after much heroics and stylized cinematic violence, the attack is eventually thwarted. Unfortunately, it wasn’t soon enough. Everyone who receives a paycheck from the company behind your favorite commercial open source company is now a zombie in the steadfast pursuit of acquiring brains for food–they could care less about your sev one support ticket. The question is this: Can the open source software project survive without its commercial backer?

My blog readership consists of multiple audiences. For some of you, the question posed is interesting because your company depends on that software to run its business. For you, this is a “sole source supplier” problem with the primary concern being: If the software vendor goes away, is there another place I can get the same software?

Some of you are like me–you provide professional services around commercial open source software. The commercial company produces the software you deliver to your clients but may also provide other types of assistance such as marketing, business development, and training.

Still other readers might be classified as “community members” who give time and resources toward the project. Members of the first two groups are often members of this group as well. It is this group–the community–that becomes critical in answering this survivability question as we shall soon see.

Okay, so back to the scenario. Zombies attack. Zombies subdued. Sadly, all of the employees of our commercial open source software vendor are no more. Why is the question of survivability even a question? Remember, we are talking about open source software with a primary commercial backer. Your organic open source projects are safe from zombie attacks, for the most part, because there is no single company responsible for its development. For organic open source projects with a large, healthy community, the load of building and maintaining software is distributed across potentially hundreds or thousands of individuals employed by many different companies. Commercial open source, on the other hand, has a single company that pumps significant dollars into engineering, research and development, sales, and marketing. If that company goes away, there’s a clear risk to the project. Stakeholders need to understand this risk.

For the rest of this analysis, I’m going to ignore the very real investments commercial open source vendors make around marketing, business development, community management, and training. These things matter, of course, but they don’t matter at all unless you ship code. As the smoke clears from the zombie attack, the single most important thing facing the surviving stakeholders is getting out the next release.

Suppose our zombie-stricken company sold support for what was already an extremely successful open source project. There are many people who regularly make very significant contributions to the code base and documentation. There are lots of people answering questions in forums and on IRC. That healthy community means there is a viable population of non-zombies who will obviously mourn the loss of their former collaborators, but will no doubt bravely carry on.

Now, instead, imagine a commercial vendor who is really open source in license only–they lack a community entirely. There are exactly zero people outside of the company who know anything at all about where to get the code and how to build and test it, let alone the intricate details of how it works. It’s clear this project is doomed. Maybe someone would fork the code base and start a new company but that would be tough. Unlike what MariaDb did after the Oracle-MySQL acquisition, our scenario doesn’t allow a new company to bootstrap with experienced founders or engineers, at least those who were employed by the vendor at the time of the zombie attack.

From looking at these two extreme ends of the spectrum it is clear that the thing that allows the project to continue is the viability of the project as an independent open source project and that depends on the health and makeup of the community.

To answer this question–whether or not a commercial open source project could operate as an independent organic open source project–there are several aspects of the current community to assess:

Pre-commercial open source success. If the software project was a successful organic open source project before the commercial company appeared, this is a good indicator that if that company were to go away, the software project would survive.

Governance model. Is the software and associated trademarks under the control of an independent foundation? If so, that’s good–a lot of the details and processes will already be taken care of. Formal governance of this sort is designed around ensuring viability independent of a single commercial backer.

Number of external committers. How many committers are employed by the commercial company? If the answer is 100% that’s bad for survivability. In our scenario anyone working for the company is now a zombie which means there will be fewer experienced people to work on the next release.

Number of external contributions. What kind of contributions have typically come from the community? If it is low volume or mostly insignificant patches, this is another negative indicator. If the project stands a chance of survival post zombie attack it needs significant activity from independent contributors because that provides a population of people who are familiar with the technical details of the product.

Install base. A product installed in a large number of big companies would be ideal but even a few large “anchor” companies would be sufficient. The surviving community will need to pool its resources to move the project forward. If it is strategic to stakeholders with deep pockets, those stakeholders may be willing to invest in the software’s future.

Product complexity. The simpler, the better. When a product gets complex, its engineering team starts to specialize. A large community could do that too, but if the product is complex and the surviving community is too small, there may not be enough people who can go deep enough on every part of the system to maintain the entire thing. A complex product also requires more resources to test and build.

Upstream dependencies. If the product is a relatively thin veneer on a handful of well-known upstream dependencies, that’s good. It means you might be able to depend on some of those upstream communities for help. However if the system is complex and has a lot of smaller dependencies, it means the surviving community has a lot to learn and the upstream communities may lack the resources to be of much help.

Downstream dependencies. If the software is used by many other projects downstream, that’s a good thing because it significantly increases the number of people interested in keeping the project alive.

Company diaspora. How much turnover has there been over the life of this company’s engineering department? Low turnover means there will be fewer people in the market who know the deep dark secrets of the code base.

Community makeup. This is closely related to the “external contributions” aspect. If the community is mostly “power users” that’s a problem for survivability. What you need is a community that has a significant number of individuals who are passionate and technical enough to dedicate time and resources to moving the software forward. It obviously helps if the software is strategic to their employers.

You might assess your favorite commercial open source software and realize that it isn’t viable without commercial backing. That doesn’t mean it’s a bad company or a bad product. What it does mean depends on your perspective:

If you depend on the software for your business…

  • And you are evaluating the software for purchase, you cannot give “availability of source code” a much higher score against other alternatives because one of the benefits you derive from that–the ability to continue forward should the company go away–is less likely to be realized. (see “Why Clients Choose Open Source”).
  • And you already have the software installed, have a backup plan in mind should something happen to the vendor, just like you would a proprietary vendor. If you deem a major event to be likely, consider moving to an alternative now.

If you are part of the commercial open source software project’s community…

  • Push for changes in the aspects identified above that would make the project more viable as an independent project. Realize, however, that not all vendors are enlightened (or empowered) enough to execute these changes.
  • Be okay with the fact that you are dedicating time and energy to something that depends mostly (or entirely) on its commercial backing. This means not getting bent out of shape when the commercial company does something to further its commercial interests. Or don’t be okay with it and move on.
  • Assess your zombie attack survivability as a community and identify initiatives that address areas of weakness.

If you are the commercial open source software vendor…

  • Be careful how you market your open source-ness. If your software fails the zombie survivability test but you tout open source as a major advantage, your marketing message may ring flat.
  • Be open to ideas that could give your software the ability to outlive you. This makes it more attractive to customers and community members alike. It makes your open source claim more genuine.

Obviously the specific threat of a zombie attack is far-fetched. But the risk of a commercial open source company being acquired, folding, or radically shifting their business model is quite real. Just because “commercial open source” has “open source” in it, does not magically give it a vibrant community that can fulfill the vital engineering and quality assurance role that the commercial company often provides. Even a vibrant community may lack the proper make-up to step in should it need to.

Regardless of which role you play, if you are a stakeholder in a commercial open source software product, it is important you assess this risk and have a plan should the need arise.

Alfresco cancels Summit, asks community to organize its own conference

summit-community-editionEarlier this week, in a post to a public mailing list, Ole Hejlskov, Developer Evangelist at Alfresco, announced that the company will not be putting on its annual conference, Alfresco Summit, this year as originally planned. Instead, the company is focusing on smaller, shorter, sales-oriented events which have been very successful in several cities around the globe.

Ole said that Alfresco will be adding developer content to its Alfresco Day events, which have historically been mostly end-user and decision-maker focused. In contrast, Alfresco’s yearly events started out as developer-focused conferences, but in recent years had a more balanced agenda with both technical and non-technical tracks.

Alfresco had announced earlier in the year that their annual conference would be in New Orleans in November. In each of the last five years the company put on two conferences–one in Europe and the other in United States. For 2015 the plan was to have a single conference only in the U.S. which drew criticism from the community that skews heavily toward a non-U.S. demographic.

When the community realized Alfresco Summit 2015 would be held only in the U.S., an independent community organization called The Order of the Bee began making plans to hold their own conference in Europe. Alfresco says it will support the community’s efforts to hold its own event and wants to explore “…ways in which participation from Alfresco corporate makes sense”.

I understand where Alfresco is coming from. Annual conferences are expensive in both real dollars and the time and attention it takes to plan and execute. When you multiply that times two it obviously represents an even bigger investment.

You also have to look at what Alfresco gets out of the conference. Alfresco is increasingly sales-focused. The conference has historically been focused on knowledge-sharing and camaraderie. Yes, there were deals closed at Alfresco Summit but it was not geared towards selling. It was more about coming together to share stories, good and bad.

The Alfresco Day events are unabashedly sales and marketing. The attendees (and they get very large turnouts) know this which means Alfresco does not have to apologize for coming off too sales-y. Multiple cities with hundreds of prospects is a better investment for them than two cities with 1400 attendees who are existing customers and community members.

As the guy who led DevCon and Alfresco Summit and together with my team grew it year after year, it is weird to see Alfresco cancel the conference for 2015. I was looking forward to attending.

As a member of The Order of the Bee, I’m intrigued by the challenge of using an all-volunteer organization to potentially put together a replacement conference of some sort. If you have any interest in helping and you did not see my email to the mailing list, we’ll probably be meeting next week to get organized. Reach out to me and I’ll add you to the invitation.

The plain truth about Alfresco’s open source ethos

There was a small flare-up on the Order of the Bee list this week. It started when someone suggested that the Community Edition (CE) versus Enterprise Edition comparison page on alfresco.com put CE in a negative light. In full disclosure, I collaborated with Marketing on that page when I worked for Alfresco. My goal at the time was to make sure that the comparison was fair and that it didn’t disparage Community Edition. I think it still passes that test and is similar to the comparison pages of other commercial open source companies.

My response to the original post to the list was that people shouldn’t bother trying to get the page changed. Why? Because how Alfresco Software, Inc. chooses to market their software is out-of-scope for the community. As long as the commercial company behind Alfresco doesn’t say anything untrue about Community Edition, the community shouldn’t care.

The fact that there is a commercial company behind Alfresco, that they are in the business of selling Enterprise support subscriptions, and at the same time have a vested interest in promoting the use of Community Edition to certain market segments is something you have to get your head around.

Actually there are a handful of things that you really need to understand and accept so you can be a happy member of the community. Here they are:

1. CE is distributed under LGPLv3 so it is open source.

If you need to put a label on it and you are a binary type of person, this is at the top of the list. Alfresco is “open source” because it is distributed under an OSI-approved license. A more fine-grained description is that it is “open core” because the same software is distributed under two different licenses, with the enterprise version being based on the free version and including features not available in the free version.

2. Committers will only ever be employees.

There have been various efforts over the years to get the community more involved in making direct code contributions. The most recent is that Aikau is on github and accepting pull requests. Maybe some day the core repository will be donated to Apache or some other foundation. Until then, if you want to commit directly to core, send a resume to Alfresco Software, Inc. I know they are hiring talented engineers.

3. Alfresco Software, Inc. is a commercial, for-profit business.

Already mentioned, but worth repeating: The company behind the software earns revenue from support subscriptions, and, increasingly, value-added features not available in the open source distribution. The company is going to do everything it can to maximize revenue. The community needs this to be the case because a portion of those resources support the community product. The company needs the community, so it won’t do anything to aggressively undermine adoption of the free product. You have to believe this to be true. A certain amount of trust is required for a symbiotic relationship to work.

4. “Open source” is not a guiding principle for the company.

Individuals within the company are ardent open source advocates and passionate and valued community members, but the organization as a whole does not use “open source” as a fundamental guiding principle. This should not be surprising when you consider that:

  1. “Drive Open Innovation” not “Open Source” is a core value to the company as publicly expressed on the Our Values page.
  2. The leadership team has no open source experience (except John Newton and PHH whose open source experience is Alfresco and Activiti).
  3. The community team doesn’t exist any more–the company has shifted to a “developer engagement” strategy rather than having a dedicated community leadership or advocacy team.

Accept the fact that this is a software company like any other, that distributes some of its software under an open source license and employs many talented people who spend a lot of their time (on- and off-hours) to further the efforts of the community. It is not a “everything-we-do-we-do-because-open-source” kind of company. It just isn’t.

5. Alfresco originally released under an open source license primarily as a go-to-market strategy

In the early days, open source was attractive to the company not because it wanted help building the software, but because the license undermined the position of proprietary vendors and because they hoped to gain market share quickly by leveraging the viral nature of freely-distributable software. Being open was an attractive (and highly marketable) contrast to the extremely closed and proprietary nature of legacy ECM vendors such as EMC and Microsoft.

I think John and Paul also hoped that the open and transparent nature of open source would lend itself to developer adoption, third-party integrations and add-ons, and a partner ecosystem, which it did.

I think it is this last one–the mismatch between the original motivations to release as open source and what we as a community expect from an open source project–that causes angst. The “open source” moniker attracts people who wish the project was more like an organic open source project than it can or ever will be.

For me, personally, I accepted these as givens a long time ago–none of them bother me any more. I am taking this gift that we’ve been given–a highly-functional, freely-distributable ECM platform–and I’m using it to help people. I’m no longer interested in holding the company to a dogmatic standard they never intended to be held to.

So be cool and do your thing

The “commercial” part of “commercial open source” creates a tension that is felt both internally and externally. Internal tension happens when decisions have to be made for the benefit of one side at the expense of the other. External tension happens when the community feels like the company isn’t always acting in their best interest and lacks the context or visibility needed to believe otherwise.

This tension is a natural by-product of the commercial open source model. It will always be there. Let’s acknowledge it, but I see no reason to antagonize it.

If you want to help the community around Alfresco, participate. Build something. Install the software and help others get it up and running. Join the Order of the Bee. If you want to help Alfresco with its marketing, send them your resume.

10 ways Alfresco customers can support the community

A prospective Alfresco customer recently asked me some of the ways an Alfresco customer can support the Alfresco community. Here’s what I said:

  1. Give your employees company time to answer questions in the forum or participate in the community in other ways. Perhaps set up an objective related to something on this list.
  2. Write a blog post about your experience with Alfresco (doesn’t have to be technical) then tweet the link with #Alfresco.
  3. Share your story at a meetup, Alfresco Summit, or some other conference.
  4. Make your office space available for local Alfresco meetups. If there isn’t a regular meetup in your area, start one and keep it going quarterly.
  5. If you customize Alfresco, take the customizations that don’t represent a competitive advantage to your business and contribute them to the community as freely-available addons. If you don’t want to take the time to package it up as a formal add-on, at least stick your code on github or a similar public code repository.
  6. Similar to the above, if you hire systems integrators, word your contracts such that they can contribute the code they write for you to the community. (Often the default language assigns IP ownership to the hiring party).
  7. If you choose Community Edition, give your time to the Order of the Bee so that you can help others be successful running Community Edition in production. The Order is particularly interested in Community Edition success stories at the moment.
  8. File helpful bug reports and make sure they are free of information specific to your business so that Alfresco will keep them public.
  9. If you not only find a bug but fix it, contribute the patch. One way to do that is to create a pull request on GitHub in the Alfresco Community Edition project then reference that pull request in an Alfresco Jira.
  10. If you see something wrong or missing on the wiki, log in and fix it.

Really, this list is mostly applicable to anyone that wants to participate in the community, not just customers. What did I leave out? Add more ideas in the comments.

My takeaways from the Alfresco Summit keynotes

This year we tried something new at Alfresco Summit. Rather than have all of our keynotes delivered by Alfrescans we invited some external speakers to both Barcelona and Boston.

Day 1: Big ideas, big opportunities–Doug Dennerline, Jimmy Wales, Andrew McAfee, & John Newton

In both cities we opened the conference with our new CEO, Doug Dennerline. This was Doug’s first annual conference since joining Alfresco, so it was a great opportunity for him to introduce himself to the community and talk about the tremendous opportunity he sees in front of us.

Then, in Barcelona we had Jimmy Wales, founder of Wikimedia Foundation. Jimmy spoke of the phenomenal growth of Wikipedia, particularly in emerging countries and in various languages. He talked about an initiative called Wikipedia Zero, which seeks to provide free access to Wikipedia over cell phone networks. He showed a never-before seen video of school children in South Africa who wrote an open letter to carriers to explain how much Wikipedia helps them with their studies and how much free access would mean to their community. That video totally got to me–I’m such a softy.

One of the things that stuck with me from Jimmy’s talk is that we should be asking what our community needs to get done and then help them make that happen rather than constantly asking what our community can do for us. It’s tough to do because our community is so diverse but this might be a useful guiding principle in the coming year.

In Boston the first day keynote was Andrew McAfee. Andrew is Principle Research Scientist for Digital Business at the Sloan School of Management. You may know him as the guy who coined the term “Enterprise 2.0”. His talk was about the unbelievable growth of content in our lives and businesses–“Content is growing faster than our ability to find words to describe it,” he said.

He talked about the importance of following the data rather than always deferring to the HiPPOs (Highest Paid Person in the Organization). He spoke of various studies that showed how areas once ruled by pundits (politics, wine, real estate) are now more accurately forecast using big data techniques.

There were all kinds of amazing stats Andy shared with us that morning. The one most shocking to me was that 500 million searches every day are completely new to Google (here is an article where that is referenced). Apparently 15% of Google searches have been new to Google for each of the last 15 years. Wrap your head around that!

We monitor all kinds of stats related to the Alfresco community. Each quarter we pick a few and see if we can make improvements in those numbers. Andy’s talk was a reminder to me that we need to pay attention to what the community is trying to tell us through data.

That evening John Newton, Alfresco co-founder and CTO, provided a Back to the Future themed keynote focusing on the future of work. John pointed out how unimaginable the work environment of today was ten years ago and asked for all of us to try to predict what work might be like ten years from now. If you have ideas, he’d love you to tweet them with the hashtag “#Work2023”. John’s slides are here. We’ll post the video soon.

Day 2: The Inevitability of Change. Simon Wardley and Dries Buytaert

Day two brought a new set of speakers. In Barcelona we kicked off with Simon Wardley, researcher at the CSC Leading Edge Forum. His talk covered a lot of ground. It was about the best way to think strategically about your organization (find the “why”, not just the “what”) and the inevitability of change and the incredible phases of discovery and innovation that follow major shifts in technology.

He compared cloud, which is simply the shift in computing from product to commodity, to the mass commoditization of electricity. He expects a period of unfathomable new products and services that will be achievable thanks to the cloud much in the same way radio, television, and other major innovations appeared after electricity was commoditized.

I agree with Simon that cloud is not an if but when. Even organizations that say there is no way they will ever put certain data in the cloud will ultimately shift to that style of computing. It will take time–probably less time than any of us think–but it will happen. Until then, Alfresco thinks that 20% of your content will stay on-premise, 20% will move to the cloud, and 60% will be in or moving between both.

Simon’s talk got me thinking about how our community will change over time. On-premise is still a huge part of our business and will be for some time, but SaaS is definitely the direction we’re headed. That will certainly change the make-up, goals, and tactics of the Alfresco community. It’s important for people to know, though, that our values around openness and transparency are fundamental to who we are. We may evolve our products and services, but you should continue to hold us to those values.

In Boston we kicked off day two with a keynote from Drupal creator and Acquia founder, Dries Buytaert. Dries talked about the evolution of content management. He took us from those humble beginnings in his Antwerp dorm room to today where Drupal runs 5% of all web sites and one-size-fits-all approaches are being abandoned in favor of best-of-breed, often incorporating open source software like Drupal and Alfresco.

I loved the “Do Well, Do Good” slide in Dries’ talk because it speaks to a reason why I like working in commercial open source. We can do well as a company–grow the business, earn profits for our stakeholders–but we can also do good for our fellow humans. Software like Drupal and Alfresco are helping all kinds of people fulfill their missions despite their lack of budget. We spend a lot of time worrying about the people who have huge budgets who aren’t paying us and we forget about the tremendous good we do for those who can’t.

Directly relevant? Maybe not always. Inspiring? I hope so!

It’s tough picking keynote speakers. Regarding the exact same speaker I had some people who asked, “Was that talk really relevant to what we do?” and others who exclaimed, “Wow, that was spot-on!”. It’s sort of like art–the perceived relevancy is totally in the beholder. I found elements from all four talks that were relevant to me–the themes played right into my community keynote on day 3–I wish I could say that was totally planned.

The goal wasn’t to have industry visionaries talk to us about our own products or even our own market. The goal was to have someone inspiring give a talk that opened your mind to new possibilities. That’s the best frame of mind you could be in when you go to a conference like Alfresco Summit, I think.

Up-coming Alfresco meetups in Sydney, Atlanta, London, New York, Chicago & Seville

Toronto Alfresco MeetupThe months leading up to Alfresco Summit are typically popping with meetup activity and this year is no exception. I thought I’d give you a quick rundown of the Alfresco meetups I know about that are coming up this month and next month:

  • Alfresco Sydney Day, August 22. This is a day-long meetup featuring talks from customers, partners, and yours truly. If you find yourself down under, it is not too late to sign up.
  • Atlanta, August 27. This meetup will feature a talk about Alfresco in the Insurance industry as well as a technical talk on the new backup and recovery toolkit. Sign up here.
  • London, September 11. Beer and Alfresco. What’s not to like? And this one has a hometown advantage. You never know who might drop by. Sign up here.
  • New York, September 24. We’ll hear from Mitch Brodsky, Digital Archive Manager from the New York Philharmonic. And I’ll be there to share some CMIS tips and tricks. Mitch is going to be organizing this group going forward, so he’ll want to hear your ideas on how to shape the revitalized New York Alfresco community. Sign up and share your ideas.
  • Chicago, September 25. How about a long lunch with the Alfresco Chicago community? The good folks at TSG once again offer up their sweet digs for the local community to swap tips and tricks. I’ll be there to hear about the great work being done with Alfresco in chi-town and maybe share a few tips of my own. Sign-up here.
  • Seville, October 8. Our Spanish community is one of the most passionate and committed on the planet. Sample what’s in store for Barcelona by hanging out with this awesome community in October. Inscribete aqui.

If you’ve never been to an Alfresco meetup, you’re missing out on a wonderful chance to hear first-hand from people just like you who are implementing Alfresco in their companies. These local communities vary greatly. Some meet very regularly, others not so much. Some lean towards the technical end of the spectrum while others are more focused on end-users. Often there is a formal agenda with one or more talks. Other times the goal is to spend time chatting over drinks.

Regardless of the style of the local Alfresco community in your geography, these principles hold true across all of them:

  1. Everyone is welcome. If you are interested in Alfresco, for whatever reason, we want you to participate. It doesn’t matter which product you use, whether or not you are a partner, or what your experience level is. Ours is a friendly, welcoming community online as well as in-person.
  2. You get out of it what you put into it. Most meetups are run by the local community. Organizing the meetings, finding people to speak, and finding a location all takes time and energy. So find a local community in your area, attend, and ask the organizer if you can help with the next one (even if the organizer works for one of your competitors).
  3. These aren’t sales events. Sure, the group might have one or more sponsors who paid for the food or supplied the venue, and they should get a few minutes to say who they are and let people thank them for their much-needed support of the group, but these meetups are for learning, sharing, and socializing. I haven’t heard of any problems in this area–I just want you to know our meetups are intended to be hard-sales-pitch-free zones.

If you are thinking about starting your own meetup and want some tips, take a look at Amy Currans’ Lightning Talk from last year’s DevCon.

If hosting your own Alfresco meetup is too much of a commitment for you at the moment, find an existing one and show up. I think you’ll have fun, you might learn something, and you’ll meet some really cool people. At the very least, you might walk away with some coveted Alfresco footwear. (Seriously, ask around).

I hope to see you at one of these meetups before Alfresco Summit!

Alfresco Tech Talk Live moves to Hangouts On Air; this month’s topic “Alfresco & Reporting”

hangoutsonair-300x171We’re going to try something new with Tech Talk Live. The May episode, which airs this Wednesday, May 1 at 10:00 US/Central, will be broadcast on Hangouts On Air rather than WebEx. This means you don’t have to sign up beforehand and you will be able to watch the recording on YouTube rather than using WebEx’s proprietary format that cannot be replayed on Linux clients.

If you are already signed up for the WebEx this Wednesday, don’t join it. Instead, just head over to the Event page. We’ll embed the live broadcast there. We’ll also include an embedded IRC chat window tuned in to #alfresco on Freenode IRC to facilitate real-time questions and discussion.

What’s on the agenda this month?

So glad you asked. This month we’ll be talking about Alfresco and reporting. We’ll have Alfresco community member, Tjarda Peelen, showing us what he does to solve the problem by integrating Alfresco and Pentaho. He’s made that available as an open source project so we’ll be looking at that code, seeing a demo, and talking about other ways people do reporting against Alfresco. If you want to throw in your ideas, join us in the chat.

We’ve tried Google Hangouts before, but this is the first time using it for Tech Talk Live. We hope it works well and that you’ll like the new format. Of course it could be a complete disaster. Who knows. Tune in to find out!

Alfresco Summit comes to Barcelona & Boston in November 2013

Alfresco Summit Slogan: Put your content to workHopefully you saw my previous post about Alfresco DevCon expanding to include not only great technical content but also new content around the business of Enterprise Content Management. The new, expanded conference is called Alfresco Summit.

I am pleased to announce that Alfresco Summit will take place this November in Barcelona from the 4th through the 7th and in Boston from the 12th through the 15th.

As we’ve done with previous DevCon events, the first day will be a pre-conference day consisting of training workshops (additional cost), a hack-a-thon, and a Partner Summit. The main conference starts on the next day. The full schedule will be on the Alfresco Summit site some time this Summer.

We expect registration to go live in June.

You Should Speak

We always have a great mix of content from Alfrescans, customers, partners, and other community members and I want to make sure that continues this year. Whether you are a developer who wants to give a down-and-dirty technical talk or you are an IT decision-maker, project manager, or ECM practitioner who wants to share thoughts on how to make ECM implementations successful, we want you to be front-and-center because no matter which edition or solution you are using–Enterprise Edition, Community Edition, Cloud, or Workdesk–you have tips, tricks, best practices, and solutions that the rest of us want to know about.

The call-for-presenters closes June 15. If you need some help thinking about what to present, check this out. Don’t feel like you have to stick to that, of course, but it might improve your chances.

I look forward to seeing what you submit and to catching up with you in-person this November!

5 drivers of your decision to pay for commercial support

DISCLOSURE: I work for a commercial Open Source Software company called Alfresco that earns revenue by selling commercial support for the software we freely distribute under an OSI-approved license.

A recent CMSWire post cited a study commissioned by a proprietary software vendor to show that Open Source Software is of lesser quality than proprietary. The person funding the survey is quoted as saying, “You certainly can’t use Open Source for something that’s the lifeblood of the company.”

I commented to one of my colleagues that it seemed like this guy just stepped out of a time machine from the 90’s and is still spouting anti-Open Source Software FUD that was dispelled years ago. And because the entire planet, except for this one guy, realizes that Open Source Software in fact runs the mission critical operations of many companies of all sizes and, basically, most of the Internet, the cloud, mobile phones, tablets, and countless other electronic devices, I shall not spend any more time on his nonsense here.

What the post did do, however, was to get me thinking about how companies make the decision to pay for commercial support of the Open Source Software they have deployed in their companies.

In talking it over with my colleague, Richard Esplin, we’ve come up with five drivers that companies think through when they decide whether or not to pay for commercial support of the Open Source Software they use. You can think of this like a scorecard. The higher a software packages scores across these dimensions, the more likely it is that the company will pay for support.

First, a couple of assumptions. Let’s assume that a company has the budget to pay for support. Companies and non-profits that don’t, don’t have the luxury of this decision–they make due. And, let’s further assume that commercial support for a given piece of Open Source Software can be obtained within that budget. Not all OSS has a commercial support option, or one that fits within their budget.

Now, the company is left with a decision: Do we pay for support or not?

Richard and I argue that this decision comes down to these five drivers:

Mission criticality

This one is simple: The more mission critical a piece of Open Source Software is to the business, the more it makes sense to pay someone to help keep that software running.

Switching Costs

If something goes wrong with a library I’m using as a developer, I may be able to find a similar library or I’ll just code around it. However, if my Open Source CRM, ERP, or ECM system fails, it is a different story. Those migrations don’t happen overnight. The higher the switching costs, then, the greater the need for someone to be there to help push through any issues that do arise.

Adoption

Are you one of millions of people using a particular piece of Open Source Software or one of ten? One of the benefits of Open Source Software over proprietary software is that “with enough eyes, all bugs are shallow”. If there is a huge population of people using the software, that means it has been used for a variety of use cases on a variety of platforms. The risk of a problem caused by using the software in a new and unique way is lessened. And a thriving community not only helps with finding and fixing bugs, it can also make it easier and cheaper to get trained up and to get ideas around approaches or to discover new use cases by engaging with that community.

If, however, the Open Source Software is narrowly-adopted, a lot of the benefit of the network effect is lessened. In that case, rather than crowd sourcing support, a company pays someone to do it.

Complexity

Open Source Software runs the gamut of complexity, from relatively simple libraries and small web applications to operating systems and databases and entire software suites. A company’s willingness to pay for support for software comprised of a few thousand lines of code that performs a small number of functions is going to be vastly different than that of a package comprised of millions of lines of code with hundreds of moving parts. Also consider some Open Source Software projects that are built on top of multiple layers of more foundational components, which are also Open Source.

The more complicated the stack (large code base, lots of moving parts, lots of layers and dependencies), the more it makes sense to pay a single vendor with deep expertise in the entire stack.

Cost of Self-Support

The final driver is the cost of supporting the software internally. In this case, I mean “cost” in the economic sense of the word, to be inclusive of the real dollars it costs to hire, train, and employ people with expertise in that software but also in terms of the opportunity cost experienced when a company spends their own fiscal and human resources on supporting the software instead of on other things. For a huge company with a deep bench of under-utilized people with technical skills in a certain area, for example, the cost of self-support may be relatively cheap. Companies where that is not the case are more willing to pay someone else to support the software because it is extremely costly for them to do it on their own.

Weigh Each Driver to Make a Decision

You can see how a strong score in one of these areas might offset a weaker score in others. For example, maybe you are using an Open Source Software package that is widely Adopted and has low Switching Costs but is of relatively high Complexity. Even if the Cost of Self-Support is high relative to what commercial support would cost, you might still not pay for support because you judge that the benefits of wide Adoption and low Switching Costs outweigh everything else.

Mission Criticality has the potential to trump the other drivers, though. A company whose existence depends on a piece of software that is completely unsupported appears wreckless, despite how low the actual risks may be when a package scores low on the other dimensions. Commercial support works like an insurance policy in this case.

All software breaks. Companies have to decide how they will deal with that when it happens. Companies may weight each of these drivers differently, but I think these five drivers are a good model of the decision at hand. And isn’t that the cool thing about Open Source Software? A company gets to make their own decision whether or not they want to pay for commercial support and from whom they want to buy it. I think that’s pretty awesome.

Alfresco Berlin Meetup Agenda

On Friday, May 10, we’ll be having a half-day meetup in Berlin, Germany in conjunction with the Codemotion conference happening at the same time. Everyone is welcome to attend and there is no cost, even if you are not registered for the Codemotion conference. You can register for the meetup here. The agenda will be as follows:

15:00 to 15:15 Welcome (Jeff Potts, Alfresco)
15:15 to 15:45 Introducing the Alfresco API (Jeff Potts)
15:45 to 16:15 Group Discussion: How Are You Using Alfresco? (All)
16:15 to 16:45 SmartWCM (Florian Maul, fme)
16:45 to 17:00 BREAK
17:00 to 17:30 Enhanced Script Import Tooling (Axel Faust, Prodyna)
17:30 to 18:00 Alfresco Workdesk (Bernhard Werner, Alfresco)
18:00 to 18:15 Invitation to Join the Community (Jeff Potts)
18:15 to 19:00 Bratwurst, Beer, & Networking

If you would like to present a 30-minute customer case study on how your organization implemented Alfresco, please let me know.

Earlier in the day I’ll be giving a talk at Codemotion Berlin on CMIS and Apache Chemistry in Action. So, if you are at Codemotion and you want to learn how to use an industry standard API to manage content in ECM repositories like SharePoint, FileNet, and Alfresco, come to my talk.

I hope to see you there!