[core-workflow] Software Factory

[Nick Coghlan]

On 31 December 2015 at 10:00, Stefan Krah <skrah.temporarily at gmail.com> wrote:
>
> M.-A. Lemburg <mal at ...> writes:
>> On 30.12.2015 20:03, Stefan Krah wrote:
>> > I don't care if they have been profitable by selling private repos on a
>> > small/medium scale, the direction they're heading in is quite clear:
>> >
>> > Get people (esp. young ones) to work for free on OSS projects using
>> > gamification, cute icons, "social" coding, and a fake hero-of-work ethos
>> > fueled by "longest streak" statistics.  When these people are ready to enter
>> > the job market, they can <euphemism>be brought in contact with</euphemism>
>> > employers.
>>
>> FWIW: This business model is already being used by other companies
>> scraping Github repos, analyzing checkins and then matching what
>> they find against recruitment offers (basically automated head
>> hunting).
>>
>> The same could be done with any other DVCS repo system, but Github
>> is currently the most popular one out there. Ohloh, now renamed to
>> Open Hub, has been doing such analysis for quite a while (with
>> a different focus, though):
>>
>> https://www.openhub.net/p/python/contributors
>>
>> That's simply a consequence of having repos out in the open
>> and not really specific to Github.
>
> GitHub takes this to a new limit: When you create an account, you
> are being told (gamification-style) how to get dark green squares
> in your statistics, how to promote yourself using a picture, how
> to use a single account for private and public repos, how to
> keep the single account *even when switching companies*!
>
> If you happen to work for a company that's on GitHub *and*
> contribute to volunteer projects there, they basically have a
> major part of your life on their servers. I don't think
> OpenHub can match that in any way.
>
> I'm not anti-corporate: If Microsoft would make us an offer
> to manage our infrastructure, I'd rather have a Microsoft
> account for Python development that a GitHub account.

I actually share a lot of Stefan's concerns regarding the potential
for exploitation of community volunteers that is involved in GitHub's
business model - being a late-entering competitor in an already
crowded Enterprise VCS market (where version control is just one piece
of the larger Application Lifecycle Management puzzle) doesn't justify
the kind of VC investment that GitHub has been receiving, while
GitHub's potential as the preferred platform for connecting open
source contributors with large organisations adopting and creating
open source software *does* justify that kind of investment. "Going
where the developers are" is certainly the justification I see used to
advocate for even established open source organisations setting up
shop there rather than hosting their own repositories on a more
obviously company or project branded site.

However, it's also important to acknowledge that corporate
exploitation of open source community volunteers is *already
happening* - it's a cultural norm for profitable companies to deploy
and run open source software without allocating even a single hour of
their employees' time to contributing back to the projects they use,
figuring out a way to compensate existing contributors to improve the
sustainability of upstream projects, or paying a non-profit foundation
or commercial redistributor to handle those problems on their behalf
(and even community non-profits and commercial redistributors aren't
as good at handling those tasks on behalf of sponsors, customers and
contributors as we should be).

As such, I've come to the conclusion that the potential for
exploitation of community members isn't a strong argument against
community projects like CPython adopting GitHub for code hosting and
review, as making contributions more readily visible actually has the
potential to *reduce* exploitation by helping contributors to
strengthen their negotiating position in various commercial contexts.

Since I'm also a strong advocate for tackling that problem at the
employer/employee boundary [1] rather than the vendor/customer one,
the case can even be made that GitHub's approach to changing that
dynamic (i.e. baking it in as an inherent feature of the way their
free-as-in-beer software hosting platform works) may prove to be more
effective than asking people to do it voluntarily [2] or leaving it to
foundations and companies to invest in their own data gathering [3,4].

Regards,
Nick.

[1] http://community.redhat.com/blog/2015/02/the-quid-pro-quo-of-open-infrastructure/
[2] https://docs.python.org/devguide/motivations.html
[3] http://stackalytics.com/
[4] https://www.rdoproject.org/stats/browser/

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia