Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/12/05/non-profit-home.html

[ This post of mine is cross-posted
from Conservancy’s
blog.]

I came across this email
thread this week, and it seems to me that Node.js is facing a standard
decision that comes up in the life of most Open Source and Free Software
projects. It inspired me to write some general advice to Open Source and
Free Software projects who might be at a similar crossroads⁰. Specifically,
at some point in the history of a project, the community is faced with the
decision of whether the project should be housed at a specific for-profit
company, or have a non-profit entity behind it instead. Further, project
leaders must consider, if they persue the latter, whether the community
should form its own non-profit or affiliate with one that already exists.

Choosing a governance structure is a tough and complex decision for a
project — and there is always some status quo that (at least) seems
easier. Thus, there will always be a certain amount of acrimony in this
debate. I have my own biases on this, since I am the Executive Director of
Conservancy, a non-profit home for Open Source and Free Software projects,
and because I have studied the issue of non-profit governance for Open Source
and Free Software for the last decade. I have a few comments based on that
experience that might be helpful to projects who face this decision.

The obvious benefit of a project housed in a for-profit company is that
they’ll usually always have more resources to put toward the project —
particularly if the project is of strategic importance to their business.
The downside is that the company almost always controls the trademark,
perhaps controls the copyright to some extent (e.g., by being the sole
beneficiary of a very broad CLA or ©AA), and likely has a stronger say
in the technical direction of the project. There will also always be
“brand conflation” when something happens in the project (Did
the project do it, or did the company?), and such is easily observable in
the many for-profit-controlled Open Source and Free Software projects.

By contrast, while a for-profit entity only needs to consider the
interests of its own shareholders, a non-profit entity is legally required to
balance the needs of many contributors and users. Thus, non-profits are a
neutral home for activities of the project, and a neutral place for the
trademark to live, perhaps a neutral place to receive CLAs (if the community
even wants a CLA, that is), and to do other activities for the
project. (Conservancy, for its part, has a list of what services it
provides.)

There’s also difference among non-profit options. The primary two USA
options for Open Source and Free Software are 501(c)(3)’s (public charities)
and 501(c)(6)’s (trade associations). 501(c)(3) public charities must always
act in the public good, while 501(c)(6) trade associations act in interest of
its paying for-profit members. I’m a fan of the 501(c)(3)-style of
non-profit, again, because I help run one. IMO, the choice between the two
really depends on whether you want the project run and controlled by a
consortium of for-profit businesses, or if you want the project to operate as
a public charity focused on advancing the public good by producing better
Open Source and Free Software. BTW, the big benefit, IMO, to a 501(c)(3) is
that the non-profit only represents the interests of the project with
respect to the public good, so IRS prohibits the charity from conflating its
motives with any corporate interest (be they single or
aggregate).

If you decide you want a non-profit, there’s then the decision of forming
your own non-profit or affiliating with an existing non-profit. Folks who
say it’s easy to start a new non-profit are (mostly) correct; the
challenge is in keeping it running. It’s a tremendous amount of work and
effort to handle the day-to-day requirements of non-profit management, which
is why so many Open Source and Free Software projects choose to affiliate or
join with an existing non-profit rather than form their own. I’d suggest
strongly that the any community look into joining an existing home, in part
because many non-profit umbrellas permit the project to later “spin
off” to form your own non-profit. Thus, joining an existing entity is
not always a permanent decision.

Anyway, as you’ve guessed, thinking about these questions is a part of
what I do for a living. Thus, I’d love to talk (by email, phone or IRC) with
anyone in any Open Source and Free Software community about joining
Conservancy specifically, or even just to talk through all the non-profit
options available. There are many options and existing non-profits, all with
their own tweaks, so if a given community decides it’d like a non-profit
home, there’s lots to chose from and a lot to consider.

I’d note finally that the different tweaks between non-profit options
deserve careful attention. I often see people commenting that structures
imposed by non-profits won’t help with what they need. However, not all
non-profits have the same type of structures, and they focus on different
things. For example, Conservancy doesn’t dictate anything regarding specific
CLA rules, licensing, development models, and the like. Conservancy
generally advises about all the known options, and help the community come to
the conclusions it wants and implement them well. The only place Conservancy
has strict rules is with regard to the requirements and guidelines the IRS
puts forward on 501(c)(3) status. Meanwhile, other non-profits do
have strict rules for development models, or CLAs, and the like, which some
projects prefer for various reasons.

Update 2013-12-07: I posted
a follow
up on Node.js mailing list in the original discussion that inspired me
to write the above.

⁰BTW, I don’t
think how a community comes to that crossroads matters that
much, actually. At some point in a project’s history, this issue is raised,
and, at that moment, a decision is before the project.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/12/05/non-profit-home.html

[ This post of mine is cross-posted
from Conservancy’s
blog.]

I came across this email
thread this week, and it seems to me that Node.js is facing a standard
decision that comes up in the life of most Open Source and Free Software
projects. It inspired me to write some general advice to Open Source and
Free Software projects who might be at a similar crossroads⁰. Specifically,
at some point in the history of a project, the community is faced with the
decision of whether the project should be housed at a specific for-profit
company, or have a non-profit entity behind it instead. Further, project
leaders must consider, if they persue the latter, whether the community
should form its own non-profit or affiliate with one that already exists.

