Month: April 2013

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!

Alfresco Stockholm Meetup Agenda

On Monday, May 6, we’ll be having a half-day meetup in Stockholm, Sweden. Everyone is welcome to attend and there is no cost. You can register here. The agenda will be as follows:

13:00 to 13:15 Welcome (Jeff Potts, Alfresco)
13:15 to 13:45 Introducing the Alfresco API (Jeff Potts)
13:45 to 14:15 Customer Case Study (TBD)
14:15 to 14:45 Alfresco Administration Best Practices (Redpill-Linpro)
14:45 to 15:00 BREAK
15:00 to 15:30 Media Viewers Add-On (Peter Lofgren, Loftux)
15:30 to 16:00 Alfresco Workdesk (Barbara Lemke, Alfresco)
16:00 to 16:45 Lightning Talks
16:45 to 17:00 Invitation to Join the Community (Jeff Potts)

If you want to do a lightning talk (probably 5 minutes, max) or are interested in presenting a case study on how you implemented Alfresco in your organization, please let me know.

I hope to see you there!

How involved should partners be in a vendor’s community?

There are people all over the world doing amazing things in the Alfresco community and that includes partners, but I often feel that partners are under-represented in our community. A small example is going to a city that has multiple partners headquartered there only to have one or two of them participate in a meetup. This is frustrating to me but should it be? Maybe my expectations are skewed by my open source/collaborative world view? Why should a partner, who earns revenue by selling time, spend time participating in the community for free?

First, some background on software vendor partnerships

Every software vendor or project has a community regardless of their business model or their license or whether or not they choose to invest in that community. And most software vendors have partners. These are firms who install, configure, customize, and extend the vendor’s software. The partnership formalizes the business relationship between the partner and the vendor.

To understand whether or not it is realistic to expect partners to participate in a community, it helps to understand the makeup of the partner ecosystem. I’d be shunning my consulting heritage if I didn’t use a two-by-two matrix to illustrate this:

Partners can be grouped in a 2x2 matrix of size and relationship

The first axis in the matrix is the size of the partner. You might measure size by revenue, the number of billable consultants, or the number of vendors the firm partners with. It doesn’t really matter for this discussion. The second axis describes the nature of the partnership–is the partnership strategic or tactical for that partner?

A strategic partnership is just that–it is strategic to the partner’s business. A strategic partner actively works to improve their relationship with the vendor. They jointly close deals. They get their consultants trained up or certified on the technology. They might spend marketing dollars on events or campaigns that help promote their work with the software. If the software vendor goes away, or the partnership deteriorates, it adversely impacts a significant chunk of the partner’s revenue.

A tactical partnership is not strategic at all, it’s transactional, often opportunistic. A common way for these partnerships to happen is when a firm sees a potential project on Technology XYZ. Maybe they’ve done something with XYZ and maybe they haven’t, but they need to tick a box, so they do the bare minimum necessary to say they are a partner and then try to win the project. A partnership that starts out as tactical could grow into a strategic relationship over time. Or the firm may move on after one project, never getting any real traction with that vendor.

Every partner ecosystem has partners in these four quadrants. (Notice I do not make any mention of partner tiers. Software vendors often use tiers (Diamond, Platinum, Double-Dutch Chocolate) to help differentiate partners. It’s one way of helping customers figure out where a partner might be on the matrix. But I think the matrix does a better job for this discussion.)

What should a vendor’s community expect from each partner type?

I think it is safe to expect nothing from the partners in the tactical categories, regardless of their size. For this group, the community serves a purpose, but it is almost entirely one-way. These partners will read blog posts, tutorials, sample code, and wiki pages. They might even ask a few questions in the forums as they get up to speed on the platform, but it is unrealistic to expect much more.

Where I think the opportunity lies is in the strategic partners, but what the community offers the partner and what the partner is willing to invest is much different between small and large strategic partners.

Small, Strategic Partners

Let’s look at small, strategic partners first. The number one concern of a small partner is utilization and cash flow. A small, strategic partner needs lots of “at bats” and a reputation for getting on base and scoring runs. Small partners need visibility and credibility. Spending time in the community can help with that. The challenge for a small partner is that resources are super constrained. Often, the same individual is doing billable work and closing the next deal. It leaves little time to give to the community.

For partners in this group I think it is fair to expect contributions to the community that can be done it smaller chunks of off-peak time. Blogging, wiki cleanup, hosting or organizing meetups, and participating in the forums in a fairly ad hoc manner are some things that will help the community tremendously and in turn helps the partner with name recognition and credibility.

Large, Strategic Partners

Of course large partners still care about utilization and cash flow. But there are a few things about large firms that allow them to invest more in their vendor communities: they have a deeper bench (more consultants), they have access to more capital, and often, they have more negotiating power with their clients.

Let’s look at this bench advantage. When a firm has many consultants they can smooth out the inevitable ups-and-downs of utlization (assuming they also have lots of projects).  It also means that compared to smaller firms, they have more bench time to invest in the community. Let’s say there are 2000 potentially billable hours in a year. If you’ve got 30 consultants, there are 60,000 hours you could bill. Assuming a generous utilization rate of 90%, that leaves 6,000 hours of down time, spread across all of the consultants, throughout the year.

It’s not fair to expect all of those hours to go to the community. Consultants need bench time to train, work on internal projects, and help sell new business. But I do think a significant chunk of that time can be invested in the community. Imagine what a huge difference it would make if just 20% of the down time mentioned above was invested in the community. Now multiply that times the number of large, strategic partners in a vendor’s ecosystem and it is huge.

What is the incentive for a large, strategic partner to invest that time in the community? They will benefit from name recognition and credibility benefits that a smaller partner seeks, but larger firms have marketing dollars so that may be less important to them.

I mentioned that larger partners often have more negotiating power with their clients. This can allow them to turn some of their client work into open source projects (like add-ons or extensions) or even into full business solutions. These will have their own communities. Investing in the vendor’s community can help bootstrap these solutions and the communities around those.

There is a bigger picture reason large, strategic partners should invest in the community. It is the “rising tide raises all boats” argument. When the software vendor succeeds, the strategic partners succeed. So anything the partner can do to make the vendor successful will return dividends. I saw this at Optaros, Alfresco’s first platinum partner. Optaros gave me time to blog and to write tutorials and even a book. These helped thousands of people get ramped up on the platform, including customers and competing partners. We were helping the tide rise. Optaros didn’t stay in the Alfresco business long enough to see the full return on those investments, but I know from the success of similarly-sized partners around at that time that they were there to be had.

Free Riders

Clearly, there are partners, small and large, who believe it is important to participate in the community. There are those, however, who will reap the benefits of a healthy community without participating at all. They lock up their best practices, tips & tricks, code snippets, and know-how behind walled gardens, or, worse, they simply don’t share them at all. There is not much a community can do about this other than to try to educate these firms on the benefits of participating and encourage customers to buy services from those who are willing to demonstrate and share their expertise in public, for the benefit of the entire community.

Summary

A strategic partnership is just that–it is strategic to both the partner and the vendor. The community is a huge part of the success of the software vendor (open source or proprietary), so strategic partners ought to invest and participate in the community. Their ability to do that and the types of investments they make differ, primarily due to resource constraints. It is unreasonable to expect more than what the partner can give, but for a strategic partnership to be truly successful, they must be a visible and frequent presence in the community.

Alfresco DevCon evolves to incorporate business tracks; will be known as Alfresco Summit in 2013

We have done six Alfresco DevCon events so far–one in EMEA and one in the Americas for each of the last three years. The general feeling from people who have attended is that it has improved year after year. Attendees come from all over the globe and are usually a good mix of Enterprise Edition users, Community Edition users, partners, Alfresco employees, and other community members.

