Improve Your Open Source Project Adoption by Catering to Integrators
Develop | Posted April 18, 2013

In the software ecology, a special type of evangelist works with organizations that are open to incorporating open source into their technology infrastructure. These “integrators” (sometimes called value-added resellers or just computer consultants) can encourage a business to adopt software because the integrator is a trusted outside party without a sales agenda. If you capture the integrators and keep them interested and dedicated, the growth of your project is guaranteed.

These are the best friends an open source project can have. Integrators who become enamored with an open source project devour all the information they can about it. They are drawn to projects that make their lives easier (which means: helps them deliver quality software sooner) and which make the lives of their constituents secure, pain-free, and a joy to work with on a daily basis.

Satisfied integrators market your project, encourage project adoption among their clients, and tell their associates how project X really made a difference in their business process. However, if the integrators feel they are not getting the attention they deserve, the core developers, the designers and even the project leaders will find themselves building only for themselves.

Love to love you, baby

Integrators want to love your project. In many cases, these people (and their companies) are paid to deliver to their clients a stable, reliable solution to a business problem. Like any consultants, especially those who are paid a flat fee, they want tools that work, that easily can be customized, and that don’t cost a lot of money. Open source has always been attractive to these people.

When integrators fall deeply in love with your project, they show it off to anyone who will listen. They evangelize your project to their boss, their co-workers, their clients, and even the C-level executive who just happens to sit next to them on a cross-country plane trip.

Happy integrators are a boon to the project and to the community in general. Integrators are the developers who take your code into the big bad world of everyday, real world commerce and enterprise. They represent the needs of end users, since it’s the integrators who build applications with your open source project as their foundation. That gives them a wider breadth of experience, too, since they solve several kinds of problems with the software.

This also gives integrators a reason to contribute and to display their knowledge. If they customize code, integrators are motivated to hang around the IRC channel or participate in online discussions. It is, after all, a good way for experienced consultants to find new clients; businesspeople who like the open source software but lack the time or expertise to do customizations themselves are apt to contact active participants whose bio says “expert in this technology.” That means the integrator is also in the channel and on the mailing list to help other people with technical issues. (In fact, I met my editor, here at SmartBear, from the IRC channel for an open source project.)

Appreciate these contributors and pay attention to their input. Even if these people don't commit to GitHub as frequently as your core development team, integrators can determine the project’s success because they influence where and how it’s used. Ask them what they find most useful, which features are not intuitive, what challenges they face. Include integrators in ongoing testing.

Catering to integratorsGranted, there is no way to “please all of the people all of the time;” balancing what integrators request with what is best for the project as a whole is key to keeping your project – and its community – solid and meeting technical expectations.

I write, therefore I am

One way to encourage integrators is to ask them to help guide end-user document creation. This increases the likelihood of project adoption, as documentation is created to address issues experienced by someone new to the code base. Core developers tend to write to other developers; often that means the documentation is confusing and full of "inside" language that makes a lot of assumptions about the end-user’s experience with their project that may not be true.

Integrators deal with end-users in real life situations using your project code. As a result, they can include examples and situations that encompass multiple scenarios. Their fresh eyes and different perspective highlights usability issues that may not occur to the core team. After all, they haven’t been knee deep in your project code for six months. Incorporating the integrators’ hands-on project experience in your end-user documentation helps to bring on more integrators, which leads to wider exposure for the project and its community.

Know thy integrator

You can be deliberate about catering to integrators. Organize a sprint or two that includes integrators and follow up with them afterwards. Allow them to learn what is involved in creating new components to your project. Get them involved in testing a new user friendly aspect. Is it really as user friendly as you think it is? Why?

Listen to the integrators’ concerns. If your project is a content management system, maybe the WYSIWYG editor is too complicated for the MarCom department that one integrator deals with on a daily basis; they need something simplistic but easy to customize. Often that input raises larger questions for the project’s core developers. Would changing the editor make the entire project a bit more palatable and widely adopted across the user base?

As an integrator attending and organizing sprints for one of my favorite projects, I found that engagement with the developers heightened my overall knowledge of the project. It encouraged me to ask crucial questions. Often times these questions bred new feature sets or functionality that were not a consideration prior to participation in the sprint.

Two Steps Forward One Step Back

Developers understandably tend to think about adding new functionality. In this day and age, backwards compatibility is a given. Or is it?

Integrators repeatedly are warned not to customize the core code so that we can easily upgrade our clients to newer versions. Layer your customizations, we are told, and we happily comply.

Using new theming processes or a better file system layout is exciting for the project owner and developers. Unfortunately, for the integrator, it doesn’t matter how sleek or sexy the new release might be if it makes it impossible to upgrade an older site. A lack of backwards compatibility means we have to go to our boss and tell her we can’t upgrade to the latest version, or we have to spend countless hours and resources bringing the code base up-to-date. If the site that needs the upgrade has to pay a consultant’s hourly rate for that upgrade to make an important feature work, someone is sure to get cranky.

What may appear to be a simple update to theming or site management can be a painful endeavor for the integrator. Introducing conflicts between old and new releases alienates integrators and consequently the organizations to which they sold the project. Keeping integrators in the loop and actively testing for potential conflicts with older releases encourages them to notify you about potential stumbling blocks and protects the project’s longevity.

Change can be good and is sometimes necessary to stay on top of the rapidly changing software landscape. It’s not change in and of itself that causes dissention and heartbreak, but the fact that the integrator wasn’t told how this might affect the way he is used to doing things.

Making drastic changes to the way the project is themed or managed without involving the integrators is a definite path to obscurity for your project. Integrators deal with their user base on a daily basis and make look-and-feel and software management decisions. Integrators will leave without letting you know that the drastic changes introduced bitterness or apathy towards your project.

Silence isn’t always a good thing. If you want to migrate to a new way to do something – how the project modules are packaged, the way assets are managed, etc. – introduce it slowly and leave the old way as an option until users get used to it. Include the integrators in vital decision making and they will reward you with more adoption and a strong user base.

About the author:

Donna M Snow is a Silicon Valley transplant currently living in Las Vegas. With over 15 years experience working with open source as an integrator and designer she has first hand experience working with both management and development teams. Technologies she’s worked with include Zope. Plone, Django, Drupal ,ModX, Pimcore, WebGUI and WordPress. When she isn’t eyeballs deep in a new project, she is fervently leveling some toon in her video game of the week.

See also:



By submitting this form, you agree to our
Terms of Use and Privacy Policy

Thanks for Subscribing

Keep an eye on your inbox for more great content.

Continue Reading

Add a little SmartBear to your life

Stay on top of your Software game with the latest developer tips, best practices and news, delivered straight to your inbox