Choosing a governance structure is a tough and complex decision for a
project — and there is always some status quo that (at least) seems
easier. Thus, there will always be a certain amount of acrimony in this
debate. I have my own biases on this, since I am the Executive Director of
Conservancy, a non-profit home for Open Source and Free Software projects,
and because I have studied the issue of non-profit governance for Open Source
and Free Software for the last decade. I have a few comments based on that
experience that might be helpful to projects who face this decision.

The obvious benefit of a project housed in a for-profit company is that
they’ll usually always have more resources to put toward the project —
particularly if the project is of strategic importance to their business.
The downside is that the company almost always controls the trademark,
perhaps controls the copyright to some extent (e.g., by being the sole
beneficiary of a very broad CLA or ©AA), and likely has a stronger say
in the technical direction of the project. There will also always be
“brand conflation” when something happens in the project (Did
the project do it, or did the company?), and such is easily observable in
the many for-profit-controlled Open Source and Free Software projects.

By contrast, while a for-profit entity only needs to consider the
interests of its own shareholders, a non-profit entity is legally required to
balance the needs of many contributors and users. Thus, non-profits are a
neutral home for activities of the project, and a neutral place for the
trademark to live, perhaps a neutral place to receive CLAs (if the community
even wants a CLA, that is), and to do other activities for the
project. (Conservancy, for its part, has a list of what services it
provides.)

There’s also difference among non-profit options. The primary two USA
options for Open Source and Free Software are 501(c)(3)’s (public charities)
and 501(c)(6)’s (trade associations). 501(c)(3) public charities must always
act in the public good, while 501(c)(6) trade associations act in interest of
its paying for-profit members. I’m a fan of the 501(c)(3)-style of
non-profit, again, because I help run one. IMO, the choice between the two
really depends on whether you want the project run and controlled by a
consortium of for-profit businesses, or if you want the project to operate as
a public charity focused on advancing the public good by producing better
Open Source and Free Software. BTW, the big benefit, IMO, to a 501(c)(3) is
that the non-profit only represents the interests of the project with
respect to the public good, so IRS prohibits the charity from conflating its
motives with any corporate interest (be they single or
aggregate).

If you decide you want a non-profit, there’s then the decision of forming
your own non-profit or affiliating with an existing non-profit. Folks who
say it’s easy to start a new non-profit are (mostly) correct; the
challenge is in keeping it running. It’s a tremendous amount of work and
effort to handle the day-to-day requirements of non-profit management, which
is why so many Open Source and Free Software projects choose to affiliate or
join with an existing non-profit rather than form their own. I’d suggest
strongly that the any community look into joining an existing home, in part
because many non-profit umbrellas permit the project to later “spin
off” to form your own non-profit. Thus, joining an existing entity is
not always a permanent decision.

Anyway, as you’ve guessed, thinking about these questions is a part of
what I do for a living. Thus, I’d love to talk (by email, phone or IRC) with
anyone in any Open Source and Free Software community about joining
Conservancy specifically, or even just to talk through all the non-profit
options available. There are many options and existing non-profits, all with
their own tweaks, so if a given community decides it’d like a non-profit
home, there’s lots to chose from and a lot to consider.

I’d note finally that the different tweaks between non-profit options
deserve careful attention. I often see people commenting that structures
imposed by non-profits won’t help with what they need. However, not all
non-profits have the same type of structures, and they focus on different
things. For example, Conservancy doesn’t dictate anything regarding specific
CLA rules, licensing, development models, and the like. Conservancy
generally advises about all the known options, and help the community come to
the conclusions it wants and implement them well. The only place Conservancy
has strict rules is with regard to the requirements and guidelines the IRS
puts forward on 501(c)(3) status. Meanwhile, other non-profits do
have strict rules for development models, or CLAs, and the like, which some
projects prefer for various reasons.

Update 2013-12-07: I posted
a follow
up on Node.js mailing list in the original discussion that inspired me
to write the above.

⁰BTW, I don’t
think how a community comes to that crossroads matters that
much, actually. At some point in a project’s history, this issue is raised,
and, at that moment, a decision is before the project.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/12/05/non-profit-home.html

[ This post of mine is cross-posted
from Conservancy’s
blog.]

I came across this email
thread this week, and it seems to me that Node.js is facing a standard
decision that comes up in the life of most Open Source and Free Software
projects. It inspired me to write some general advice to Open Source and
Free Software projects who might be at a similar crossroads⁰. Specifically,
at some point in the history of a project, the community is faced with the
decision of whether the project should be housed at a specific for-profit
company, or have a non-profit entity behind it instead. Further, project
leaders must consider, if they persue the latter, whether the community
should form its own non-profit or affiliate with one that already exists.

Choosing a governance structure is a tough and complex decision for a
project — and there is always some status quo that (at least) seems
easier. Thus, there will always be a certain amount of acrimony in this
debate. I have my own biases on this, since I am the Executive Director of
Conservancy, a non-profit home for Open Source and Free Software projects,
and because I have studied the issue of non-profit governance for Open Source
and Free Software for the last decade. I have a few comments based on that
experience that might be helpful to projects who face this decision.

The obvious benefit of a project housed in a for-profit company is that
they’ll usually always have more resources to put toward the project —
particularly if the project is of strategic importance to their business.
The downside is that the company almost always controls the trademark,
perhaps controls the copyright to some extent (e.g., by being the sole
beneficiary of a very broad CLA or ©AA), and likely has a stronger say
in the technical direction of the project. There will also always be
“brand conflation” when something happens in the project (Did
the project do it, or did the company?), and such is easily observable in
the many for-profit-controlled Open Source and Free Software projects.

By contrast, while a for-profit entity only needs to consider the
interests of its own shareholders, a non-profit entity is legally required to
balance the needs of many contributors and users. Thus, non-profits are a
neutral home for activities of the project, and a neutral place for the
trademark to live, perhaps a neutral place to receive CLAs (if the community
even wants a CLA, that is), and to do other activities for the
project. (Conservancy, for its part, has a list of what services it
provides.)

There’s also difference among non-profit options. The primary two USA
options for Open Source and Free Software are 501(c)(3)’s (public charities)
and 501(c)(6)’s (trade associations). 501(c)(3) public charities must always
act in the public good, while 501(c)(6) trade associations act in interest of
its paying for-profit members. I’m a fan of the 501(c)(3)-style of
non-profit, again, because I help run one. IMO, the choice between the two
really depends on whether you want the project run and controlled by a
consortium of for-profit businesses, or if you want the project to operate as
a public charity focused on advancing the public good by producing better
Open Source and Free Software. BTW, the big benefit, IMO, to a 501(c)(3) is
that the non-profit only represents the interests of the project with
respect to the public good, so IRS prohibits the charity from conflating its
motives with any corporate interest (be they single or
aggregate).

If you decide you want a non-profit, there’s then the decision of forming
your own non-profit or affiliating with an existing non-profit. Folks who
say it’s easy to start a new non-profit are (mostly) correct; the
challenge is in keeping it running. It’s a tremendous amount of work and
effort to handle the day-to-day requirements of non-profit management, which
is why so many Open Source and Free Software projects choose to affiliate or
join with an existing non-profit rather than form their own. I’d suggest
strongly that the any community look into joining an existing home, in part
because many non-profit umbrellas permit the project to later “spin
off” to form your own non-profit. Thus, joining an existing entity is
not always a permanent decision.

Anyway, as you’ve guessed, thinking about these questions is a part of
what I do for a living. Thus, I’d love to talk (by email, phone or IRC) with
anyone in any Open Source and Free Software community about joining
Conservancy specifically, or even just to talk through all the non-profit
options available. There are many options and existing non-profits, all with
their own tweaks, so if a given community decides it’d like a non-profit
home, there’s lots to chose from and a lot to consider.

I’d note finally that the different tweaks between non-profit options
deserve careful attention. I often see people commenting that structures
imposed by non-profits won’t help with what they need. However, not all
non-profits have the same type of structures, and they focus on different
things. For example, Conservancy doesn’t dictate anything regarding specific
CLA rules, licensing, development models, and the like. Conservancy
generally advises about all the known options, and help the community come to
the conclusions it wants and implement them well. The only place Conservancy
has strict rules is with regard to the requirements and guidelines the IRS
puts forward on 501(c)(3) status. Meanwhile, other non-profits do
have strict rules for development models, or CLAs, and the like, which some
projects prefer for various reasons.

Update 2013-12-07: I posted
a follow
up on Node.js mailing list in the original discussion that inspired me
to write the above.

⁰BTW, I don’t
think how a community comes to that crossroads matters that
much, actually. At some point in a project’s history, this issue is raised,
and, at that moment, a decision is before the project.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/12/05/non-profit-home.html

[ This post of mine is cross-posted
from Conservancy’s
blog.]

I came across this email
thread this week, and it seems to me that Node.js is facing a standard
decision that comes up in the life of most Open Source and Free Software
projects. It inspired me to write some general advice to Open Source and
Free Software projects who might be at a similar crossroads⁰. Specifically,
at some point in the history of a project, the community is faced with the
decision of whether the project should be housed at a specific for-profit
company, or have a non-profit entity behind it instead. Further, project
leaders must consider, if they persue the latter, whether the community
should form its own non-profit or affiliate with one that already exists.

Choosing a governance structure is a tough and complex decision for a
project — and there is always some status quo that (at least) seems
easier. Thus, there will always be a certain amount of acrimony in this
debate. I have my own biases on this, since I am the Executive Director of
Conservancy, a non-profit home for Open Source and Free Software projects,
and because I have studied the issue of non-profit governance for Open Source
and Free Software for the last decade. I have a few comments based on that
experience that might be helpful to projects who face this decision.

The obvious benefit of a project housed in a for-profit company is that
they’ll usually always have more resources to put toward the project —
particularly if the project is of strategic importance to their business.
The downside is that the company almost always controls the trademark,
perhaps controls the copyright to some extent (e.g., by being the sole
beneficiary of a very broad CLA or ©AA), and likely has a stronger say
in the technical direction of the project. There will also always be
“brand conflation” when something happens in the project (Did
the project do it, or did the company?), and such is easily observable in
the many for-profit-controlled Open Source and Free Software projects.

By contrast, while a for-profit entity only needs to consider the
interests of its own shareholders, a non-profit entity is legally required to
balance the needs of many contributors and users. Thus, non-profits are a
neutral home for activities of the project, and a neutral place for the
trademark to live, perhaps a neutral place to receive CLAs (if the community
even wants a CLA, that is), and to do other activities for the
project. (Conservancy, for its part, has a list of what services it
provides.)

