[Freedombox-discuss] Paid FB developers
> I am curious to hear how those in favor of paying some contributions
> believe it will affect other contributions.
Sometimes people think that if some contributors are paid and others
are volunteer, the volunteers will feel slighted and won't contribute.
My experience is that it's possible to grow a satisfying ecosystem for
both volunteer and paid contributors, and that they complement each other.
When I was maintainer of GDB, we had both paid and volunteer
contributors. Most of the people who were paid to work on it worked
at Cygnus, building better support for C++, making it work on new
embedded processor architectures like the MIPS, H8 or the AMD 29000,
interfacing it to a new host or target OS, or adding GUI interfaces.
The volunteer contributors tended to be people who had a use for it in
their own work or life projects, and they contributed bug fixes, small
features, or ports to their favorite OS. But their changes tended to
break one thing while fixing another; or would add a feature while not
adding it to the documentation, etc. Frequently I used their proposed
patch more as a guideline to understanding the bug they'd found, than
as an actual patch to install. Those irregular contributors were
happy to have paid contributors and a paid maintainer, who they could
submit their bug reports and changes to, and who'd rewrite the small
changes into fully correct changes and get them into the release.
As an irregular contributor made more and more changes, I'd feed them
back critique on their patches, asking them to change particular
things until their patch was as good as I could make it. This
'trained them up' in the internals of GDB, which they tended to like,
and it also meant that I could just slide their later patches right
into the source tree, making the process more of a joy both for them
and for me.
GCC had a much broader base of contributors, some of whom were paid by
Cygnus, some of whom were paid by government contracts to work on GNU
Ada, some of whom were paid by their employer and did some GCC as part
of their job, some of whom were paid academics, some of whom were not
paid at all, and some students who were actually PAYING to do the
work. Overall it was a good deal to everyone. The community made
rapid progress on the code, regular releases happened and were of high
quality, people collaborated to bring proposed patches up to high
quality, and the irregular contributors could get their changes into
releases, so they could avoid maintaining a forked version.
As Cygnus grew, we were often able to hire a former volunteer or
student contributor to GCC, paying them to work on it full time. The
volunteers were invariably overjoyed to have their fun hobby turn into
a full-time paying job. (Any ones that weren't overjoyed at the
prospect simply wouldn't take the job.) And we at Cygnus were very
happy to have a big pool of active contributors, because before we
even thought of offering someone a job, we already knew the quality of
their work. That let us hire some of the most productive and
detail-oriented programmers I've ever had the pleasure to work with.
Volunteers tend to be poor at documentation and quality assurance. We
used paid staff to vastly improve the GCC and GDB manuals, and to
build large test suites for both, and to do the release engineering
required to make high quality releases every 12 weeks. But what
volunteers were great at were finding and opening niches -- markets
where our software almost worked, almost solved somebody's problem.
They would submit changes that started to solve that problem. They
pulled the software into that niche. This enabled us in the center to
see that there was indeed a need in the world to solve that problem,
and we could start devoting resources to it, or finding other
volunteers who shared the same needs. This is part of how the GNU
tools became much more useful in the embedded computing world.
John
Reply to: