<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 30, 2014, at 11:17, Chris Angelico <<a href="mailto:rosuav@gmail.com" class="">rosuav@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">On Sun, Nov 30, 2014 at 8:54 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" class="">ncoghlan@gmail.com</a>> wrote:<br class=""><blockquote type="cite" class="">On 30 November 2014 at 15:23, Chris Angelico <<a href="mailto:rosuav@gmail.com" class="">rosuav@gmail.com</a>> wrote:<br class=""><blockquote type="cite" class="">Python is already using quite a bit of non-free software in its<br class="">ecosystem. The Windows builds of CPython are made with Microsoft's<br class="">compiler, and the recent discussion about shifting to Cygwin or MinGW<br class="">basically boiled down to "but it ought to be free software", and that<br class="">was considered not a sufficiently strong argument. In each case, the<br class="">decision has impact on other people (using MSVC for the official<br class=""><a href="http://python.org" class="">python.org</a> installers means extension writers need to use MSVC too;<br class="">and using GitHub means that contributors are strongly encouraged,<br class="">possibly required, to use GitHub); so why is it acceptable to use a<br class="">non-free compiler, but not acceptable to use a non-free host?<br class=""></blockquote><br class="">Relying on non-free software to support users of a non-free platform<br class="">is rather different from *requiring* the use of non-free software to<br class="">participate in core Python community design processes.<br class=""></blockquote><br class="">But what non-free software is required to use the community design<br class="">processes? The GitHub client is entirely optional; I don't use it, I<br class="">just use git itself. Using a free client to access a proprietary<br class="">server isn't the same as using non-free software.<br class=""></div></blockquote></div><br class=""><div class="">Also keep in mind that unless you are using a <i class="">very</i> esoteric hardware setup and dedicated leased lines that you purchased yourself, you are likely to be using copyrighted, patented, proprietary software at a number of levels:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">the microcode implementation in your CPU</li><li class="">the firmware in your GPU</li><li class="">the firmware in your network card</li><li class="">the boot code (e.g.: BIOS or EFI implementation) of your motherboard</li><li class="">the firmware in your router</li><li class="">or the firmware in your cable or DSL modem, if you thought to get a free router with OpenWRT or something in it</li><li class="">the firmware in your ISP's router</li><li class="">the firmware in the backbone's routers</li><li class="">the firmware in the PSF's ISP's routers</li></ol><div class=""><br class=""></div></div><div class="">Does this sound like ridiculous nitpicking? Of course it does! If you refused to use all that stuff you just wouldn't be able to access the internet at all, regardless of your personal choices. Most layers of this stack are _less_ constrained to open standards and open data access than Github, and can require layers and layers of additional proprietary software or reverse engineering (ask anyone who has tried to play a video game on a Linux computer what the experience is like without gobs of proprietary blobs from nvidia or ATI).</div><div class=""><br class=""></div><div class="">And as the story of BitKeeper shows, if a proprietary platform decides to do something bad, if the cost of migration is within your means, <i class="">you can just leave</i>. This is far more true of Github than Bitkeeper - Linux had to create a totally new VCS to migrate off of that, we just have to install Trac or Roundup or something again. (Which, as per the presently-proposed PEP, we don't even have to install them again, just change some configuration to put a few repositories back.)</div><div class=""><br class=""></div><div class="">The monoculture about Github concerns me. I also have concerns about the long-term consequences of not having an all-free-software stack. But focusing on avoiding services like Github at this point in history is just a gigantic waste of time; it's resolving dependencies in the wrong order.</div><div class=""><br class=""></div><div class="">The only reason to avoid Github is ideological purity, and even then it's not even "purity" because you still have to accept this other ideological contamination. Except, what about other ideological concepts that are important to the Python core developers, like equitable representation for women and minorities, and compassionate and polite interactions within the community? Clearly we can't require the use of Linux. If we treat these ideals as an equivalent priority as free software (even if we ignore the "invisible" dependencies like the list I just made above), then there is literally no software left that we can use to develop Python. Linux kernel and GNU low-level user-land development are a perpetual cesspit, and their leaders serve as a continuous embarrassment to our community.</div><div class=""><br class=""></div><div class="">And speaking of equitable representation, one proven technique we have learned for dealing with that problem is making it for newcomers of all stripes to access the community. Like it or not, Github's popularity means that it's a place where <i class="">most</i> newcomers to programming are learning to use version control and bug tracking. This is a network effect that can have a real impact on people's lives. Requiring newcomers to learn our weird technology religion before they can contribute creates a real barrier to entry, which in turn makes our community more insular and homogenous.</div><div class=""><br class=""></div><div class="">Some days you get the Git, and some days the Github gets you. The sooner we, as a community and a culture, can accept this and move on, the more time will be available to actually build replacements for these things.</div><div class=""><br class=""></div><div class="">-glyph</div><div class=""><br class=""></div></body></html>