Skip to main content

Blog Post

If You Wanna Be My Vendor ...

If you wanna be my vendor, you’ve gotta get with my friends: Drupal, Open Source, and Communication.

It doesn’t take very long working on Drupal projects to figure out that at one point or another you are going to need to interact with a third party vendor.  Whether they are providing a university admissions management system, a learning management system, or translation services, the website will need to work well with other systems and processes to be successful. At Mediacurrent, our clients will often ask us to recommend service providers, but there are also times when the client will choose these vendors without us.  No matter which situation we are in, there are several measures that vendors can take to promote an enjoyable work experience so that agencies recommend them more often. There are also things that we on the agency side can do to facilitate a better experience with any vendor. 
 

Open Source

I know that every company can’t drop what they have been doing for years and years and start using open source for everything.  Despite the benefits of open source software (including a vast community of development support, superior customization capabilities, and freedom from vendor lock-in, software costs, and licensing fees) immediate adoption just isn't practical in all cases. But, in the open source community, there is a lot of support for others that embrace open source.  All you have to do is simply be nice.  Maybe when you are selling to clients, you feel you have to expose things that other companies in your industry don’t do well.  But when you are talking to partners, we just need to know what you do well.  If you are dogging someone else that has represented the Drupal or Open Source community well, it is not going to make me recommend you more.

We also are frustrated by “black boxes” - even if we are communicating with proprietary software, we need to know more.  Help us have access to your logs.  Use standards in your communication protocols.  If you aren’t giving out source code or a view into things, we want your documentation to be flawless.
 

Drupal

Drupal is what we do. As a full service digital agency with an emphasis on Drupal, we have been helping clients like Manhattan Associates and weather.com since 2007 to utilize this content management system to establish a competitive edge in their markets.  We are always passionate about Drupal, what it does and what it can do. We don’t just want people to like it.  We want to make it better.  By contributing code and actively participating in the Drupal community, we pave the way for high-speed innovation—and in a competitive marketplace, speed matters.

If a vendor needs to pass information back and forth with Drupal, it helps if there is a contributed module to handle this.  It is even better if the contributed module works well and creates a nice configuration that makes sense. It is also helpful if a vendor is enabling Drupal developers to help.  If they encourage issues posted to the queue, appreciate the help they receive, and keep things moving forward with the direction of the community, we like them and recommend them.  
 

Communication

In my experience, communication is one of the differentiating factors for successfully working with a vendor.  I have experienced written documentation only.  I have experienced status calls.  I have experienced continuous chat throughout the day.  Sometimes, problems exist in integrations that cannot be solved by one party.  The worst thing that can happen is for mostly project managers or client services to stand in the middle of communication.  When a developer is deep in an issue, making progress that is difficult for the developer to understand, nothing slows things down like trying to describe the issue to a non-technical person who will need to communicate it to a developer on the other side.  Allow developers to talk directly to developers.  

I was recently a part of a project where we needed to implement single sign-on for a client’s vendor.  The authentication ran into a significant hurdle, and there was a time period where we exchanged emails and had some update calls to trade information back and forth.  Progress wasn’t sufficient to meet our goal.  To increase efficiency and improve communication  we opened up a slack chat channel between the two companies.  We had impromptu meetings throughout the day.   By adapting our workflow and getting better efficiency, we quickly cleared that hurdle and met our goal.

Also, it is not helpful for multiple people to ask for updates at random times. I know that there are people that need to know progress, but this communication needs to be defined on a schedule. There is a reason the TPS report memo of Office Space is so funny. It is relatable.    
 

Drupal Developers - Represent

If a vendor is the choice of the client, and they don’t have defined integration with Drupal, we the developers have to take the lead. It is our responsibility to teach and evangelize the Drupal way to this vendor.  Create a new sandbox or contributed module to handle this (see more about Contrib First Development).  Even if you can’t make it fit a generic use case, the module can be expanded by others later.  Get the code out there to allow others to help.

We have to communicate and collaborate.  Often, it is difficult to figure out what side an issue resides on.  We should always be willing to consider that the problem is within our code until it is fixed.  Pointing fingers never helps to isolate an issue. Give information. Rule out caching. Make sure you follow all of the hooks.  

Get creative with isolating issues. If it is possible to configure xdebug to be able to step through code, it is difficult to beat the value this provides in being able to isolate an issue.  When we are looking at integrations, you might not be able to step through code on the server that is setup to communicate with other systems.  I have set up local systems to pretend that they are the vendor.  I have also added watchdog or other logging mechanisms to the server to make sure I understand exactly what is happening.  Sometimes just running various scripts through drush scr helps to identify what is happening.  
 

Conclusion

I love that I get to work with brilliant developers that push each other to be better.  I know that working well with vendors can be essential to the success of a project. No matter what encounters are like, I always believe improvement starts with me.  So, no matter if it is a joy or frustration, we can always learn from our experiences together as service providers.  It is great when that moment happens: the integration has succeeded, the site has launched, the customer is happy, and the vendors now consider each other friends and are looking at happily ever after...even if the feeling only lasts a minute before the next challenge comes banging on our door.
 

Additional Resources
Dev Hacks: My Other Office | Blog
20 Things to Know About Your Site Before Approaching an Agency | Blog
Creating a Culture of Giving in your Organization | Blog


 

Nathan James

Meet team member, Nathan James

Nathan received an early introduction to open source during his days at the University of Arkansas’s Computer Engineering program. From Linux and shell scripting, to PHP and MySQL, to Asterisk...

Learn more about Nathan >