There’s also difference among non-profit options. The primary two USA
options for Open Source and Free Software are 501(c)(3)’s (public charities)
and 501(c)(6)’s (trade associations). 501(c)(3) public charities must always
act in the public good, while 501(c)(6) trade associations act in interest of
its paying for-profit members. I’m a fan of the 501(c)(3)-style of
non-profit, again, because I help run one. IMO, the choice between the two
really depends on whether you want the project run and controlled by a
consortium of for-profit businesses, or if you want the project to operate as
a public charity focused on advancing the public good by producing better
Open Source and Free Software. BTW, the big benefit, IMO, to a 501(c)(3) is
that the non-profit only represents the interests of the project with
respect to the public good, so IRS prohibits the charity from conflating its
motives with any corporate interest (be they single or
aggregate).

If you decide you want a non-profit, there’s then the decision of forming
your own non-profit or affiliating with an existing non-profit. Folks who
say it’s easy to start a new non-profit are (mostly) correct; the
challenge is in keeping it running. It’s a tremendous amount of work and
effort to handle the day-to-day requirements of non-profit management, which
is why so many Open Source and Free Software projects choose to affiliate or
join with an existing non-profit rather than form their own. I’d suggest
strongly that the any community look into joining an existing home, in part
because many non-profit umbrellas permit the project to later “spin
off” to form your own non-profit. Thus, joining an existing entity is
not always a permanent decision.

Anyway, as you’ve guessed, thinking about these questions is a part of
what I do for a living. Thus, I’d love to talk (by email, phone or IRC) with
anyone in any Open Source and Free Software community about joining
Conservancy specifically, or even just to talk through all the non-profit
options available. There are many options and existing non-profits, all with
their own tweaks, so if a given community decides it’d like a non-profit
home, there’s lots to chose from and a lot to consider.

I’d note finally that the different tweaks between non-profit options
deserve careful attention. I often see people commenting that structures
imposed by non-profits won’t help with what they need. However, not all
non-profits have the same type of structures, and they focus on different
things. For example, Conservancy doesn’t dictate anything regarding specific
CLA rules, licensing, development models, and the like. Conservancy
generally advises about all the known options, and help the community come to
the conclusions it wants and implement them well. The only place Conservancy
has strict rules is with regard to the requirements and guidelines the IRS
puts forward on 501(c)(3) status. Meanwhile, other non-profits do
have strict rules for development models, or CLAs, and the like, which some
projects prefer for various reasons.

Update 2013-12-07: I posted
a follow
up on Node.js mailing list in the original discussion that inspired me
to write the above.

⁰BTW, I don’t
think how a community comes to that crossroads matters that
much, actually. At some point in a project’s history, this issue is raised,
and, at that moment, a decision is before the project.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/12/05/non-profit-home.html

[ This post of mine is cross-posted
from Conservancy’s
blog.]

I came across this email
thread this week, and it seems to me that Node.js is facing a standard
decision that comes up in the life of most Open Source and Free Software
projects. It inspired me to write some general advice to Open Source and
Free Software projects who might be at a similar crossroads⁰. Specifically,
at some point in the history of a project, the community is faced with the
decision of whether the project should be housed at a specific for-profit
company, or have a non-profit entity behind it instead. Further, project
leaders must consider, if they persue the latter, whether the community
should form its own non-profit or affiliate with one that already exists.

Choosing a governance structure is a tough and complex decision for a
project — and there is always some status quo that (at least) seems
easier. Thus, there will always be a certain amount of acrimony in this
debate. I have my own biases on this, since I am the Executive Director of
Conservancy, a non-profit home for Open Source and Free Software projects,
and because I have studied the issue of non-profit governance for Open Source
and Free Software for the last decade. I have a few comments based on that
experience that might be helpful to projects who face this decision.

The obvious benefit of a project housed in a for-profit company is that
they’ll usually always have more resources to put toward the project —
particularly if the project is of strategic importance to their business.
The downside is that the company almost always controls the trademark,
perhaps controls the copyright to some extent (e.g., by being the sole
beneficiary of a very broad CLA or ©AA), and likely has a stronger say
in the technical direction of the project. There will also always be
“brand conflation” when something happens in the project (Did
the project do it, or did the company?), and such is easily observable in
the many for-profit-controlled Open Source and Free Software projects.

By contrast, while a for-profit entity only needs to consider the
interests of its own shareholders, a non-profit entity is legally required to
balance the needs of many contributors and users. Thus, non-profits are a
neutral home for activities of the project, and a neutral place for the
trademark to live, perhaps a neutral place to receive CLAs (if the community
even wants a CLA, that is), and to do other activities for the
project. (Conservancy, for its part, has a list of what services it
provides.)

There’s also difference among non-profit options. The primary two USA
options for Open Source and Free Software are 501(c)(3)’s (public charities)
and 501(c)(6)’s (trade associations). 501(c)(3) public charities must always
act in the public good, while 501(c)(6) trade associations act in interest of
its paying for-profit members. I’m a fan of the 501(c)(3)-style of
non-profit, again, because I help run one. IMO, the choice between the two
really depends on whether you want the project run and controlled by a
consortium of for-profit businesses, or if you want the project to operate as
a public charity focused on advancing the public good by producing better
Open Source and Free Software. BTW, the big benefit, IMO, to a 501(c)(3) is
that the non-profit only represents the interests of the project with
respect to the public good, so IRS prohibits the charity from conflating its
motives with any corporate interest (be they single or
aggregate).

