I thought I would start seeing red and frothing at the mouth when I read this, but this is actually a pretty reasonable take. I wouldn't say that the takeaway is that open source is just a diversion though - it's just that we should actually think about the fundamental software freedoms when we create a free software project. It's not just about making the source code available and slapping a GPL license on there (though that's important). If one of our goals is to give the users control over the software we develop, we should think about whether our software is actually achieving that goal - i.e. thinking about: have we actually designed this software in a way that makes it easy to modify and customize? Should there be a higher-level layer through which less technically savvy users can still customize this software to some extent? and other questions like this.
It's easy to get caught up in a primitive mode of thinking "FOSS license good, proprietary license bad", but we have to remember that free software licenses are not ends in themselves, but are a just a means to achieving freedom for users. Whether this goal is really achieved is a function not just of the software license but also of the actual design and customizability of the software in question.
> Betteridge's law of headlines is an adage that states: "Any headline that ends in a question mark can be answered by the word no."
Then the clickbait worked on you. If the answer wasn't no, the writer would have made it into a statement, as that's gonna drive even more click through/reads.
I'm sorry if you felt insulted from my comment, that wasn't my intention at all.
From my perspective, it's pretty much a complete "no", because you've contextualized the term "open source" to mean something different to what the reader initially thought of at the time of reading the headline.
Furthermore: a question as the headline will always be a clickbait, as readers will always want to have it answered.
Just to be clear, I'm not saying that this was blogspam. It's something you've clearly thought about before putting it in writing and it's well reasoned.
> When I released Ardour under the GPL, my vision was that by virtue of it being an open source project (technically orthogonal to its status as "free/libre software"), it would be possible, even encouraged, for other developers to participate and get involved in extending its capabilities.
I think a lot of people starting with open source kinda expect that dedicated contributors will start to swarm around the project. In reality, a large majority of projects, even many quite prominent ones, are driven by a very small core, often just the project founder.
I kinda understand why the author thinks this is the value of OSS, but from the POV of a user, I'm not as much interested in extending the long list of open source projects I'm using. I prefer open source, because it gives me some mental safety - if I invest into using this software (time spent learning, importing my data into project's data structure etc.), I like the fact that the project is not automatically going to be a dead end if the project founder stops developing it (for whatever reason) or will start pulling something shady, because there is a latent possibility of forking it, in case something happens and there's a need for it.
I'd compare it to democracy (although it is an imperfect analogy of course). You might think that the freedom to participate in the political scene will motivate many people to do exactly that. But only a small majority of citizens will participate in it. Yet even the non-participating citizens are glad that the leaders won't be able to pull off something crazy without citizens having any say in that.
There's a fair few FOSS projects that have a bus factor of 1 or 2, it's one of the things I check these days before considering adoption.
That said, having multiple core contributors isn't always a guarantee either if they're from the same company, that's another bus factor of 1, especially if the company's core business isn't selling software to others, they'll usually end up neglected or abandoned.
Great examples are Robinhood's Faust library, and Shopify's stewardship (or lack thereof) of Sarama. Not their core business, so eventually, the devs get moved on to stuff that makes money directly.
Maybe I phrased it the wrong way. What attracts me to open source isn't a higher number of contributors / bus factor, but the fact that if the project dies for whatever reason, I, and perhaps some other desperate users, can fork it, port it to newer platforms, fix the gravest bugs etc. If worse comes to worst, I'm not completely locked out. Meanwhile with closed source software, I'm completely realint on the software producer.
For me the value isn't the maintainer but the ability to not get locked out. At my work we deal with older files a LOT. We have a bunch of vms running scary old versions of stuff because they're out of date and insecure. At least with open source we could patch or maintain them.
> I think a lot of people starting with open source kinda expect that dedicated contributors will start to swarm around the project. In reality, a large majority of projects, even many quite prominent ones, are driven by a very small core, often just the project founder.
Open Source on its own doesn't mean the average user can make choices with a reasonable effort.
A big thing for me in any desktop environment is, can I (1) have the focused window stand out from others - for example a colored title bar, and (2) choose my own accent color? There was a time when this was no problem - Windows 3.1 could do it, so could Windows 95, and pretty much any linux distro before "the one theme to bind them all". There was a setting for this in a dialog box in most cases, but even if you wanted to experiment with some new theme, since it was all bitmaps and palettes the worst you'd have to do is edit a config file and change GTK_COLOR once or so.
Nowadays, the closest I can get on the "modern" branches of things is regexp-replacing hundreds of lines of CSS, unless I want to build the themes part from source and spin up a whole dev environment to do it. Open Source doesn't help one bit - the difference for me is between 1 minute changing a setting in a dialog box, or half a day trying to understand how the system works because what I want to do clearly wasn't intended.
Or consider chromium. It's open source, right? So I could in theory fix the problem that manifest v3 will no longer play nice with the full ublock origin myself? Yeah, right. What makes it so easy on v2 is not that chromium is open source, but that it offers a plugin interface and API so that people like gorhill can write extensions like ublock, and people like me can just click and install them. The only code I then have to write is then things like `##.featured-video`.
The advantage of Linux (and the BSDs) over Windows there is that if one DE does not let you do something another will. For example I am pretty sure XFCE will let you do configure focused windows, and KDE will provided the theme follows the colours.
Yeah, I run mint/xfce on my linux (virtual) machine. But it doesn't always work perfectly with GUI applications that don't believe in, or don't care about, anyone who's not on the "shiny new thing" branch. Like, you can run both GNOME2 and GNOME3 applications in the same desktop and the title bars are usually fine (that's the wm after all) but the controls might not look the same.
There is a GREAT quote in the comments here. Speaking as someone who's often done their own source and car maintenance because could not afford to go anywhere else. On that note - open source is EXPENSIVE, because it depends on developers having enough of a source of income of freedom, money and time to be able to commit to projects. (I have not had all three in decades)
```Car owners may not want to do auto maintenance / repair themselves, but they have a strong expectation that they can take their vehicles to any variety of techs who can do so for them, without being beholden to the auto manufacturer for whatever support they deign to provide. Buying proprietary software without the right to repair it (including the right to rebuild from the source code) is like buying a car with the hood welded shut (or better, locked down with a key that belongs only to the manufacturer).
There are car owners who never take their car to anybody but the “factory authorized” dealer for maintenance and repair, but they are far from a majority, AFAIK.```
The problem with this analogy is that it presupposes that there actually are "repair shops" somewhere that could do whatever you need done.
For a DAW, that just turns out not to be very realistic. It's bit like owning some highly exotic, super-sophisticated vehicle without the hood welded shut: sure, in theory anyone could modify it/fix it for you, but in reality only the folks that made it understand it well enough to do so.
"The vast majority of real, ordinary users don't really care."
Because they do not understand it and nerds usually suck at communicating with normal people. The result is known: little to no funding and support from the normal world.
In those cases, where it was possible to establish a relationship with the users - the projects worked out and do have funding. Like blender did.
> Because they do not understand it and nerds suck at communicating with normal people. The result is known: little to no funding and support from the normal world.
Agree. Asking a non-techie user about interest in open source won't go anywhere.
But if you frame it in terms like: Do you want your favorite app to lock you in so you can't use any competing apps and then ratchet up the price sky high? Do you want your favorite features removed without recourse? Do you want the company to suddenly discontinue your favorite app and lock you out of using it (and lock you out of your data which you created with it)?
In my experience most regular people first react with "Oh they wouldn't do that", and then after experiencing commercial software for a decade or so eventually realize they all eventually do that.
From there, one can open a discussion to the solution which is open source.
> Do you want your favorite app to lock you in so you can't use any competing apps and then ratchet up the price sky high?
Yes, I want that. Because what I pay for software is so much less than what I make from using that software. Photoshop is not expensive, because the people and organisations who buy it make back that money in two weeks.
Of course I will pay a high price for my favourite app, because I would loose ten times more money by wasting time with open source software that never works properly for the end user and doesn't have any support – unless you are also a developer.
When you buy a car you are usually "locked in" to using the propellant the manufacturer has settled on. Or you can waste almost no money, byt years of your life building a custom car from scrap metal, with a motor that takes any fuel.
But unless you love building cars or love building software, you will want to go for the better, commercial option.
> > Do you want your favorite app to lock you in so you can't use any competing apps and then ratchet up the price sky high?
> Yes, I want that.
I don't quite believe you want that. You'll be willing to pay any amount of money for photoshop no matter how high?
> When you buy a car you are usually "locked in" to using the propellant the manufacturer has settled on.
This analogy shows the opposite. I can buy gas for my car from any number of places, all of them unrelated to he manufacturer.
In fact, the manufacturer can discontinue the car model or can even go out of business entirely and yet I can still continue to buy gas from third parties and continue to use my car.
How do you plan to continue using photoshop of adobe discontinues it? You can't.
> How do you plan to continue using photoshop of adobe discontinues it? You can't.
Double click the app and start it?
Now if you're referring to cloud locks and garbage like that, well that's a risk you take if you decide you're going to use that, just like every single project on github takes the risk that Microsoft doesn't discontinue it. Or every single business that relied on CentOS was taking the risk that RedHat wouldn't discontinue it.
I feel like that's a risk for all software, OSS or not. If the OSS maintainers stop updating your software, it probably stops running on the latest version of your OS at some point. Apple or Microsoft may accelerate that process (Apple almost certainly, Microsoft less so as they're famously very concerned about backwards compatibility).
Obviously there's some software that probably could keep running without updates almost forever, but even for simple things if you're dynamically linked against 32 bit libraries is going to have a hard time on 64 bit OSes if the 32 bit versions of that library aren't available. OSes may add or remove functionality your app relied upon. Heck as long as we're imagining a world where Adobe has decided to stop making photoshop, we could also imagine a world where IPv4 is finally deprecated and removed. How many applications out there assume an IP address is and will always be 4 octets?
Can you give me one example of software that is too expensive for its users? The higher priced software that exists is almost always professional tools, that the user makes money by using.
Open source has many times proved that it doesn't prevent stupid changes in for example UI. Looking at Firefox and them making my most loved features of closing tabs multiple times more effort to do... Because some users can't not hit some menu item...
And I guess this is cycle that has already repeated many times.
>In my experience most regular people first react with "Oh they wouldn't do that", and then after experiencing commercial software for a decade or so eventually realize they all eventually do that.
>From there, one can open a discussion to the solution which is open source.
As long as you keep them away from the apocalyptic discussions about systemd, or pulseaudio, or gnome3 vs gnome 2, or snapd or any of the many other "project has gone in a direction that some people feel very strongly about" kerfluffles that have littered the open source world and lead to many a fork. Or for something bigger than a kerfluffle, you could look at basically anything going on with RedHat / CentOS / Fedora in the past few years. Yes, in theory what happens here is that group B forks from group A and people who preferred A are happy and people who preferred B are also happy. In reality, users suddenly find themselves in the middle of deciding which camp they want to be a part of (especially if the split was over some item they don't care about, like systemd). And if they're really lucky, they'll pick a side that gets continued, ongoing development. If they're not, they pick a side that either gets abandoned by the forkers after their fury cools and the realities of managing the fork set it, or worse they wind up as a small-also-ran, slowly but surely deviating more and more from the "mainline" from which they forked and losing out on all the ancillary benefits that come from being the community de-facto standard/target.
That isn't to say that open source can't have a better degree of protection than proprietary software does. Just that open source by itself is no guarantee, and you might find yourself having to switch software and learn whole new systems just as much as you would if you were using closed source software.
For the absolute vast majority of users who are not developers, open source doesn't mean anything to them because they don't have the knowledge, or the money to deal with the open source software they use making the same arbitrary decisions any other software package might make. Yes, you could take all the source from the last release of CentOS and hire a bunch of developers to keep it going for you... you could also in theory buy all the shares of Microsoft and force them to make windows the way you want it too. The fact that the former is more in the realm of possibility than the latter doesn't make either of them a good plan.
Heck even for developers - if vim decided to start shipping everything you wrote to sketchy AI servers, if Ubuntu decided that all windows will only have maximize buttons and be unclosable without a restart, or if VLC decided to inject ads infront of every locally played video - I may not have the knowledge or skill set to find that and rip it out. Or maybe I just don't have the time because my bills don't get paid by correcting open source projects doing things I find stupid. I can hope other people will do that, but again, now I'm at the mercy of hoping the team of dissatisfied people maintain a fork forever, just like any other uses.
I think that sentence summarizes all your other points.
Of course it's not a guarantee.
One thing that is a guaranteed outcome is that when you rely on proprietary software, you will have zero options when the company that made it goes in a direction you hate. You can't fork it, you can't maintain it, you can't restore the functionality, you can't pay others to fix it; you are guaranteed to be stuck.
Open source keeps your options open. Does not mean it will be necessarily free or effortless, but you'll have options.
> Open source keeps your options open. Does not mean it will be necessarily free or effortless, but you'll have options.
You still have to be able to exercise those options. If you can't, you might as well not have them at all for all the good it will do you, and in the mean time you still have to deal with the fact that your stuff doesn't work now.
Also for what it's worth, you said you frame the argument in the form of:
OSS Advocate: "Do you want your software to change grind puppies into baby food?"
User: "They wouldn't do that"
<Spoiler: They do>
User: <shocked pikachu>
OSS Advocate: "Have you heard the good news about our Lord and Savior RMS?"
But, just because you have options to mitigate the end result doesn't mean that OSS software also won't change to the "grind puppies into baby food" model. That's what the user cares about and OSS does nothing to address that because OSS on its own isn't concerned at all with the the features of the software, just how the software is distributed.
Edit:
And having finally read the linked article in full, I feel like the author is talking about a similar thing. The option to recompile from source to implement the features you want is useless to the user if the user doesn't have the ability or time. And it makes the software less valuable to the user relative to a proprietary version that does have options that they can exercise. Open source is and always has been a developer facing feature in reality and it just so happens that some times (and especially early on) developers were also users. But most users aren't developers anymore and even developers aren't necessarily developers with the skill sets necessary to modify your application anymore. If the goal is to give the USER the freedom to modify the software, then open source on its own might not be enough, or even sufficiently better than the offerings from closed source vendors.
Well, it might start by not tarring other people as "normal" or "ordinary" and separating off "the normal world".
Consider that everybody has a unique life and story, and that each of us are normal (in a statistical sense) in some metrics, and an outlier in others.
The whole "nerd vs normie" thing is just toxic from the word go.
But when it comes to computer use and knowledge, there is a divide between techies and just about everyone else. It's not just about lack of knowledge but also lack of fucks to give. Techies just love to build and configure things to their liking. The rest of us have things to do, and would just rather buy the functionality they need in a ready-to-go and easy-to-use form. This is why when computers meet creative work, except maybe for programming, the best-of-breed professional tools are all proprietary. Nobody in those lines of work gives a shit about source availability. They will endure dark patterns techies find intolerable, just to have that functionality. Hello Adobe subscription model. It's not hard to find a Hackernews who will say "I'd rather pay that $23/month for Photoshop than have to endure GIMP."
Speaking of, the above goes for technical professionals too: sooner or later, many of them will put their college kid tinkering hobbies aside and just buy a Mac, freeing up time they would have spent tinkering with a Linux distro to cook dinner for their spouse or play with their kids.
I used to be like you and believed it was senseless and harmful to believe there was a divide between users and programmers. I was smoking that "any user could become a programmer" copium in my 20s. But there is a divide and it's a wide, wide gulf. One of the things that got me to put the programmer hopium/copium pipe down was getting married. She's very smart, but she buys 100% Apple kit and doesn't have to worry about maintaining or configuring anything after initial purchase.
> Techies just love to build and configure things to their liking.
I don't, and I don't believe I'm even in the minority in that regard. What you are referencing is a stereotype that may reflect a minority of so called "techies", but even those are almost certainly only interested in building and configuring things within some specific field of interest, but still want everything outside of that to "just work".
> The rest of us have things to do, and would just rather buy the functionality they need in a ready-to-go and easy-to-use form.
A false dichotomy that is often repeated, but incorrect nevertheless, for it is the proprietary ecosystem that keeps breaking things over and over again, changing UIs, features, and even very basic settings you've set, dropping support for various things (apps, devices, etc.) you might still use and that still work fine.
My linux installations have made everything work directly out of the box (unlike some properietary systems where you have to install things and fiddle with settings to make things work) and have stayed almost identical in terms of their UI and already-existing features for a decade now (and could have for quite a bit longer if I had adopted linux earlier). No properietary system could come even close to this level of "just works"-ness (though apple probably gets far closer than the others).
In the DAW space, Reaper's success would suggest that the gulf is nowhere nearly as wide as you suggest. This is a supremely "nerdy" DAW, and yet has found great rates of adoption and publicity (partly thanks to its enormously energetic user community).
One of things that is easy to forget if you're not in this world all day every day is that audio engineering was already a pretty nerdy activity before DAWs came along, so the move to computer-based workflows doesn't really change the fundamental psychological qualities of a lot of the process.
Erm, I am fine being considered a freak. But what I am talking about is, that a very high percentage of computer freaks do not go out and talk to people who do not have anything to do with computers. I remember the day I walked into my university and first IT classes and thought, "wow, they actually do live the cliché". I mean, that is fine by me, everyone should live the way they want. But if you want to make an impact beyond your circle of devs, you might want to learn to communicate with people who are happy, that they manage to turn their computer on. Because they are not dumb, they just have other priorities.
> you might want to learn to communicate with people who are happy, that they manage to turn their computer on. Because they are not dumb, they just have other priorities.
Easier said than done. I think many, including myself, would argue that there's more than enough time and energy for it all. People who "have priorities" are simply not curious enough and often stubborn. That's a whole different topic, but definitely worth thinking about.
Your typical "nerd" can balance a diverse set of interests well enough. That's precisely why they're not considered "dumb".
UI/UX is costly. It's not enough to be "good at design", but that a mature API is a prerequisite for frontends that aren't a mess. Most projects never get to that point.
If you really want to make the dichotomy, "nerds" are excellent at communicating if only they didn't have so much to say to so few people. It's really that the "normies" aren't interested. You get them interested by having said so much to so many that something eventually got their attention. You must leverage that they only hear what they want. That's the trick. That tolerance gives you the chance to get to know your audience so you don't bore them, but never stop communicating. Point that firehose to as many audiences as possible. "Normies" have to do this with only a garden hose. Imagine how tough it is to be in sales, but I digress.
You need a lot of observations to figure out what is commonly interesting and what isn't. You have to also accept that the more prolific you are, the more you will have a long tail of useful yet underappreciated ideas.
In other words most "simple" apps are actually full of a ton of features, but they're well placed instead of vomited out to the user. You need both a fully-loaded API and design skills to get there. An immature API leads to weirdness. You'll be putting features front and center that are incomplete or hard to use simply out of guilt.
"It's really that the "normies" aren't interested."
People are interested in things they can control and not be controlled by them. But since "they" do not know about computers - to them a proprietary app they know how to use, is one they feel they can control, opposed to a open source app, they can totally control in theory, but not in reality because they cannot figure out the config, let alone change the source.
In other words, it is how you present it to them. If you can make them understand, that open source can mean that in the end, they can have a app they can really trust and gets the job done - then they will be interested. But if you tell them, they just will have to memorizes those terminal commands, then probably no.
> nerds usually suck at communicating with normal people
Wow, way to buy in to inaccurate, hostile stereotypes. The smart people I know write novels, teach dance, play instruments - and communicate with people.
Oh well, it wasn't supposed to be an insult. Rather a self description. As I am a nerd and do all those things and quite a bit more. I still suck at communicating with normies.
Developer-users are real users. A tool (such as a piece of software) is not just a toy just because it's targeted towards users that actually have the skillset to make proper use of it. In fact, quite the opposite; the most useful tools (in any domain, not just software) are often quite inaccessible to those without the prerequisite expertise. Commercial products may be heavily incentivized to make themselves appeal to even the most inexperienced users, and obtain a much wider userbase as a result, but how many of those users actually do something useful with that, and is the proportion of such users high enough that it would make sense for FOSS developers to target them, instead of their existing more reliably competent userbase?
This is the usual fallacy that assumes users can't either become developers themselves, pay for developers, or wait until some developer cares about their problem and fixes it for free (still way more likely to get results than paying for a support contract with the original developer, and I say that as a contractor).
It doesn't sound like a fallacy to me. You're just extending the statement to also include people who depend on developers in addition to actual developers. It doesn't really change the argument.
I agree with this. On the other hand, the same is true of other things, like the right to free speech: most people don't use it most of the time, but it's critical to have it around anyway. Why would a safeguard lose any validity because most people never use it?
I mean users because I think it's important that people who receive my code can inspect it, especially if a third party has changed it between me and them. I also think they should be able to make their own changes.
You're right, very few care, but it's an important software freedom. Apathy doesn't mean freedom is bad.
Both uses of "users" are valid. Your latter definition probably could use refinement.
I believe what you mean is "people who want to benefit from the technology without understanding or changing it". This is only a subset of users. I think people overindex on these users because they are both vast and a popular monetization target.
This is very true, and I think goes back to the days when it was big news that someone made a C compiler open source - where the users are by definition developers.
A very simple answer: users do not know that they want classic desktop systems, where the OS was a single application and apps was just bits of code inside it. Let's take modern Emacs as an example.
Unfortunately most modern devs do not know that as well. People lost the concept of working in a live framework where pushing just few bit of code suffice to bend their environment. You can automate Emacs without knowing much of it, and without any specific DSL or limited interface for scripting. That's the point that fusion both views, the devs with the full sources and build process vs the users and a specific live instance of a program.
Please try to rediscover such classic tech, because that's anyway the future, those who understand it now are just 10+ years in the future.
I think the main lesson here is that a scripting interface that lets you make major changes to an application, including building UIs, is a great deal more valuable than one that only lets you plug in to extension points that the application developer has already thought of.
This was, of course, a large part of the reason why Firefox was successful in the days when it was successful.
I don't think the idea that things are "very different from the way things were when Stallman began" is very relevant to this. After all, Emacs is one of the best examples of an application whose scripting system has this sort of power.
Item one: people contribute to open source projects if it scratches an itch or it makes them money somehow.
But considering what ardour does, most of your users are not developers. You're relying on the small subset of audio engineers that are also programmers to get an itch. Or a check from... who? Maybe you can or are already getting sponsorships from hardware manufacturers, I have no idea, your software goes over my head :)
Item two: it's 1000x harder to read code than to write it. Maybe perl had it right, being write only. They just admitted no one wants to read code :)
So when someone wants to add minor functionality (they have an itch or it improves their paycheck) it's normal that they don't want to go through all the internals, no matter how well documented your source code is. It's much easier to make changes via a minimalistic (and documented like an API!) plugin system. Especially if you're an audio engineer, not a professional programmer.
I don't think having a 'build' step is much of a barrier to entry. It's more the lack of competence (because the users aren't programmers) or itch.
Even if it were a steaming pile of javascript, it would still be a pain to set up on windows.
I think opens source is still what users want even if they don't want to work on the software. It allows your investment not to go away with whatever company is making it or worse by becoming spyware or subscription based.
That said I think the post asked an important question about what makes users able to contribute and grow applications better.
I think extensibility is correct but the reason it's correct isn't because c++ is hard (though it is). Without stable well documented APIs programming extensions is not a good investment because all that work gets thrown away the moment the project changes it for their needs.
I would argue that Chrome and Firefox extensions are bad investments since they depend on applications for which the API decisions are controlled and directed unilaterally by their organizations and if they aren't being good stewards of those APIs (see manifest v3) you'd need to maintain your own fork of either of those large applications yourself.
For me, the manifest v3 example proves that open source doesn't matter. Chromium is open source, and although in theory someone could fork it and keep v2 backwards compatibility in, the effort is likely to be prohibitive.
The effort is prohibitive for an individual, perhaps, but not for a small company or a large one. Open Source isn't just about preserving individual freedoms, it's about making it easy for corporations to share code without complicated arrangements. Don't like what Google's doing with Blink or Chromium, find a company (there are several) that's stable and offering a forked version.
Being open source doesn't mean the application is a safe investment but it is still a useful bullet point to have. We can and should also judge our investments by how small, simple and composable the application is.
The title of this article deserves to be answered with a strong "Yes!" This is something I've noticed too --- the fact that software is "open source" does not mean that it can't be user-hostile, and the impression that one needs source code and an increasingly-complex build system to do anything can itself be used as a form of discouragement against other easier and more empowering approaches.
If they were going to add functionality, or extend it or in some other way modify it, source code access seems like a basic and absolute requirement.
All the crackers and modders of the 80s and 90s would disagree. There was no expectation of access to any source code, yet people modified software in more ways than ever. You only needed a hex editor and debugger. PC magazines would even publish binary patches of the form "change byte in foo.exe from 3F to 9A".
There's another comment here about Chromium, but Firefox is also a great example; it's open-source, yet they've been adding all sorts of unwanted changes. Theoretically, you could revert them all and build it yourself, but getting to the point of building it is itself an ordeal that also requires more computing power than a typical user might have, and you're still faced with the problem that you may change other things you didn't want changed. In that case it's much easier to patch the binary. The source code only acts as a guide to what to patch, so it's not of no value, and that may be the only benefit that open source has.
To use an analogy, other physical devices like appliances, vehicles, and electronics are modified and repaired almost always without access to the original engineering documentation, or even official service instructions. If one does have such material it can be helpful, but it's not a necessity. Why should software be any different?
Educating people to understand that software is not magic and that source code is not a holy grail will do far more for user freedom than opening the source. But knowledge is power, and those in power don't want others to know too much.
>Theoretically, you could revert them all and build it yourself, but getting to the point of building it is itself an ordeal that also requires more computing power than a typical user might have
I've been compiling Firefox (and Mozilla before that) on consumer laptops with free software for almost 25 years. Your claim that it takes resources regular people don't have is simply false. It used to be hard, it took me an hour or two to set up my first build environment on Windows back in 1999 but in 2000 I got a linux machine and that became like three commands for setup with no fuss and today it's about as simple as opening a prompt and typing a single command. Modifying is not much harder, though if you're unfamiliar, you'd probably want to read 5 minutes of documentation.
> All the crackers and modders of the 80s and 90s would disagree. There was no expectation of access to any source code, yet people modified software in more ways than ever. You only needed a hex editor and debugger. PC magazines would even publish binary patches of the form "change byte in foo.exe from 3F to 9A".
That typically let you unlock otherwise locked or hidden features.
I'd like to see anyone add support for a new MIDI control surface in Ardour just using a byte editor.
There is a difference between making a DAW and publishing its complete source code, and making a DAW, whether open source or not, and making it automatable/scriptable which is what these users seem to be looking for.
Sure it’s daunting if I’m told that for some automation workflow I need to hack on some huge C++ codebase and rebuild it. Embedding a Lua interpreter or another language so one can ad-hoc control your application does not have anything to do with whether your main application is open source or not.
Neovim and emacs are both open source editors, and yet they both provide a hackable interface sonyou can extend them. So does Sublime Text which is not open source. I believe that a response to “I want this stupid custom text transformation for this one project” along the lines “you have the source, implement it” is a very unhelpful one, while providing macros/scripting is the right tool for the job.
> There is a difference between making a DAW and publishing its complete source code, and making a DAW, whether open source or not, and making it automatable/scriptable which is what these users seem to be looking for.
It is already automatable/scriptable, to a huge degree.
What you cannot do is use the scripting to create new GUI elements. That's how/why TFA was originally written.
I feel this comes down to the four freedoms and specifically "The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1)".
In this article it still is clear that this is what both the developers want to provide and the users want to get, however, the disconnect (and the main discussion there) is between what is the most favorable form to study and change the behavior - for some people it's the original C++ code, which gives more power and access to everything, but for others it would be a limited but simpler scripting solution with a clear API that makes easy to write a plugin without having to set up a build environment for a platform where (compared to many other popular languages) that can be a real pain.
Open source is necessary but not sufficient to draw in contributors/enthusiasts. If it's a huge effort to get the thing to build, that is an impediment and reduces the pool of folks who are willing to put in the effort to be able to contribute. If "the code is the documentation" and folks are expected to reverse engineer how it works from the code -- another barrier to deter folks. And so on.
A plugin architecture may be the sweet spot to pull in technical folks without imposing the complete learning curve on them. Examples such as Firefox plugins, gimp plugins, NextCloud apps, etc. come to mind.
One could probably look at steam stats, using their categories, user ratings and license info to see if "open" gives any extra kick to the user feedback. Dunno if theres enough data there for really valid conclusions.
Certainly there's places where "open source" isn't the advantage it is for say, compilers and network infrastructure. I'd love my car's software to be accessible and hackable; for example... But I'm happier that I am not required to think about it, to the point that I'm not terribly concerned I can't modify it.
Only time I check a licence on a project I'm using (besides checking for AGPL at work) is if I'm thinking of contributing somehow.
If it's any kind of "open core" or "source available" corporate one, then unless it's an egregious bug that's affecting me and others, I won't bother, as I'm quite reluctant to do free work for a corporation's benefit.
This is why I work on Nix, and why I want Nix to run on Windows.
I can't make C++ stop sucking, but I can make it so any kind of developer environment on any platform is 1 click away.
After that, I can get back to PLT. I think the C++ + scripting language paradigm sucks, and we can do better. But the lowest hanging fruit is developer environment ease.
It's a nice post and I enjoyed reading it, but I think the title is somewhat misleading.
Obviously what users want and software being open source are two different things. It's quite possible to be open source and still give the other users what they want. So no, open source is not a diversion, but it isn't everything either.
AmigaOS is a closed source operating system that's better understood than most open source ones. If Ardour were closed source but understandable and easily extensible, everyone would be happy -- including the author who can make some money off his efforts finally. The Sublime Text model should be considered here.
1. 3rd party plugin APIs (VST2, VST3, AudioUnit, LV2)
2. Lua scripting interface, covering very large chunks of the internal API, already used by many users to do some very clever and/or useful things.
3. C++ source, generally well reviewed by most newcomers
what is does not have, and which is how TFA originated, is a scripting system that lets you build new GUI components.
So it's a feature request. FOSS doesn't make feature requests go away.
And you've already built a bunch of things for customers to do integrations and/or customizations. It just turned out that you did that so well that they expect even more. Honestly, you should take it as a complement, imho.
It is, however, a problem to think about when one of your "competitors" major features that differentiates them from other similar software is a scripting system that can provide "just what users want".
yes extensibility via scripting has value as an alternative to modifying the source, even if it exposes a limited API
and yes c++ builds are unnecessarily hard and waste time for beginners and experts compared to most newer languages
not sure either of these means 'open source is a diversion', but would agree with a different conclusion that commercial software can lead to better user outcomes sometimes. adobe is an example where they squander some of that value add by making the ancillary experience miserable
to the comparison w/ reaper's scripting -- my guess is reaper invested a lot of iterations and user research into creating a usable scripting system. getting this right is hard in the same way as creating an intuitive and productive UX
The only reason I use Ardour is because it is open source. I have no plans on modifying it, but I like knowing it’s an option. That said, I can see why someone would want a more robust scripting interface.
It's easy to get caught up in a primitive mode of thinking "FOSS license good, proprietary license bad", but we have to remember that free software licenses are not ends in themselves, but are a just a means to achieving freedom for users. Whether this goal is really achieved is a function not just of the software license but also of the actual design and customizability of the software in question.