1. 30
  1. 7

    We already have various tools for enabling growth: the freedom to use the software for any purpose being one of the most powerful.

    This has been tried for the last 30 years; with very limited success, and the success it did have is probably not primarily attributable to “Software Freedom” either.

    Essentially this article is “keep doing what we’ve been doing for the last 30 years”, which doesn’t strike me as a very good strategy.

    1. 6

      with very limited success

      Hobbyist software hasn’t exactly displaced end-user software, but the major browsers are (corporate) open-source and pretty much all developer tooling and infrastructure is. I’d say open source has been very successful!

      1. 7

        Hobbyist software hasn’t exactly displaced end-user software, but the major browsers are (corporate) open-source and pretty much all developer tooling and infrastructure is. I’d say open source has been very successful!

        Ok but how much browser hacking have you done? How many times have you opened up Blender’s source code – or Chromium’s – and gone “ok I can make a change to this within a reasonable timeframe to make it do what I want”.

        Free as in freedom doesn’t mean shit when codebases are so large as to be inscrutable and induplicable.

        1. 10

          Something as complex as a modern web browser is going to have complex source code. There’s no way around that, and it has nothing to do with being open source or not.

          1. 4

            Sometimes those codebases are large because they actually do something useful.

            I will say I’ve gone in on complex projects before (usually language runtimes) when needed/desired and been able to figure out changes. Usually, I don’t because I have no need.

            1. 2

              On one hand, there are two hobbyist forks of Chromium that I use: Ungoogled Chromium (for desktop) and Bromite (for Android). These are both Chromium with no google services. That these projects are possible is a success of open source.

              On the other hand, In order to have an ecosystem that fully embodies the spirit and values of free software, we need to embrace the OP’s recommendation, and go well beyond that. Software needs to be much simpler. Languages need to be much simpler. Hypercomplex mega-apps need to be replaced by an ecology of small tools that interoperate on a shared data model. (We had that in the Unix CLI, but then we threw that away when we permitted Apple and Microsoft to define how a GUI works.) Operating systems need to allow you to trivially examine and modify any code that you happen to be running, much more like Smalltalk or a Lisp machine, and much less like the C + Unix model that the community adopted back in the 1980’s.

            2. 3

              Hobbyist software hasn’t exactly displaced end-user software

              Linux was originally a hobby OS, so, at least “software that started as hobbyist” did displace end-user everywhere on internet servers.

              1. 2

                It’s been very successful at developer tooling. Which makes sense, since the whole ‘you can modify and change it as you please’ ethic lends itself naturally towards developers who can make those changes. It’s failed pretty hard at end-user software, with browsers being one of the only exceptions I can think of.

                1. 2

                  I guess one thing is that end-users often are unaware things might be changeable. Many still view computing as a black box that only the “gifted” can bend to their will. Everyone has a “handy cousin” who can fix their printer, but not everyone has a handy cousin who can change the program for them to do as they will.

                  And besides, if someone would ask me to create what is in essence a private fork of a program, I would be very hesitant at doing so: I would have to maintain that until the end of days, and somehow incorporate security updates into it. No, thanks!

                  And paying a company to do the same would get prohibitively expensive for most people, especially if it’s just a small seemingly trivial change like, I dunno, “could you change it so that the menu bar is at the bottom rather than at the top?”

                  Of course the more savvy users would end up making implementation tickets in the ticket trackers of the projects they care about, but I doubt the small free software projects would be able to deal with the large inflow of such “trivial” requests without patches, or even the certainty people would be able to verify the new version does what they want. Dev: “can you compile this most recent version and test it?” User: “what does ‘compile’ mean?”

                2. 1

                  I’d say open source has been very successful!

                  The point of this article is that it’s been successful in a way that hasn’t meaningfully accomplished much in terms of user empowerment. Open source gave us the browser ecosystem which has been a very powerful force for allowing tech companies to deliver new products (which is exactly why open source exists) but it’s succeeded only by redirecting goodwill away from the user-centric free software movement towards the corporate-friendly goals of open source. So we have these incredibly powerful browsers that are borderline impossible for anyone who doesn’t work at Google/Apple/Mozilla to contribute to. We have mobile phones which have impressive computing power and are largely technically open source, but they spy on us and don’t allow us to do much to protect against hostile corporate behavior even on our own devices.

                  By focusing on technologies which are intentionally anti-scale, we may be able to redirect some of that lost momentum from the last couple decades back to technologies which can put the user in control and respect consent and autonomy.

                  1. 1

                    But is this attributable to “software freedom” or something else?

                    How many people use Chrome because it’s Free Software? I’d say very very few.

                3. 4

                  The author is only discussing problems where “scale” means reaching more users and having higher availability. However, there are other sorts of scale which we are having trouble managing.

                  Variable names have been getting longer and source code has gotten bigger. This isn’t just because of a shift in choice of languages, but because we have more disk space, better automation for code generation, and a desire to write more readable code which lasts longer. The amount of space required to compile, link, compress, and even execute code has grown.

                  Multimedia has gotten bigger and richer. We demand that an ever-higher number of pixels be displayed at an ever-faster rate of change, while remaining synchronized to audio output and controller input. We might finally be reaching a plateau in this field, but it’s taken a long time. Multimedia used to be less than a single KiB and packed into still images in tiny boxes, but now it is delivered by the MiB as rich fullscreen video.

                  The number of platforms has not just grown, but exploded with the rise of licensing for processor designs. Writing portable code has only gotten a bit easier with our newer languages, but getting good performance out of so many different chipsets inevitably requires hand-writing specialized intrinsic routines or assembly.

                  1. 7

                    Another thing: Users have much higher expectations of user interfaces than in the past. That’s a good thing, but writing software with good UX is still hard, sometimes in ways that don’t make sense to many coders, or at least that they may not find interesting enough to put volunteer effort into. In my experience, UX work also often requires that someone make and enforce contentious decisions and uphold principles, otherwise endless bikeshedding results.

                  2. 3

                    Amen. I’m writing a composition app targeting ActivityPub but I’m designing it for myself first, then for a few friends if they show interest (and actually use it), and I plan to only support those AP platforms that I actually use. Life’s too short to productize every one of my personal projects.

                    1. 2

                      More users (theoretically) means more people helping out with the project. The author would probably respond that the smaller platforms they’re proposing have a higher proportion of users who would help out. But that’s less sustainable, etc. See also https://www.gwern.net/Holy-wars, which says what I just said better.