If you decide you want a non-profit, there’s then the decision of forming
your own non-profit or affiliating with an existing non-profit. Folks who
say it’s easy to start a new non-profit are (mostly) correct; the
challenge is in keeping it running. It’s a tremendous amount of work and
effort to handle the day-to-day requirements of non-profit management, which
is why so many Open Source and Free Software projects choose to affiliate or
join with an existing non-profit rather than form their own. I’d suggest
strongly that the any community look into joining an existing home, in part
because many non-profit umbrellas permit the project to later “spin
off” to form your own non-profit. Thus, joining an existing entity is
not always a permanent decision.

Anyway, as you’ve guessed, thinking about these questions is a part of
what I do for a living. Thus, I’d love to talk (by email, phone or IRC) with
anyone in any Open Source and Free Software community about joining
Conservancy specifically, or even just to talk through all the non-profit
options available. There are many options and existing non-profits, all with
their own tweaks, so if a given community decides it’d like a non-profit
home, there’s lots to chose from and a lot to consider.

I’d note finally that the different tweaks between non-profit options
deserve careful attention. I often see people commenting that structures
imposed by non-profits won’t help with what they need. However, not all
non-profits have the same type of structures, and they focus on different
things. For example, Conservancy doesn’t dictate anything regarding specific
CLA rules, licensing, development models, and the like. Conservancy
generally advises about all the known options, and help the community come to
the conclusions it wants and implement them well. The only place Conservancy
has strict rules is with regard to the requirements and guidelines the IRS
puts forward on 501(c)(3) status. Meanwhile, other non-profits do
have strict rules for development models, or CLAs, and the like, which some
projects prefer for various reasons.

Update 2013-12-07: I posted
a follow
up on Node.js mailing list in the original discussion that inspired me
to write the above.

⁰BTW, I don’t
think how a community comes to that crossroads matters that
much, actually. At some point in a project’s history, this issue is raised,
and, at that moment, a decision is before the project.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/12/05/non-profit-home.html

[ This post of mine is cross-posted
from Conservancy’s
blog.]

I came across this email
thread this week, and it seems to me that Node.js is facing a standard
decision that comes up in the life of most Open Source and Free Software
projects. It inspired me to write some general advice to Open Source and
Free Software projects who might be at a similar crossroads⁰. Specifically,
at some point in the history of a project, the community is faced with the
decision of whether the project should be housed at a specific for-profit
company, or have a non-profit entity behind it instead. Further, project
leaders must consider, if they persue the latter, whether the community
should form its own non-profit or affiliate with one that already exists.

Choosing a governance structure is a tough and complex decision for a
project — and there is always some status quo that (at least) seems
easier. Thus, there will always be a certain amount of acrimony in this
debate. I have my own biases on this, since I am the Executive Director of
Conservancy, a non-profit home for Open Source and Free Software projects,
and because I have studied the issue of non-profit governance for Open Source
and Free Software for the last decade. I have a few comments based on that
experience that might be helpful to projects who face this decision.

The obvious benefit of a project housed in a for-profit company is that
they’ll usually always have more resources to put toward the project —
particularly if the project is of strategic importance to their business.
The downside is that the company almost always controls the trademark,
perhaps controls the copyright to some extent (e.g., by being the sole
beneficiary of a very broad CLA or ©AA), and likely has a stronger say
in the technical direction of the project. There will also always be
“brand conflation” when something happens in the project (Did
the project do it, or did the company?), and such is easily observable in
the many for-profit-controlled Open Source and Free Software projects.

By contrast, while a for-profit entity only needs to consider the
interests of its own shareholders, a non-profit entity is legally required to
balance the needs of many contributors and users. Thus, non-profits are a
neutral home for activities of the project, and a neutral place for the
trademark to live, perhaps a neutral place to receive CLAs (if the community
even wants a CLA, that is), and to do other activities for the
project. (Conservancy, for its part, has a list of what services it
provides.)

There’s also difference among non-profit options. The primary two USA
options for Open Source and Free Software are 501(c)(3)’s (public charities)
and 501(c)(6)’s (trade associations). 501(c)(3) public charities must always
act in the public good, while 501(c)(6) trade associations act in interest of
its paying for-profit members. I’m a fan of the 501(c)(3)-style of
non-profit, again, because I help run one. IMO, the choice between the two
really depends on whether you want the project run and controlled by a
consortium of for-profit businesses, or if you want the project to operate as
a public charity focused on advancing the public good by producing better
Open Source and Free Software. BTW, the big benefit, IMO, to a 501(c)(3) is
that the non-profit only represents the interests of the project with
respect to the public good, so IRS prohibits the charity from conflating its
motives with any corporate interest (be they single or
aggregate).

If you decide you want a non-profit, there’s then the decision of forming
your own non-profit or affiliating with an existing non-profit. Folks who
say it’s easy to start a new non-profit are (mostly) correct; the
challenge is in keeping it running. It’s a tremendous amount of work and
effort to handle the day-to-day requirements of non-profit management, which
is why so many Open Source and Free Software projects choose to affiliate or
join with an existing non-profit rather than form their own. I’d suggest
strongly that the any community look into joining an existing home, in part
because many non-profit umbrellas permit the project to later “spin
off” to form your own non-profit. Thus, joining an existing entity is
not always a permanent decision.