Each year we try to do something new to make the event better. Last year we added things like the DevCon web site, Lightning Talks, the Hack-a-Thon, and recordings of each session. These were all hugely popular, but they were all relatively minor in the grand scheme of things. This year, we’re going to shake things up a bit and I wanted to share our plans with you first.

There’s something that’s been bothering us about DevCon: The event isn’t inclusive of our entire community. We want an annual conference to be the go-to event for everyone in the ecosystem, not just developers. Shouldn’t it be possible to have one event with content that is laser focused on each audience?

We think so.

So this year, we are expanding DevCon into what we hope will be a must-attend event for anyone working on an Alfresco project, regardless of their job title. The first change you’ll notice is the name. We’re going to call it Alfresco Summit.

New name, same great technical content, and then some

So the name changes. What else? First, content. Alfresco Summit will include the same great DevCon tracks that you are used to plus a whole new set of non-technical content aimed at the business end of Enterprise Content Management. What might you find in such a business track? Things like non-technical customer case studies, panel discussions with industry analysts, best practices around compliance, going paperless, or case management. Basically, talks that help you be successful in your implementation that focus on everything but code and configuration.

The next change you’ll notice is that we’re adding a half-day to the event. We’ll still have the optional training day, but we want to have some room in the agenda for some high profile speakers, product demos, and other types of general sessions. In addition, the extra time gives us more opportunity to have repeats of popular sessions to help alleviate inevitable schedule conflicts.

Finally, you may notice a bit more production value or “sizzle” to the event. It’s hard to quantify what that really means. Really this is about putting on an event that appears to you, the attendee, as if it were that of a company 100 times our size in terms of organization, branding, quality, and execution.

Help me spread the DevCon magic to our non-technical brothers and sisters

I continue to chair the event. If you’ve enjoyed DevCon the last two years, this should be good news to you. (If you haven’t enjoyed it, make sure I’ve heard your feedback so I can try to make it better). I will also own the DevCon tracks so we’ll have the same high bar for technical content we’ve had in the past. I will work to keep the things that you love about DevCon (the content, the access to engineers, the fun) in place as we expand to an event the entire community can enjoy.

The general format of the conference stays the same:

  • Day 0: An optional day for training, hack-a-thon, and partner meetings.
  • Day 1: The first day of the main conference starts out with some general sessions and then moves to breakouts with a fun party that night.
  • Day 2: Another full day, again starting with some general sessions and product demos before moving to breakouts. Another party that night (this is new).
  • Day 3: New for 2013, this is a half-day of breakouts with a closing panel of Engineering leads and senior management.

Of course, we’ll have the exhibition hall, engineering office hours, lightning talks, purposeful lunches, etc.

Where and When?

The save-the-date will be coming soon. The timing will be similar to last year (November) for both EMEA and Americas. EMEA should be thinking southern Europe and we’ll be on the East Coast of the US for the Americas.

Here’s what I need from you:

  • In last year’s DevCon survey, we asked if there were people who would attend if we had a business track. Roughly half of you said yes. I need you to show up this year with those people at your side.
  • Consider speaking. Especially if you are a current customer. Business or technical track, it doesn’t matter. The key is that the community wants to hear what you’re doing with Alfresco. This is the best place to share your story. The call for papers will be open by the end of April. Watch this blog, twitter, etc. for more info on that.
  • Tell me what kind of content you’d like to see at Alfresco Summit. A good way to do that is to propose session titles. You can do that here in the comments for now. If enough people have enough feedback we can look at doing something fancier.
  • If you haven’t attended in the past, make this the year you find a way to get to the conference. This is the quintessential gathering of the Alfresco community. You won’t want to miss it.

You can trust me to not screw up a good thing, but I need your help to make it awesome. If you have thoughts or comments as we continue to evolve our annual conference, share those here or by emailing me directly at jeff dot potts at alfresco dot com.