The Trade-offs of Unpaid Free Software Labor

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/11/13/unpaid-tradeoff.html

I read with
interest Ashe
Dryden’s blog post entitled The Ethics of Unpaid Labor and the OSS
Community
0, and I
agree with much of it. At least, I agree with Dryden much more than I
agree with

Hanson’s blog post that inspired Dryden’s
, since Hanson’s seems almost
completely unaware of the distinctions between Free Software funding in
non-profit and for-profit settings, and I
think Dryden’s
criticism that Hanson’s view is narrowed by “white-male in a wealthy
country” privilege
is quite accurate. I think Dryden does
understand the distinctions of non-profit vs. for-profit Free Software
development, and Dryden’s has an excellent discussion on how wealthy and
powerful individuals by default have more leisure time to enter the (likely
fictional) Free Software development meritocracy via pure volunteer
efforts.

However, I think two key points remain missing in the discussions so far
on this topic. Specifically, (a) the issue of license design as it relates
to non-monetary compensation of volunteer efforts and (b) developers’ goals
in using volunteer Free Software labor to bootstrap employment. The two
issues don’t interrelate that much, so I’ll discuss them separately.

Copyleft Requirements as “Compensation” For Volunteer
Contribution

I’m not surprised that this discussion about volunteer vs. paid labor is
happening completely bereft of reference to the licenses of the software in
question. With companies and even many individuals so rabidly anti-copyleft
recently, I suspect that everyone in the discussion is assuming that the
underlying license structure of these volunteer contributions is
non-copyleft.

Strong copyleft’s design, however, deals specifically with
the problems inherent in uncompensated volunteer labor. By avoiding the
possibility of proprietary derivatives, copyleft ensures that volunteer
contributions do have, for lack of a better term, some strings attached:
the requirement that even big and powerful companies that use the code
treat the lowly volunteer contributor as a true equal.

Companies have resources that allows them to quickly capitalize on
improvements to Free Software contributed by volunteers, and thus the
volunteers are always at an economic disadvantage. Requiring that the
companies share improvements with the community ensures that the volunteers’
labor don’t go entirely uncompensated: at the very least, the volunteer
contributor has equal access to all improvements.

This phenomenon is in my opinion an argument for why there is less risk
and more opportunity for contributors to copylefted codebases. Copyleft
allows for some level of opportunity to the volunteer contributor that
doesn’t necessarily exist with non-copylefted codebases (i.e., the
contributor is assured equal access to later improvements), and certainly
doesn’t exist with proprietary software.

Volunteer Contribution As Employment Terms-Setting

An orthogonal issue is this trend that employers use Free Software
contribution as a hiring criterion. I’ve frankly found this trend
disturbing for a wholly different reason than those raised in the current
discussed. Namely, most employers who hire based on past Free Software
contribution don’t employ these developers to work on Free
Software!

Free Software is, frankly, in a state of cooption. (Open Source itself, as
a concept, is part of that cooption.) As another part of that cooption,
teams of proprietary software (or non-released, secret software) developers
use methodologies and workflows that were once unique to Free Software.
Therefore, these employers want to know if job candidates know those
workflows and methodologies so that the employer can pay the developer
to stop using those techniques for the good of software
freedom and instead use them for proprietary and/or secretive
software development.

When I was in graduate school, one of the reasons I keenly wanted to be a
core contributor to Free Software was not to just get paid for any
software development, but specifically to gain employment writing software
that would be Free Software. In those days, you picked a
codebase you liked because you wanted to be employed to work on that
upstream codebase
. In fact, becoming a core contributor for a widely
used copylefted codebase was once commonly a way to ensure you’d have
your pick of jobs being paid to work on that codebase.

These days, most developers, even though they are required to use some
Free Software as part of their jobs, usually are assigned work on some
non-Free Software that interacts with that Free Software. Thus,
the original meme, that began in the early 1990s, of volunteer
for a Free Software codebase so you can later get paid to work on it
,
has recently morphed into volunteer to work on Free Software so you can get a job
working on some proprietary software
. That practice is a complete
corruption and cooption of the Free Software culture.


All that said, I do agree with Dryden that we should do more
funding at the entry-level of Free Software development, and the
internships in particular, such as those through
the OPW are,
as Dryden writes, absolutely essential to solve the obvious problem of
under-representation by those with limited leisure time for volunteer
contribution. I think such funding is best when it’s done as part of a
non-profit rather than a for-profit settings, for reasons that would
require yet another blog post to explain.


0Please
note that I haven’t seen any of the comments on Dryden’s blog post or many of the
comments that spawned it, because as near as I can tell, I can’t use Disqus
without installing proprietary software on my computer, through its
proprietary Javascript. If someone can tell me how to read Disqus
discussions without proprietary Javascript, I’d appreciate it.