[python-committers] Would anyone STOP contributing to Python if we used GitHub?

[Nick Coghlan]

On 16 December 2015 at 08:00, Barry Warsaw <barry at python.org> wrote:
> On Dec 15, 2015, at 10:51 PM, Jesus Cea wrote:
>
>>I realize that my weight as a very low activity committer is minimal and
>>I don't have an alternative proposal.
>
> An alternative which meets many of your criteria is the GitLab proposal in PEP
> 507.

(TL;DR of below: my own main concern has shifted to ensuring that,
even if we choose GitHub now, we can still add GitLab, Kallithea or
Phrabricator in parallel later, without disrupting the folks that
genuinely prefer GitHub based workflows)

For me personally, regardless of what happens in the near term, I
still want to see us eventually offer a free-software-needs-free-tools
friendly contribution path running on a project like GitLab CE,
Kallithea or Phabricator.

However, I'm also satisfied that, regardless of what we do on the free
software side of things, we want to offer a GitHub based contribution
path for folks familiar with that workflow (I now see this as similar
to the fact we actively work to support both Windows and Mac OS X as
user and contributor platforms, even though they're proprietary
operating systems).

Having accepted that my own long term goal is to minimise barriers to
contribution both for folks accustomed to using popular proprietary
platforms *and* for folks that aim to use exclusively free software,
I've come around to the view that a compromise "open enough" solution
that leaves *nobody* especially happy with the outcome likely isn't a
good approach, and hence it's better to pursue a "parallel
contribution path" model where we create two *interoperable*
workflows, rather than a single *compromise* workflow.

Splitting the two workflows that way means the folks that "just want
something that works" can benefit from the use of a commercial
freemium service, while folks that genuinely prefer to use free and
open source tools are also generally willing to be a bit more
forgiving of any deficiencies relative to better funded alternatives.

That means my core requirements for the near term solution have
changed markedly from those I documented in my withdrawn workflow
PEPs: I now merely want to ensure we don't lock ourselves *out* of
adding a parallel free-software-needs-free-tools contribution path
later. The GitHub-with-a-merge-bot refinement currently being
discussed on the core-workflow list clearly meets that criterion
(since a merge bot can be updated to accept submissions from multiple
sources), and the GitLab EE proposal in PEP 507 arguably does as well
(the features we want from GitLab EE that aren't in GitLab CE are
relatively minimal, and hence readily implemented on top of CE as an
external script if desired).

Cheers,
Nick.

P.S. As an analogy I've been working on, consider how folks typically
approach creating a welcoming environment for vegetarians & vegans at
a community event. Do they:

1) serve exclusively vegetarian & vegan dishes?; or
2) provide enjoyable vegetarian & vegan dishes, clearly marked as
such, while also providing non-vegetarian options?

The latter approach is by far the most common one, as the former risks
vocal complaints about the lack of meat dishes from non-vegetarians at
the event if your event isn't specifically about vegetarianism and
veganism. The equivalent we see in open source workflow design is
folks resenting being "forced" to use open source and free software
solutions that they consider inferior (or at least unfamiliar) in
order to participate, rather than being given a free choice between
them and their more familiar proprietary competitors.

By the same taken, nobody would consider a community event that
refused to cater to special dietary needs to be a particularly
welcoming event, which is why I consider it important to offer a
free-software-needs-free-tools friendly approach to contribution.

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