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:
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.
Hi Jeff,
Excellent post. Like the fact that you wrote the post in general terms, the map can really be applied to lot of communities out there.
Cheers
Hi Jeff,
Thanks for your interesting post. My name is Francesco and I met you during the last meetup in Rome and if you remember I asked you some questions connected with what you have written. In fact in our 10-person company we are debating internally what kind of partner we want to become.
We have worked in the field of ECM for many years and even though we aren’t a large firm we developed our software solution with good results. Now we are interested in taking some features from our solutions and implementing them by using alfresco as a platform. We think that the success in an open source project depends on the quality of the community behind it. If members are capable of finding a balanced way/formula to give to and receive from such a community they can be small but able to do great things anyway.
We would like to be part of a project in which we are a strategic partner immersed into an ecosystem of other strategic partners. If we develop something new and complete we would like to offer it among the add-ons and try to sell it. If we develop something new but only partially complete we would like to share it and find in the community someone who wants to improve our software because it is convenient for them (more so than achieving the same goal by writing the code form scratch). If we develop an extension we would like to give the resulting code back with the goal of seeing our software in the next version of alfresco.
In my opinion, such practical measures encourage a company prefer to be a proactive member of the community rather than what you call “free riders”. That’s why during the meetup I asked you how to take full advantage of the community. You shared a 8-slide slideshow entitled “join-the-community.ppt” offering good tips to be part of the alfresco project. Now I’d like to take the occasion to ask you some strategic questions to become a profitable strategic partner:
What kind of service/support do you provide to your partners to make the right strategic decisions regarding the development of a new functionality/feature/ module?
Similarly how can we avoid risks of migrations from one solution to another as a project evolves or the risks of working on a solution that is already under development by the vendor and other members of the community?
Are there any ways of reassuring a partner in advance that what they are going to develop will be included in next version of alfresco?
Would it be possible to see in the next alfresco summit some workshops/best practices/case histories aimed at giving suggestions on how to be in synch with alfresco’s road map and how to take full advantage of the community ?
Just with the intention of being a little provocative, could you suggest a strategy to turn a small firm into a medium/large firm by leveraging the potential of the community?
In the next alfresco summit I’d like to see these kinds of positive experiences: company growth enabled by community participation.
Thanks in advance and regards,
Francesco
Yes, exactly! I want all of our partners thinking like this.
I think you’ll find that Alfresco is very responsive in this area. For smaller contributions, it might make sense to check the roadmap, and if you don’t see anything related, you just go build it and list it on add-ons. Or maybe bring up your idea in the forums. For larger contributions you can reach out to me and I can facilitate a discussion with Engineering. Or, you can talk to your Channel Rep about it and they can facilitate the discussion. We don’t want people spending multiple person-months on a contribution that duplicates something Engineering is already working on.
I don’t understand the “migrations from one solution to another” problem. If you mean upgrades, you are definitely going to want to develop your add-ons using the published extension mechanisms. This has gotten easier with each release. How do you avoid duplication with others in the community? Searching addons.alfresco.com, posting in the forums, asking around in IRC, floating ideas at meetups, and running ideas past me are things that can help. The best advice is to get plugged in to these channels.
We used to have something called the Alfresco Community Contributor Process (ACCP). It was an incubator, of sorts. The way it worked was someone like you would create a new feature and make it available. It would then get traction in the community and someone would nominate it for inclusion in Community Edition core. It would go there and then at some point get nominated for inclusion in Enterprise Edition core. We processed a handful of nominations and then the nominations stopped coming and the process died. Now Engineering kind of farms the community for contributions they want to incorporate. The best way to get something into the core is to create something that is extremely useful, applicable to a broad set of users, well-liked by a lot of people, coded at a high-quality level, documented, and unit tested.
As mentioned earlier, if you have a large contribution, you can work out the plan with Engineering beforehand. If everyone is nodding their heads and the contribution is well-executed, you’ve got a shot.
I think a session entitled, “So you want to make a contribution” would probably be a good one. I should add, though, that historically, the number of people who want to contribute to core is actually quite low. Even people doing quality contributions that would make great additions to the product (look at Florian Maul’s JavaScript Console as an example) often prefer to maintain a separate code base.
The best way to grow your firm is to develop a reputation for doing great work on-time and at a reasonable rate. As I mentioned in the blog post, you need repetition. And people need to know who you are. By “people” I mean both customers and the Alfresco sales team. When you do great work, share it. And when you share what you’ve done, it can’t be only, “Look what we did”. That’s marketing and you have to have that. But when you share with the community it is about sharing something of value. Tell us what you learned from that project. Give us an insight or a code sample or some new piece of functionality. The community is an exchange. You give the community actionable knowledge and if the community finds it valuable, we give you back recognition, respect, and, yes, project work.
Jeff
I am in the process of forming an idea to make the right decisions. So, your replies are very useful.
Just a couple of more precise explanations on things I wasn’t enough clear:
1. What I meant by saying “migrations from one solution to another” was the following: once I heard about a project in which a partner decided to use an external tool for forms. The problem was that that tool didn’t evolve as fast as the project did. The problem reached a point in which a small variation required in the forms brought about a migration from the tool initially chosen to another one (e.g. share). I know that it is impossible to reduce this kind of “risks” to zero but I was wondering if a more integrated and coordinated collaboration with the community could help even in this cases.
Even though I didn’t manage to convey exactly what I meant, I found in your reply the answer to this question too. Thanks.
2. You wrote: “Even people doing quality contributions that would make great additions to the product (look at Florian Maul’s JavaScript Console as an example) often prefer to maintain a separate code base”.
We are trying to identify the right approach for each case, at this point. If “to maintain a separate code base” is what you suggest in these cases, we will certainly do it.
Francesco
Francesco,
On the issue of using external tools versus extending the product, I think you have to take that on a case-by-case basis. The problem you identified is true either way you go. If you pick an external tool or framework, the evolution of your solution may move faster than that tool or framework. It could just as easily move faster than Share. And, in either case, you have the issue of how your changes will complicate the upgrade path. So those are costs you have to weigh against the benefits of getting something done quickly or closer to requirements or with less code, or whatever your particular values are for that project.
On contributing to core or not, I’m not making a blanket statement that one is better than the other. If you are creating something that should be part of the product and really can’t exist on its own and you don’t mind giving up control, contribute it. If, however, you want to continue developing it or you need it to also be part of some other solution it should exist as a separate project. Currently, we have no easy way to take a contribution into our source control that you continue to commit to.
Jeff