Why your employees should work on Open Source projects

Why your employees should
work on Open Source
projects
Rich Bowen
Community Growth Hacker, SourceForge
Documentation Guy and Director, Apache Software
Foundation

2012 AIKCU Technology Conference

If your employees aren't
working on Open Source
projects, you're doing them,
yourself, and your institution,
a great disservice.


Assumptions

You're using Open Source software
in your organization
You have paid staff that's responsible
for the care and feeding of that
software


Technical skills

This is the obvious one
However, OSS participation is not
necessarily programming


Be an expert/craftsman

Encourage your employees to be an
expert
OSS allows them to be inﬂuential in the
project community


Craftsmanship

Be the expert in your ﬁeld
Hubris is a powerful motivator
Open Development encourages
excellence - the whole world is
watching


Expanded skill set

Participation in OSS makes your
employees more valuable
This isn't just about programming


Documentation/
communication

Participation in Open Source requires
the ability to communicate
So does their "real" job


Clarity

Communicating via email/IRC/tickets
requires the ability to communicate
unambiguously


Cross-cultural
communication
Open Source requires the ability to
communicate across cultural
boundaries
This eliminates ambiguity
It also helps eliminate prejudice


Cross-discipline
communication
Documentation requires the ability to
communicate with people who aren't
experts
Your employees need to know this
skill


Eliminates the "I Know
Everything" complex

Yeah, you know who I'm talking about


Don't Repeat Yourself

DRY is a common philosophy in OSS
Sharable, reusable components
Gives deep insight into all aspects of
their job


Code reuse

Duplicated code means duplicated
bugs
Less code means less to ﬁx


Design reuse

But it's more than just code
Design and documentation also beneﬁt
from reuse


Templating and
generalization

Templating eliminates duplication
It also increases consistency, and
therefore ease of use


But in the real world ...

Sometimes repetition is necessary
People are not computers


Localization

Localization forces you to think of your
projects in a different way
Which bits should be translatable?


Other people are supporting
your code

Don't have to maintain and reapply
your patches
Other people can help support this
code


Don't have to do it again in
the next release

Reapplying patches with every new
release is unsustainable
And sometimes impossible, then you
have to redo


Civility and Good manners
This is the biggest reason participate in
Open Source
IT professionals have a reputation. You
know what I'm talking about.


Customer support

Open Source "customers" are the
most entitled people in the world
They paid nothing, and they expect
everything
Remind you of anyone?


Exposure to jerks

How you deal with jerks says a lot
about who you really are


Leadership

Open Source is often organized as a
do-ocracy
You have to step up and lead. Nobody
is going to promote you.


Do-ocracy

Those that do, get to do more
Those that don't do, don't get to
complain
AKA "Meritocracy"


Mentorship

Giving and receiving
mentorship are the
most valuable
beneﬁts of Open
Source participation


Identify your next employees

Interview the guy that helped you solve
that hard problem
Their Ohloh/Github/SourceForge page
is a more accurate resumé


Should we start a project?

No, don't do that
There's already one out there
Join that one


By the way ...

Never too soon
SourceForge student internships - Pilot
program
(communityteam@sourceforge.net)


Objections:

But ... but ...


Isn't it supposed to be free?

Diagram from Kathy Sierra


Free as in puppies


They're just gooﬁng off

svn log
get on the IRC channel
subscribe to the mailing list
Also, they'd probably be gooﬁng off
anyway


It's not work related
They should be working on a product/
project that you use at work
They should be working on features
that you need
Everything is work related if you look at
it right

The Google 20%

Frequently misunderstood
They're not just free to play a day a
week

The real work isn't getting
done

Yes, managing priorities can be difﬁcult
It may be helpful to set a speciﬁc time
limit for those people


They're just looking for their
next job
They're already doing that
Give them a reason to stay
Nobody wants to leave a job where
they get to work on what fascinates
them


Why should I give my work
away?
So that someone else will take it and
make it even better
So you don't have to support it
So you don't have to do it again in the
next version


We're not programmers

Participating in Open Source is so
much more than writing code
Code contributions are a small
percentage
Everyone is qualiﬁed


Ways to participate

Fix a typo, or improve sentence
structure
Get on the mailing list and help a
newbie (You should be on the mailing
list anyways)


Ways to participate

File a bug report
Test and close a ﬁxed bug report


Subject Matter Expertise

Open Source projects implement ideas
You might be the expert in that idea
e.g. Library collection management
software, written by non-librarian
programmers


Conference proposals

Encourage your employees to submit
conference talk proposals
Some conferences cover expenses
Send employees to one conference a
year?


Tech talks
Teaching is often the best way to learn
Encourage your employees to give
presentations to your staff


Other ways ...

s.apache.org/ways-to-contribute


FIN

Rich Bowen
rbowen@geek.net
@rbowen
rcbowen.com
slideshare.net/rbowen


Why your employees should work on Open Source projects

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (13)

Similaire à Why your employees should work on Open Source projects

Similaire à Why your employees should work on Open Source projects (20)

Plus de Rich Bowen

Plus de Rich Bowen (8)

Dernier

Dernier (20)

Why your employees should work on Open Source projects

Notes de l'éditeur