Anyway, as you’ve guessed, thinking about these questions is a part of
what I do for a living. Thus, I’d love to talk (by email, phone or IRC) with
anyone in any Open Source and Free Software community about joining
Conservancy specifically, or even just to talk through all the non-profit
options available. There are many options and existing non-profits, all with
their own tweaks, so if a given community decides it’d like a non-profit
home, there’s lots to chose from and a lot to consider.

I’d note finally that the different tweaks between non-profit options
deserve careful attention. I often see people commenting that structures
imposed by non-profits won’t help with what they need. However, not all
non-profits have the same type of structures, and they focus on different
things. For example, Conservancy doesn’t dictate anything regarding specific
CLA rules, licensing, development models, and the like. Conservancy
generally advises about all the known options, and help the community come to
the conclusions it wants and implement them well. The only place Conservancy
has strict rules is with regard to the requirements and guidelines the IRS
puts forward on 501(c)(3) status. Meanwhile, other non-profits do
have strict rules for development models, or CLAs, and the like, which some
projects prefer for various reasons.

Update 2013-12-07: I posted
a follow
up on Node.js mailing list in the original discussion that inspired me
to write the above.

⁰BTW, I don’t
think how a community comes to that crossroads matters that
much, actually. At some point in a project’s history, this issue is raised,
and, at that moment, a decision is before the project.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/12/05/non-profit-home.html

[ This post of mine is cross-posted
from Conservancy’s
blog.]

I came across this email
thread this week, and it seems to me that Node.js is facing a standard
decision that comes up in the life of most Open Source and Free Software
projects. It inspired me to write some general advice to Open Source and
Free Software projects who might be at a similar crossroads⁰. Specifically,
at some point in the history of a project, the community is faced with the
decision of whether the project should be housed at a specific for-profit
company, or have a non-profit entity behind it instead. Further, project
leaders must consider, if they persue the latter, whether the community
should form its own non-profit or affiliate with one that already exists.

Choosing a governance structure is a tough and complex decision for a
project — and there is always some status quo that (at least) seems
easier. Thus, there will always be a certain amount of acrimony in this
debate. I have my own biases on this, since I am the Executive Director of
Conservancy, a non-profit home for Open Source and Free Software projects,
and because I have studied the issue of non-profit governance for Open Source
and Free Software for the last decade. I have a few comments based on that
experience that might be helpful to projects who face this decision.

The obvious benefit of a project housed in a for-profit company is that
they’ll usually always have more resources to put toward the project —
particularly if the project is of strategic importance to their business.
The downside is that the company almost always controls the trademark,
perhaps controls the copyright to some extent (e.g., by being the sole
beneficiary of a very broad CLA or ©AA), and likely has a stronger say
in the technical direction of the project. There will also always be
“brand conflation” when something happens in the project (Did
the project do it, or did the company?), and such is easily observable in
the many for-profit-controlled Open Source and Free Software projects.

By contrast, while a for-profit entity only needs to consider the
interests of its own shareholders, a non-profit entity is legally required to
balance the needs of many contributors and users. Thus, non-profits are a
neutral home for activities of the project, and a neutral place for the
trademark to live, perhaps a neutral place to receive CLAs (if the community
even wants a CLA, that is), and to do other activities for the
project. (Conservancy, for its part, has a list of what services it
provides.)

There’s also difference among non-profit options. The primary two USA
options for Open Source and Free Software are 501(c)(3)’s (public charities)
and 501(c)(6)’s (trade associations). 501(c)(3) public charities must always
act in the public good, while 501(c)(6) trade associations act in interest of
its paying for-profit members. I’m a fan of the 501(c)(3)-style of
non-profit, again, because I help run one. IMO, the choice between the two
really depends on whether you want the project run and controlled by a
consortium of for-profit businesses, or if you want the project to operate as
a public charity focused on advancing the public good by producing better
Open Source and Free Software. BTW, the big benefit, IMO, to a 501(c)(3) is
that the non-profit only represents the interests of the project with
respect to the public good, so IRS prohibits the charity from conflating its
motives with any corporate interest (be they single or
aggregate).

If you decide you want a non-profit, there’s then the decision of forming
your own non-profit or affiliating with an existing non-profit. Folks who
say it’s easy to start a new non-profit are (mostly) correct; the
challenge is in keeping it running. It’s a tremendous amount of work and
effort to handle the day-to-day requirements of non-profit management, which
is why so many Open Source and Free Software projects choose to affiliate or
join with an existing non-profit rather than form their own. I’d suggest
strongly that the any community look into joining an existing home, in part
because many non-profit umbrellas permit the project to later “spin
off” to form your own non-profit. Thus, joining an existing entity is
not always a permanent decision.

Anyway, as you’ve guessed, thinking about these questions is a part of
what I do for a living. Thus, I’d love to talk (by email, phone or IRC) with
anyone in any Open Source and Free Software community about joining
Conservancy specifically, or even just to talk through all the non-profit
options available. There are many options and existing non-profits, all with
their own tweaks, so if a given community decides it’d like a non-profit
home, there’s lots to chose from and a lot to consider.

