1. 40
  1.  

  2. 30

    It makes a lot of sense. So much sense that we should ask why it hasn’t happened in the last 20 years. Why do we have a drumbeat of stories where closed commercial tools displace open ones? I think there are two structural reasons: money and federation.

    Charging money for things means it can be someone’s day job to replace mailing lists with GitHub, and to constantly expand and improve on the breadth and quality of that software. GNU Mailman was the de-facto standard almost as fast as it was released in ‘99, but it was maintained by a couple grad students who got busy with studies or graduates, so it stopped getting substantial features after ~2005.

    And second, federation makes improvement hard and often creates a crab bucket mentality. IRC’s almost 28 years old and the only feature I can remember being added is channel services, a “chatbot” hack. I look at Slack’s features like group file sharing, impromptu private groups, mobile notifications - heck, I can’t think of a feature IRC couldn’t have added 20 years ago, but implementing it would mean getting dozens of server and client implementations to all collaborate. Instead I’ve seen steps towards these things brushed off as unsupportable, non-standard client hacks.

    I think it’s a waste of time to worry about who’s “committed to free software”. Fix the structural inequalities so GNU-licensed software can compete effectively and you’ll earn huge adoption.

    1. 10

      Yes this. Exactly. Open source is something that motivates, empowers and captivates pretty much everyone who loves what they do in this industry, but at the end of the day, we’ve all got to put food on the table and keep ourselves fed and watered.

      This issue - how to fund the open source ecosystem - is something the Python community is grappling with right now. Commercial support is fantastic, but as the fates of companies change, so does their willingness to belly up to the bar and put their money where their mouth is.

      Witness HP’s recent layoffs and in particular the Python Packaging project’s maintainer Donald Stufft.

      We all need to put our heads together and come to some constructive solutions to these problems, but IMO ivory tower statements like this aren’t entirely helpful.

      1. 1

        Create a centralized service to pay for upstream attention and relevant news, ideally via subscription. We would register - I need some help with samba and kea…

        Next, make it tax deductible. ;-)

      2. 7

        I think the argument “Free Software needs free tools” is great, but until there is a decentralized git host, ala ipfs or some other means I really don’t see anyone moving away from github. Moving to another “open source” service just has the exact same risk of the host, deciding actually they don’t want to continue being open source and we’re just trading kings. The solution isn’t to discourage one host over another but to collaborate on developing a democratized hosting solution for VCS.

        1. 4

          Moving to another “open source” service just has the exact same risk of the host, deciding actually they don’t want to continue being open source and we’re just trading kings.

          Maybe, but moving from “there is only one source host that matters” to a situation that’s no longer an effective monopoly is a worthwhile goal too.

          1. 4

            The decentralized git host is called your computer

            1. 5

              Except it really isn’t. When my computer goes down there is no mechanism for me to pull the repository from peers apart from say, emailing them. This is a frankly stupid solution that is and has always been insufficient. Also not everyone has a static ip.

              1. 1

                Complaints about stability apply just as much to GitHub. And when it comes to email, I don’t think it’s fair to say it’s stupid or insufficient. Plenty of projects work today with git and mailing lists alone, and they work more effectively in the face of GitHub going down, errant DMCA notices, etc.

                1. 14

                  No, stability concerns don’t apply “just as much” to both. GitHub has a distributed system with a staff of dozens paid to wear a pager. My laptop goes to sleep when I close it.

                  1. 5

                    How many times does Github, servers or network, go down compared to a hobbyist’s personal server or Internet connection? I’d imagine Github’s situation is much better.

                    I dont have to imagine as I’ve collected countless papers plus many software from such sources. It was often hard because the sources die off, get paywalled, links broken, machines on intermittently, etc. I click a Github link and get the docs + source almost every time. I cant even remember the one time or so it didn’t since it was so rare.

                    Open-source, free tooling or services that’s competing with Github must provide that with similar usability but without any of its proprietary risks. That’s the way to get similar results. How is still open for discussion but people are using Github for valid benefits that decentralized, FOSS tooling wasnt matching up to.

                    1. 3

                      Yeah except they don’t. They don’t work more effectively or we’d be using them. You aren’t examining the full scope of the problem.

                      1. 2

                        That depends on your definition of effectively. The Linux Kernel chugs along under that model. As do many other large, entrenched open source projects (GNOME specifically comes to mind).

                  2. 2

                    Serious decentralization requires the dismantling/defeat of pervasive NAT to be effective.

                    1. 2

                      Do you mean initiatives like gittorrent or gitchain? They seem stalled.

                  3. 5

                    I fully agree with the post, and would even say further that open source developers should only use open source tools, period (yes, I know that’s not likely to happen). If the open source community doesn’t feel the pain of working with a tool that needs to be improved then it’s less likely that someone will improve that tool. Switching to commercial software because it works better hurts everybody. Living with a mediocre tool and getting annoyed enough with it to fix it is where open source shines. We’re not all able to fix the tools we work with, but many of us are able to make a financial contribution to a project, or submit a useful bug report to a project, etc. Yes, this may be more painful in the short term, but over time it pays off.

                    1. 4

                      There is one problem I see free/decentralized hosting of git repositories: Server costs. Most git hosting tools recommend $20/month servers or higher to perform well. It may not matter as much for smaller code bases, but it’s still an issue to be contended with overall. The beauty of DVCS is that you don’t always need the remote to work, outside of CI workflows, so migrating hosts is doable, although a lot of the stuff around the repo, like issues and wikis don’t often transfer.

                      In terms of being a small, scrappy tool for some of this, I’ve been appreciating fossil a lot. It has it’s own faults, but I like that hosting it on a server vs my own machine has little to no difference in how it works. (It also currently fits as an extra thing onto my VPS, and stays zippy despite this. It doesn’t have as much functionality as git, but everything is a tradeoff)

                      1. 6

                        $20/month is far too much. You can get $5 VPSes that would make perfectly fine git hosts and maybe even do your builds.

                        1. 7

                          I suppose my expectations may be miscalibrated. I’ve been thinking of tools like gogs and gitlab that provide a few things on top of just hosting git.

                        2. 1

                          Most git hosting tools recommend $20/month servers or higher to perform well

                          This is partly why I advocate for using more performant languages and platforms. Gitlab, for example, is really held back in this space by being a Ruby on Rails app, requiring an unreasonably beefy machine for the functionality provided.

                          If we write these systems with an eye to performance, we can host them on tiny $5 boxes, or host loads of services on one larger box. Until that happens, self-hosting these services won’t be very appealing.

                          1. 2

                            yes, I think there is some value in improving projects like cgit, from an aesthetics and usability perspective. Even if we have to hire some designers to do so.