Share and share alike

by Matthew Langham

Moving commercial developers to Open Source


An increasing number of companies are now adopting Open Source
as part of
their development strategy. A subject that is often overlooked is how
corporate software developers see the move towards using
software developed
in a community project instead of what they may have written themselves.


Getting developers inside corporations to see the advantages of using
and contributing to Open Source can be a long drawn-out process. I
spend a lot of time talking to large companies in Europe about using
Open Source software inside their enterprise projects and even though
corporate managers can be convinced with a few glossy slides why Open
Source is an advantage for them, getting the developers to catch on is
sometimes not so easy.


There is a lot of FUD when it comes to introducing developers to the
"Open Source way" and it's important to understand the problems likely
to be encountered.


If it's free - then what am I worth?


Back in the 90's most corporate projects were written from scratch and
often "close to magic". The only people who really knew the software
were the people who actually worked on it. And due to the lack of
documentation - they were doubly important. The value of developers was
measured in "lines-of-code" or in the number of modules they were able
to churn out. So it's easy to imagine how scared your developer will be
if you suddenly point him to the URL of say an Apache project and state
"it's all there - and for free. Use that." Not only does the fog of
outsourcing send shivers up your developer's spine, now it's Open Source
too.


Another big problem is fighting the NIH (Not Invented Here) syndrome.
In many cases developers have refused to use an Open Source project for
their work and resorted to writing much of the same functionality
themselves from scratch. Why? Because they think they can do it better
or were unwilling to take the time to look inside the software to
see what makes it tick. A common argument is "I can write it quicker
and better myself than if I try and understand what the other developer
wrote". While Open Source software is not always well documented (at
least probably not according to your corporate standards), this
argument probably stems more from the fact that the developer is trying
to maintain his perceived value.


An often quoted barrier in getting developers to dive into Open Source
projects is the bouquet of sometimes rudimentary tools the community
uses. Tools that perhaps your developer is not familiar with like CVS,
Maven, Scarab and IRC. Instead of getting dug into using the tools, I
have heard developers start endless discussions about the poor
usability of these tools when compared to the corporate environment they
have been used to for the last 10 years.


Participating in an Open Source community can be pretty daunting
challenge for a corporate software developer. Even more so if English
doesn't happen to be your first language. It also pays to remember that
English is probably not the first language of many of the developers in
the project and therefore it is easy to misunderstand the emails -
especially when criticism is given. Due to the time-zone spanning
environment - remember that maybe the person you are emailing may have
just got up - or is just going to bed after 12 or more hours of
coding. As
email will be the main channel of communication, think
carefully about what
you write and resist the urge to quickly send off a heated response.


One of the new rules any corporate Open Source developer must
learn is that
it's good to give back. Contributing your own work to the Open Source
development process earns you karma points. This means that the
more you are
able to give back the more you will be able to profit from Open Source
yourself. It doesn't need to be code. In many cases when Open Source
software is integrated into a corporate environment, the new
modules will be
specific to that environment. So it is important to point out
that you can
also support the project by giving back things like documentation,
test-cases, bug-reports, deployment statistics, performance measurements
etc. etc.


Getting there


So, what are the rules for getting corporate software
developers to work on
Open Source projects? Of course there aren't really any rules
just some
common sense tips that will ease the transition.


Create win-win situations for your developers by explaining how they can
profit from working on Open Source projects. They can gain
visibility and
respect from their peers by working on the project. They can
extend their
knowledge by observing how others may be solving problems. They
can perhaps
take over a key role in the project and gain visibility in the
community.


Provide time for developers to actually work on the project. Understand
that, even though they may not be working on the module you
need, they are
not "working for nothing". Working on the actual project
(perhaps fixing a
bug or two) is one of the most important ways of gaining the
respect of the
other community members. The pay-back will be there if you need
a bug fixing
urgently and someone else jumps in to help. Becoming a major
contributor to
the project is also excellent marketing especially if you
happen to be a
software-vendor or consultant yourself.


Any developer getting in an Open Source project will need to adjust
their working schedule to fit the distributed environment and time-zones
of the Open Source projects. Give your developers the flexibility to do
this. Firewalls that don't let Open Source tools like IRC or Instant
Messaging work are going to prevent your developers from really getting
involved in the communication process.


What about the developers themselves? Well a major point is certainly
getting to know what makes the Open Source project tick. So join the
mailing-lists and lurk for a while. Find out how the project is
structured.
Observe how the community interacts, who is the leader and who
is lead? Read
between the lines to understand the relationships before
jumping in. Don't
be inpatient and expect quick answers to problems you may be
having with the
software. Perhaps that particular question has been answered
several times
already. Check the mailing-list archives first. If you find a bug then
report it and if possible fix it as well.


Understanding the social aspects of joining an Open Source
community will
certainly provide some input for successful participation.
Developers from
all over the world meet to work together on a joint project.
This allows the
developers to also socialize with people from different countries and
cultures. A natural and important extension of this virtual
community is to
meet-up at conferences and get to know one another personally.


And lastly, a tip that is really the easiest way to get the
Open Source ball
rolling in your company - get someone in who can talk to the developers
about Open Source. A peer who can alleviate any fears they may
have. Forcing
your developers to accept Open Source and "like it" is just not going to
work.