1. 10
  1. 6

    But to me, the development process is more important than worrying whether a cloud-based service publishes its source code.

    The culmination of the open source/MIT movement - “gratis and easy beats libre and ethical.”. I could say more, but I leave these links for reading, as they say it better than I do:


    http://thebaffler.com/salvos/the-meme-hustler (note: while this is gratuitously a fairly nasty dig at a single person, examine the cultural analysis along the way)

    1. 2

      I agree with the GNU project about the fundamental vapidity of the “open source movement”, and I love The Baffler, but I think that setting “easy and (x)” in opposition to anything other than “difficult and (x)” is missing the point of the purely utilitarian open source idea. It’s not that anybody who chooses Github does so out of some deep seated dislike for GNU licensing terms; it’s chosen because it’s easy, full stop.

      ETA: formatting, because _ means something in Markdown

      1. 1

        That’s fair: github is easy. I agree. I have an account there. But I raise this idea: that there is a deep seated thing around the idea of open source projects. A project means something by its license terms and how it comports itself. Python has specific values, and is a flagship project of the F/LOSS community. Where it goes and who it interacts with represents a selection of a set of a multidimensional choice axes. One of those relates to the signaling around “What is the ethical choice? I’ll follow the lead of this major project. They have thought in depth about this and I believe I can trust them”.

        And this is where Python has ceded their leadership of libre software in this area; they have chosen gratis network effects (and, let’s be honest, easy). I will argue that principles to die on a hill on, demand choosing the difficult option if it is the option that aligns with their principles.

        Anyway. I’m super sad about this. I think hg is a better system (for a variety of reasons), and I think the ethics of libre software demand not relying on closed-source systems.

        1. 3

          I have no particular dog in the python fight; I just think that overthinking the reasons that people do things often leads to overcomplicated arguments. I too wish that projects were more thoughtful and deliberate about how they choose to work. I too wish that there were some more serious discussion about the actual ethics of tools. I have considerably more sympathy for the FSF’s deontological arguments than the utilitarian ones of the open source crowd; but of course I use a Macintosh.

      2. 1

        I’ve put The Meme Hustler in my reading list; take the rest of this comment without considering it :-)

        If Python was using Github as nothing more than a gratis server that communicated a secret binary protocol (a la bitkeeper) I’d understand. But GH seems like nothing more than a glorified UI to git, right?

        My acid test for this kind of thing is “could a developer using nothing but FSF-approved tools interoperate with trivial to limited difficulty”. it’s a rather extreme position; I don’t personally care about FSF definitions but they at least keep us honest.

        Under that test Github never bothered me… there’s nothing to keep a developer from running git request-pull and emailing python-dev@ (or whatever) so where’s the harm?

        1. 2

          “could a developer using nothing but FSF-approved tools interoperate with trivial to limited difficulty”

          Assuming you ignore the Github website (which is arguable either way, but which I’m taking as axiomatic for my point here), no, they could not. Github’s issue tracker and pull requests are entirely closed-source and opaque to outside tools. The repository itself can, of course, easily be manipulated using the free-software git tools, and that is certainly the majority of the service Github offers; but it is not the entirety, and may not even be the major value proposition. (After all, git hosting is easy and cheap. Setting up a good, integrated issue tracker is somewhat less so.)

          1. 2

            I think PRs are potentially just fine - I guess it all depends on the maintainers' willingness to work outside GH to take contributions outside GH. Gray area at least.

            But you’re absolutely right about issues, and I don’t have a good answer as to why I didn’t consider them.

            1. 1

              “could a developer using nothing but FSF-approved tools interoperate with trivial to limited difficulty”

              could such a developer buy a train ticket with nothing but FSF-approved tools? As far as I know Python is not in line with the FSF on many layers, so why would it start judging its tools by those guidelines while developing BSD-style project (being compatible with the GPL).

        2. 3

          This is a really thoughtful and interesting report on the reasoning behind the decision to move to Github. I must say that two points particularly stick out:

          • the experience that self-hosted solutions are hard to maintain.
          • the focus on paving the way for contributions and review.

          If you are one of those who are oppose to a migration to Github and you are not a Python committer / contributor, please give the Python folks some rest. These people are spending their time on an open source project, it is their choice. Since they will use git, the source will be fairly solidly distributed, if Github turns evil, they may leave again, just as they left svn and will leave mercurial.

          It is easy to ask too much from open source or free software volunteers. The community often asks them to put in their valuable time for the project and be welcoming to contributions and deliver workable software and to ahere to philosophy X. You cannot have all of it.

          Stories with similar links:

          1. The history behind the decision to move Python to GitHub via av 5 years ago | 9 points | no comments