I’d note finally that the different tweaks between non-profit options
deserve careful attention. I often see people commenting that structures
imposed by non-profits won’t help with what they need. However, not all
non-profits have the same type of structures, and they focus on different
things. For example, Conservancy doesn’t dictate anything regarding specific
CLA rules, licensing, development models, and the like. Conservancy
generally advises about all the known options, and help the community come to
the conclusions it wants and implement them well. The only place Conservancy
has strict rules is with regard to the requirements and guidelines the IRS
puts forward on 501(c)(3) status. Meanwhile, other non-profits do
have strict rules for development models, or CLAs, and the like, which some
projects prefer for various reasons.

Update 2013-12-07: I posted
a follow
up on Node.js mailing list in the original discussion that inspired me
to write the above.

⁰BTW, I don’t
think how a community comes to that crossroads matters that
much, actually. At some point in a project’s history, this issue is raised,
and, at that moment, a decision is before the project.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/12/05/non-profit-home.html

[ This post of mine is cross-posted
from Conservancy’s
blog.]

I came across this email
thread this week, and it seems to me that Node.js is facing a standard
decision that comes up in the life of most Open Source and Free Software
projects. It inspired me to write some general advice to Open Source and
Free Software projects who might be at a similar crossroads⁰. Specifically,
at some point in the history of a project, the community is faced with the
decision of whether the project should be housed at a specific for-profit
company, or have a non-profit entity behind it instead. Further, project
leaders must consider, if they persue the latter, whether the community
should form its own non-profit or affiliate with one that already exists.

Choosing a governance structure is a tough and complex decision for a
project — and there is always some status quo that (at least) seems
easier. Thus, there will always be a certain amount of acrimony in this
debate. I have my own biases on this, since I am the Executive Director of
Conservancy, a non-profit home for Open Source and Free Software projects,
and because I have studied the issue of non-profit governance for Open Source
and Free Software for the last decade. I have a few comments based on that
experience that might be helpful to projects who face this decision.

The obvious benefit of a project housed in a for-profit company is that
they’ll usually always have more resources to put toward the project —
particularly if the project is of strategic importance to their business.
The downside is that the company almost always controls the trademark,
perhaps controls the copyright to some extent (e.g., by being the sole
beneficiary of a very broad CLA or ©AA), and likely has a stronger say
in the technical direction of the project. There will also always be
“brand conflation” when something happens in the project (Did
the project do it, or did the company?), and such is easily observable in
the many for-profit-controlled Open Source and Free Software projects.

By contrast, while a for-profit entity only needs to consider the
interests of its own shareholders, a non-profit entity is legally required to
balance the needs of many contributors and users. Thus, non-profits are a
neutral home for activities of the project, and a neutral place for the
trademark to live, perhaps a neutral place to receive CLAs (if the community
even wants a CLA, that is), and to do other activities for the
project. (Conservancy, for its part, has a list of what services it
provides.)

There’s also difference among non-profit options. The primary two USA
options for Open Source and Free Software are 501(c)(3)’s (public charities)
and 501(c)(6)’s (trade associations). 501(c)(3) public charities must always
act in the public good, while 501(c)(6) trade associations act in interest of
its paying for-profit members. I’m a fan of the 501(c)(3)-style of
non-profit, again, because I help run one. IMO, the choice between the two
really depends on whether you want the project run and controlled by a
consortium of for-profit businesses, or if you want the project to operate as
a public charity focused on advancing the public good by producing better
Open Source and Free Software. BTW, the big benefit, IMO, to a 501(c)(3) is
that the non-profit only represents the interests of the project with
respect to the public good, so IRS prohibits the charity from conflating its
motives with any corporate interest (be they single or
aggregate).

If you decide you want a non-profit, there’s then the decision of forming
your own non-profit or affiliating with an existing non-profit. Folks who
say it’s easy to start a new non-profit are (mostly) correct; the
challenge is in keeping it running. It’s a tremendous amount of work and
effort to handle the day-to-day requirements of non-profit management, which
is why so many Open Source and Free Software projects choose to affiliate or
join with an existing non-profit rather than form their own. I’d suggest
strongly that the any community look into joining an existing home, in part
because many non-profit umbrellas permit the project to later “spin
off” to form your own non-profit. Thus, joining an existing entity is
not always a permanent decision.

Anyway, as you’ve guessed, thinking about these questions is a part of
what I do for a living. Thus, I’d love to talk (by email, phone or IRC) with
anyone in any Open Source and Free Software community about joining
Conservancy specifically, or even just to talk through all the non-profit
options available. There are many options and existing non-profits, all with
their own tweaks, so if a given community decides it’d like a non-profit
home, there’s lots to chose from and a lot to consider.

I’d note finally that the different tweaks between non-profit options
deserve careful attention. I often see people commenting that structures
imposed by non-profits won’t help with what they need. However, not all
non-profits have the same type of structures, and they focus on different
things. For example, Conservancy doesn’t dictate anything regarding specific
CLA rules, licensing, development models, and the like. Conservancy
generally advises about all the known options, and help the community come to
the conclusions it wants and implement them well. The only place Conservancy
has strict rules is with regard to the requirements and guidelines the IRS
puts forward on 501(c)(3) status. Meanwhile, other non-profits do
have strict rules for development models, or CLAs, and the like, which some
projects prefer for various reasons.

Update 2013-12-07: I posted
a follow
up on Node.js mailing list in the original discussion that inspired me
to write the above.

