Le 23/09/10 17:37, Grant Ingersoll a écrit :
One of the things I've noticed in my day job, which is admittedly self-selecting since I
work for a company that engages with people deploying open source, is that I routinely
hear, how shall I say it, more enjoyment from the developers in their work as compared to
the old days when they worked on a proprietary equivalent, and I think it even holds true
when working on troubleshooting engagements where something is broken.
Since, most of us here likely work on open source, I'm curious as to what others think?
Are devs who work on or use open source happier in their day jobs? And I don't just mean
committers/contributors here, I mean people who are using the software to solve some
bigger problem for their company and who may never do anything more than ask a question
on a mailing list from time to time. Has anyone seen _independent_ studies that say one
way or the other? (References please.) I do think, that some of the answer depends on
the quality of the software they are working on (just as it likely does when working on
proprietary software), so perhaps I should separate out what could be called hobbyist
open source versus open source that has a large community of followers (regardless of
license) like Linux, ASF projects, Eclipse, etc. Therefore, assuming two different
pieces of software, one being proprietary and one being open, both of which will solve
the problem, are developers who solve the problem with open source happier in their job?
At any rate, my motivation for asking is that I'm writing an article on some
thoughts in this area spurred by something a client told me (at a very old,
established company, mind you) about why they wanted to get the word out that
they were using open source: they felt it would help them attract and retain
developers b/c they would be more satisfied in their jobs b/c they got to work
on innovative open source technologies.
Can't point you to any formal research, but give some thougths based on
personal experience. May look like boring evidence for the many
opensource old-timers here, but it could be that with time we forgot
what brought us here.
A large part of it is related to community. This word means quite
different things depending on the point of view (company or employee) or
the kind of involvement you have with the open source software.
As an employee and a simple user, participating at any level to the
community of an opensource product you're using in your day job means
you meet people using the same product, possibly on similar projects,
and can ask questions, share experiences, etc. Seems quite natural for
us but it's a life-changer for people that can suddenly escape their
cubicle and discuss about subjects that are closely related to their
work, but for which they probably can't find anybody in their physical
environment they can talk to about.
So you basically find like-minded people you can share things with. And
this like-minded thing is even more important when you become an active
contributor, since you're most probably -- at first -- the only
contributor in your company. Other committers become your co-workers for
something that you can't share with any of your real physical
co-workers. This helps finding a lot of excitement and energy for
something that could well otherwise be just a boring job fighting with a
stubborn proprietary product for which you only have well organized
but inefficient support.
Opening your cubicle to the outside world also forces you to consider
all the things you don't know and have to learn. Can be frightening for
some, but also a way to greatly improve their skills for many, and
directly impact their project's quality. The developer improves, and the
company wins. This reminds me a blog post of mine 7 years ago (eek!) --
see [1]
Another important point is the availability of source code. In modern
IDEs like Eclipse, you just have to ctrl-click to open a class/module's
source code. As a developer, it's incredibly frustrating to hit the no
source code available barrier when using a proprietary product and just
make assumptions on how a given module works when things don't behave as
expected (first thing I do is to decompile it :-) but it doesn't always
give good results). It makes you more confident since you're building on
something you can dive into and understand, if not fix yourself.
I won't go into the benefits for a company, that you certainly know
well: no lock-in to a single provider, reduced acquisition costs,
long-time maintainance/availability because the product is not tied to a
company's life/strategy, etc, etc.
Hope this helps,
Sylvain
[1] http://bluxte.net/musings/2003/02/05/are-we-three-eyed
--
Sylvain Wallez - http://bluxte.net
-
To unsubscribe, e-mail: community-unsubscr...@apache.org
For additional
