Home / A collaborative open source presentation

A collaborative open source presentation

I presented at DrupalCon London on contributing to Drupal.  The talk is called “How to have an open relationship… with software.”  Sadly, there is no nudity, polygamy or even dirty jokes.

 Nope, it’s just about how it is strategic to contribute to Open Source software and techniques for sales, marketing, management and developers. I did the same talk at Drupal Camp Montreal in September (video and Slides - not matching video).

 
 
It’s a lot of fun to do this talk.  It’s also the first time I’ve presented on non-technical topics.  There is a lot more doubt there.  When presenting on a technical topic I know that I am an authoritative voice on the topic.  That is, I have facts at my disposal. Solid, indisputable knowledge that my audience (at least 99% of them), will not have.  That is a position of power, it’s why
  • Engineers have good stability and income
  • Managers are scared to death we aren’t really working hard
  • We had a boss screen in DOOM and it worked, etc.
My new talk is all opinions.  If I’m generous, I can say I have experience and knowledge, which makes my opinions authoritative, but that’s like saying because I’ve ridden on a lot of airplanes, I’m a pilot.  It’s soft material, I’m just saying things I’ve observed and what I think works.  That’s terrifying!
Because I was so nervous about this, I did what I do most of the time when I’m nervous, I went and asked people smarter than myself.  I sent out 2 e-mails. 
One to people I knew who worked in business development and/or manage engineers and one to developers (both freelancers and salaried).  In the e-mails, I asked them a series of questions about how contributing to Drupal has changed the way they work and the satisfaction they get out of their efforts.  I turned these into several slides in my presentation, but there was a lot of great content there which didn’t fit on a slide.  Here are a few I found well written and interesting:
 

What was the biggest hurdle to contributing for you?  How did you get over it?

When I started, I thought that many of the patches weren't important enough to contribute, and the idea create a complete new project/module under my name was too scary. I learned two things: every idea is worth contributing, no matter how small. It might be a quick tip on a forum post, an extra link or a screenshot in documentation or a small fix such as a missing t() function or adding a hook_uninstall to a module. And you don't have to wait until you have a full-blown and zero-bug module before you do your first commit. I've learned to commit often and fail early. Committing dev versions or even using the sandbox already attracts some attention to people who are looking to solve the same problem, and it makes for early and good collaboration.
 
 

How does being a contributing member of the community change the way you work?

Inherently, it doesn't: I *always* open source work when that makes sense, whether it's Drupal or C++ code.
 
However, in the context of Drupal, there is one special thing you should do as a contributor: if there already is some module that partially solves the problem, but has been forgotten/neglected, then revive this code by extending/updating it to make it usable in your project and publish this code on Drupal.org (http://Drupal.org). Even if you don't want to keep maintaining it, you're at least contributing *something* back this way.
 
 

What patterns do you use to modify functionality without hacking contrib or writing your own custom modules? 

This is the most powerful hook in Drupal
Use it rarely if ever.
 
 

How do you structure contribution time for your developers outside of client projects?

 
  1. Pay everyone hourly
  2. Everyone earns 20% time toward community work that they take when it makes sense
Point 1 is key, because salaried companies often sacrifice community time for project deadlines. Then people lose track of their 20% (or whatever it is) and never get to it.
 
For point 2, we ask the team to use their best judgment in how to spend the time that will benefit Drupal and the company.
 
That's it :)
 
 
 

How do you explain the benefits of contributing to OSS to your customers and potential customers?

 
Mainly, our customers don't recognise the concept of contributing to open source one way or another. Again, they're non-technical. They just want it to work. But we do explain that by using Drupal as our underlying CMS we are plugging into the collective experience of an entire community of thousands of developers -- something far beyond what we could do by ourselves. This reassures them that the solution we provide will be sustainable and extensible over time, and won't dry up even if we do. 
 
 
 

Do you engage in "coopetition" with other companies?  How has that been successful?  How has it failed?

 
Quite a bit actually.  There are some shops that we team up with on some projects because they can provide a skill set that we don't have in house and vice versa.  Then on a different project altogether we may both be bidding on it.  And on a third, we may be doing only one part of the project even though we can provide the full set of services.  Sometimes the collaboration is rewarding in and of it self, along with the opportunity to work with a specific client. 
 
 

How does an applicant's contribution record affect your hiring decisions?

 
An applicant’s contribution record on d.o (or elsewhere) does have an impact, but not as much as some might guess.  For Palantir, it’s more about fit than it is about your d.o # or how many commits you’ve got.  We have a close knit team, with a very interesting sense of humor as well as strong care/commitment to each other.  If someone were to come along with all the d.o creds, but they couldn’t collaborate well with our team, then they wouldn’t be happy nor would the team.  
 
We also seek out the opportunity to mentor new people into the Drupal community - introduce them to all the things we already love, and hate ;), about Drupal.  In this case it wouldn’t matter if they knew what Drupal even was.  If they had all the same qualities that we see in our team and in the greater community: passion, self motivation, community, collaboration, sense of humor etc. then they could be a better fit again that someone who’s incredibly well know in Drupal circles.
 
 

The future

I originally wrote this a couple months ago and have since given the same talk at DrupalCamp Mumbai and DrupalCamp Hyderabad. It was a great experience at both and it is has evolved. Unfortunately, it did not get accepted to DrupalCon Denver, but a new talk on Drupal in emerging markets did! Hope to see you there!

I am thinking of doing this talk some more and perhaps turning it into a video or a website.  Would anyone be interested in such a thing?

How has contributing to Drupal (or another open source project), been a strategic venture for your company?

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.