⁰BTW, I don’t
think how a community comes to that crossroads matters that
much, actually. At some point in a project’s history, this issue is raised,
and, at that moment, a decision is before the project.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2013/12/05/non-profit-home.html

[ This post of mine is cross-posted
from Conservancy’s
blog.]

I came across this email
thread this week, and it seems to me that Node.js is facing a standard
decision that comes up in the life of most Open Source and Free Software
projects. It inspired me to write some general advice to Open Source and
Free Software projects who might be at a similar crossroads⁰. Specifically,
at some point in the history of a project, the community is faced with the
decision of whether the project should be housed at a specific for-profit
company, or have a non-profit entity behind it instead. Further, project
leaders must consider, if they persue the latter, whether the community
should form its own non-profit or affiliate with one that already exists.

Choosing a governance structure is a tough and complex decision for a
project — and there is always some status quo that (at least) seems
easier. Thus, there will always be a certain amount of acrimony in this
debate. I have my own biases on this, since I am the Executive Director of
Conservancy, a non-profit home for Open Source and Free Software projects,
and because I have studied the issue of non-profit governance for Open Source
and Free Software for the last decade. I have a few comments based on that
experience that might be helpful to projects who face this decision.

The obvious benefit of a project housed in a for-profit company is that
they’ll usually always have more resources to put toward the project —
particularly if the project is of strategic importance to their business.
The downside is that the company almost always controls the trademark,
perhaps controls the copyright to some extent (e.g., by being the sole
beneficiary of a very broad CLA or ©AA), and likely has a stronger say
in the technical direction of the project. There will also always be
“brand conflation” when something happens in the project (Did
the project do it, or did the company?), and such is easily observable in
the many for-profit-controlled Open Source and Free Software projects.

By contrast, while a for-profit entity only needs to consider the
interests of its own shareholders, a non-profit entity is legally required to
balance the needs of many contributors and users. Thus, non-profits are a
neutral home for activities of the project, and a neutral place for the
trademark to live, perhaps a neutral place to receive CLAs (if the community
even wants a CLA, that is), and to do other activities for the
project. (Conservancy, for its part, has a list of what services it
provides.)

There’s also difference among non-profit options. The primary two USA
options for Open Source and Free Software are 501(c)(3)’s (public charities)
and 501(c)(6)’s (trade associations). 501(c)(3) public charities must always
act in the public good, while 501(c)(6) trade associations act in interest of
its paying for-profit members. I’m a fan of the 501(c)(3)-style of
non-profit, again, because I help run one. IMO, the choice between the two
really depends on whether you want the project run and controlled by a
consortium of for-profit businesses, or if you want the project to operate as
a public charity focused on advancing the public good by producing better
Open Source and Free Software. BTW, the big benefit, IMO, to a 501(c)(3) is
that the non-profit only represents the interests of the project with
respect to the public good, so IRS prohibits the charity from conflating its
motives with any corporate interest (be they single or
aggregate).

If you decide you want a non-profit, there’s then the decision of forming
your own non-profit or affiliating with an existing non-profit. Folks who
say it’s easy to start a new non-profit are (mostly) correct; the
challenge is in keeping it running. It’s a tremendous amount of work and
effort to handle the day-to-day requirements of non-profit management, which
is why so many Open Source and Free Software projects choose to affiliate or
join with an existing non-profit rather than form their own. I’d suggest
strongly that the any community look into joining an existing home, in part
because many non-profit umbrellas permit the project to later “spin
off” to form your own non-profit. Thus, joining an existing entity is
not always a permanent decision.

Anyway, as you’ve guessed, thinking about these questions is a part of
what I do for a living. Thus, I’d love to talk (by email, phone or IRC) with
anyone in any Open Source and Free Software community about joining
Conservancy specifically, or even just to talk through all the non-profit
options available. There are many options and existing non-profits, all with
their own tweaks, so if a given community decides it’d like a non-profit
home, there’s lots to chose from and a lot to consider.

I’d note finally that the different tweaks between non-profit options
deserve careful attention. I often see people commenting that structures
imposed by non-profits won’t help with what they need. However, not all
non-profits have the same type of structures, and they focus on different
things. For example, Conservancy doesn’t dictate anything regarding specific
CLA rules, licensing, development models, and the like. Conservancy
generally advises about all the known options, and help the community come to
the conclusions it wants and implement them well. The only place Conservancy
has strict rules is with regard to the requirements and guidelines the IRS
puts forward on 501(c)(3) status. Meanwhile, other non-profits do
have strict rules for development models, or CLAs, and the like, which some
projects prefer for various reasons.

Update 2013-12-07: I posted
a follow
up on Node.js mailing list in the original discussion that inspired me
to write the above.

⁰BTW, I don’t
think how a community comes to that crossroads matters that
much, actually. At some point in a project’s history, this issue is raised,
and, at that moment, a decision is before the project.

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⁰, 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.

⁰Please
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.

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⁰, 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.

⁰Please
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.

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⁰, 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.

⁰Please
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.

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⁰, 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.

⁰Please
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.

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⁰, 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.

⁰Please
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.

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⁰, 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.

⁰Please
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.

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⁰, 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.

⁰Please
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.

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⁰, 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.

⁰Please
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.

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⁰, 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.

⁰Please
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.

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⁰, 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.

⁰Please
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.

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⁰, 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.

⁰Please
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.