[core-workflow] Questions about the proposed workflows

[Nick Coghlan]

On 12 December 2015 at 23:39, Donald Stufft <donald at stufft.io> wrote:
> It seems pretty hypocritical to be against GitHub because it's proprietary and hosted by a company that can sell your data (both things I've seen people say against GitHub) and be pro GitLab EE (either hosted by Gitlab or ourselves) or pro using a Hosted Gitlab. I don't personally have a problem with it, I'm fine with the tooling not being free but it seems disingenuous to treat Gitlab EE (as opposed CE) as if it's free software. I'm particularly interested in a managed option of some kind to reduce to load on the infra team.

Yeah, that's why I suggested there'd need to be at least four options
in a useful survey question (if Brett decides a survey is worth doing
at all), since those would help tease out what folks are actually
worried about, similar to the way that presenting a vegetarian option
for a meal may still not be sufficient for vegans.

Running through them:

a. GitLab EE instance hosted and managed by GitLab, Inc

* Being happier with this option than with the use of GitHub would
indicate someone was bothered by GitHub specifically, rather than the
use of proprietary software. Given the tech industry's propensity for
flocking to proprietary vendors who then turn around to attempt to
extract monopoly rents (cf. IBM, legacy UNIX vendors, Microsoft,
Oracle, etc), this is certainly one of the factors in my own concerns
- Silicon Valley venture capitalists are deliberately running a
"ubiquity first, revenue later" strategy for GitHub, which means it's
important to plan for an exit strategy if the flow of free money (and
the associated free services) dries up when investors start getting
impatient for their returns. While I've personally come to the
conclusion that
"Migrate-to-GitLab-or-some-other-service-if-the-need-arises"
adequately addresses such concerns (along with the general market
forces of GitHub doing battle with incumbents like Microsoft's Team
Foundation Server and Atlassian's software lifecycle management
portfolio), it may be that not everyone feels the same way.

b. GitLab EE instance hosted by the PSF, and managed by GitLab, Inc

* This gets into cases where folks are mainly concerned about having
permanent copies of everything important from GitHub always ready to
go on PSF controlled infrastructure, even if we're not using it
actively. It's essentially the "GitLab-as-GitHub-exit-strategy"
approach, with an additional hedge where PSF admins have direct
control over the data, even if GitLab have been tasked with the
day-to-day operation of the service.

c. GitLab EE instance hosted and managed by the PSF

* Similar to the previous option, this option would likely indicate
that someone is more concerned by privacy and data control issues than
they are by the use of proprietary software. Both GitLab and GitHub
are private for profit entities, answerable to their investors moreso
than to their users, so monetisation of user data, including becoming
a data broker for information on user's online activities, is well
within the prospective scope of corporate activities (even if neither
company is pursuing such activities today). By contrast, the PSF is a
non-profit entity, answerable to its members. If the PSF controls the
identity information needed to participate in the core development
process, then we can categorically assure participants that we're not
selling their information to data brokers, whereas if we use third
party services, we'll have to both tell people to check the Terms &
Conditions for those services, as well as consider defining trigger
conditions for what we consider to be unacceptable barriers to entry
for participation in the core development process.

d. GitLab CE instance hosted and managed by the PSF

* This is the only option that gets all the way to "Free software
needs free tools" - it denies even GitLab's open core development
model as a legitimate revenue raising tactic, since it's still using
the proprietary model to exercise coercive control over customers. The
main advantage GitLab EE has over GitHub in that context is that the
exit strategy from EE to CE is even simpler than that from GitHub to
GitLab EE.

I honestly don't know how the different areas of concern break down
across the core contributor base, and I've seen enough demands for
free software and privacy advocates to "stop being unreasonable" in
various contexts to suspect that an anonymous survey (that is still
somehow restricted to core developers) would be the only way to get an
even halfway accurate assessment.

Cheers,
Nick.

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