Source code is not enough
fuzzypixelz.com
fuzzypixelz.com
I don't think it's reasonable to expect an open-source maintainer to create a better development experience for you than the one they use themselves. If you're not up to editing Whitney-style code in a text editor, you should get good.
But conversely, just publishing a "source code dump", when you yourself work in a much richer development environment, is not good enough. If there's a "how to set up your dev environment" wiki page that you point other developers to, that should be part of your open-source release. IDE project definitions, project structure guides - whatever you use for making modifications to the project is what you need to publish. And if as a maintainer you don't make those steps documented and reproducible, well, that's ok, but in the long run you're only hurting yourself.
In particular, e.g. RedHat's policy of publishing only the "final" source code for their patched kernels, and not the git repo with history (which is what they use when developing it internally) is a straight-up GPL violation as far as I'm concerned.
This is clearly true. I didn’t read him as demanding that. I think his point is that the fact that something is FOSS doesn’t alone imply that anyone else can actually do anything with it, so people should either not make that claim, or acknowledge what else is needed.
How ? Are these repos insufficient ?
https://gitlab.com/redhat/centos-stream/src/kernel/centos-st...
https://gitlab.com/redhat/centos-stream/src/kernel/centos-st...
Things change more frequently behind the scenes than what appears publicly.
I've worked in the past on an open source project that is forked from an upstream codebase where the git history and all new tests in recent years are proprietary so I'm definitely very sympathetic to that argument. Its very hard to get people who have no experience in that kind of environment to understand just how much work goes into merging such changes and reverse engineering the bugs from the code changes in order to test for them.
In that kind of situation, I think you're better off just hard forking but still keeping an eye on upstream's release notes in case they make a specific change that would be useful to your fork. Trying to maintain full compatibility with upstream releases that don't share their git history is a Sisyphean task and that's probably the intent of many of the corporations that do open source that way.
It's very, very hard to tell what code got changed for what issue in those commits.
Luckily, this didn't last all that long, but dear god there have been days I've chased back code in the git history to find out why it is there and found it was already there in the original import...
Yes, I know, but that's immaterial to the question of whether it's a GPL violation, or whether it's a moral way to develop software. Free Software means everyone gets the freedoms, even Oracle.
A lot of that is made easier if the maintainer takes the time to publish all the ancillary pieces they use when making modifications to the project - secondary documentation, build environment setup support, etc.. Yes, there is always a certain level of inherent difficulty in making changes to software - apart from anything else, not everyone is capable of programming at all. But making sure you're really on a level playing field with the original maintainers in terms of tooling, environment setup, and available documentation, makes a huge difference.
I can see what you mean. At the same time, there's always been room for the 'cathedral' form of free software. GNU itself was once much more closed-off when it came to source releases.
So it's hard to argue that if Red Hat does things the same way the FSF did for at least its first decade, it's violating the GPL.
(Also, the idea of using source history during development was a lot less widespread then; I don't know if CVS even has a "blame" function, and it would presumably have required connecting to the server if it did)
If you're shipping something derived from other people's copyrighted work, you need a license and so you need to comply with the terms of that license. If you're shipping something that you hold the copyright on, then you don't need anyone's permission and aren't obliged to follow any license terms.
> They aren't obligated to ship the details of every internal partial version,
They are obliged to ship "the preferred form of the work for making modifications to it." I would think that for most contemporary development workflows (where one is accustomed to using blame/bisect/etc. during development) that would be a git repository.
> which might even include things that can't be legally shipped (confidential information, for example), which is what a complete git history would contain.
That's their problem. You don't get an exemption from the GPL just because complying is difficult.
If you are releasing PII, GDPR comes into play if any of your contributers are European.
Does your right to the source under a GPL type licence trump their right to privacy under GDPR. If you are arguing that full Git repository releases are necessary to meet GPL licence conditions, then I think you are making this argument
It's not that one trumps the other, it's that both are legal requirements. If your project is derived from GPLed code but you can't legally publish the source for other reasons then you can't legally distribute your project at all. Just like if you make a project that combines code that's under two incompatible licenses, it may just not be legally possible to distribute that project at all. (See e.g. the Wii versions of Freddi Fish etc., which had to be withdrawn from sale because they were distributing ScummVM-derived code without complying with the GPL).
(Of course in practice, most likely you can scrub PII from a repository without making it any harder to do development. You just have to put a few minutes into fixing the problem instead of using it as an excuse)
It's the open source marketing campaign that said that Bazaar is preferred and claim it give superior outcomes.
Ive never seen any requirements for documentation. I guess in the 80's 90's code bases were not yet so complex and had som many dependencies as today. I think this article makes a very valid point.
The first example is not FOSS because of its license. There are loads of examples like that. I don't see how it relates to the complexity of build systems or how it affects freedoms.
The obfuscation point is kind of interesting. I'm guessing a minified JavaScript file does not count as open source even if it is distributed with the correct license because it's been transformed by a machine. If you hand wrote some obfuscated JavaScript I'm guessing it's fine. You could argue the end result is the same, or how can you tell it's not hand written, and you'd be right.
Then it goes on to talk about upstream and what not, but I don't get what the point is.
Then the last paragraph talks about forcing software to be audited and enforcing regulation. To me, this is the epitome of anti-free software. Now you can no longer run whatever program you want and instead only what <someone>(your OS vendor? The government?) wants you to run.
I believe guix and nix have largely solved that by writing build scripts for everything they're willing to bring into scope. Debian seems to be a mix of patching upstream source and build script changes.
A few projects compile to C and ship that one program.c file - sqlite comes to mind - but editing that one source file may not be easy if it was built by a build system that did lots of surprising things.
I'm mostly interested in llvm and we try to make it easy to build on a variety of systems, so it could totally be worse, but it's not easy either. And that's partly by DIY'ing a bunch of stuff that could be library dependencies.
I've no idea what to do about this. It feels like a lot of engineering effort is lost to chasing build weirdness. Open to suggestions!
p.s. I blame cmake for a lot of build complexity in the C++ world, and npm for whatever the hell is going on over in JavaScript. Random node projects from GitHub never run for me.
Thankfully the problem is getting better. Most languages now have a central package repo as well as killing off dynamic linking so the distro maintainers don't attempt packaging libraries.
Assuming we could have the ~10GB RAM on chip to support such a nightmare.
While I somewhat agree there are levels of obscufation, just because something is hard to understand on the first go isn't sufficient for something to be "non-free" in my interpretation, like the b interpreter.
The GPLv2 contains this sentence:
> The source code for a work means the preferred form of the work for making modifications to it.
And I think that's really the fundamental question at hand. If the original author(s) actually write in a particular style (I guess the b interpreter is a case of this?) then it's ... kind of annoying IMO, but it isn't nonfree. On the other hand if the original authors wrote another representation and then intentionally obfuscated before publishing it, then that's clearly intentionally aimed at reducing the ability of others to exercise the 4 freedoms and that's a problem. And I do think there's some grey area in the middle; things like $BIG_COMPANY releasing the source code for something, but even if they have no intention of making it hard for others to work with that code it was written for their internal use and it's tied to internal build processes purely as a practical matter.
Distributing ugly and unmaintainable code because that's the only code you have is allowed (and sometimes that happens because the code works just well enough to get an academic paper published and isn't going to be polished any more than that).
I think the Kolmogorov complexity of serious production codebases is very high -- in order to convey what the codebase does, you have to transmit roughly as many bits as the codebase itseld. In most companies, you already have a way to get a "compact, human-readable description" of what the code does -- it's called asking your coworker, or reading your internal documentation. Ramp up is still hard.
This holds only if you have sufficient context, giving what is virtually an untyped function into e.g. mypy will not provide anything meaningful. Even languages with rich type systems like Haskell do require some types - even implicitly - to infer everything else.
In contrast, copilot has access to significantly more information when emitting the type-annotated code, including context of what the project is like, how are other functions defined, plus all the prior knowledge accumulated from training.
> I think the Kolmogorov complexity of serious production codebases is very high
Do serious codebases exceed gigabytes in raw storage?
> in order to convey what the codebase does
Doesn't this assume no priors / blank slate?
If the Haskell compiler is spitting out "ambiguous instance of +" or whatever that error message is, it's a sign that the author doesn't understand what they're asking for. Taking a language whose value proposition is "I refuse to compile your code if there is the slightest indication that it's not perfect" and slapping a fuzzy ML model on top of it to suppress a class of errors is not a good idea.
Type systems exist as a way of ensuring that the programmer's mental model matches the code. Offloading type annotations to something else removes that safety from you.
> no priors
Sure? I don't see how that changes anything. My point is just that we already have very high quality summarizers of code, but software development is still hard. Making a model that attempts to approximate the summarizers of code that we already have isn't going to help much, no matter how good it gets.
I am not saying that that is a good idea, I am expressing that there are limitations on what one can infer without broader context.
> Offloading type annotations to something else removes that safety from you.
Counter argument; the annotations can be used as a second sanity check; if the inferred types match your mental model - and the type inference model is good - then you know that your mental model is correct and you didn't miss something.
My requirement is user-respecting. Software should respect users, be useful to society, and should not (be designed to) cause harm (environmentally, psychologically, should respect user's privacy - and why this is important is its whole own discussion).
Free software is (arguably) a requirement for being user-respecting. A necessary condition. Because it is theoretically necessary for users (or someone they ask - most people don't have the required time / knowledge) to be able to adapt or maintain pieces of software they rely on, if its original builders ever disappear, want to take another path or simply won't fulfills the user's need. Because the users should be able to inspect their software. But indeed not sufficient. You may need guidance to understand the code and build it (documentation) [1]. You need reproducible builds (so someone can check that the shipped version does what the code says, so users don't need to build the program themselves each time to be sure). And other requirements too: like the software should not manipulate the users to make them do things that they would not have done and cause harm, or skew society in some undesirable direction. Which can be subjective.
For instance, Chromium is free software, probably documented quite well, but still serves a monopoly from an ad-supported company, which is arguably "not sufficiently" user-respecting and helps it to push the entire world to an economical model that relies on user-privacy issues, manipulation caused by ads, and control from a company bigger than countries and yet not democratic at all (assuming democracy is desirable).
Software should be free. And more. How exactly? I don't really know.
[1] Note that I also think we can't require documentation or any extra work from people contributing free software neither. They already make a gift to the world by releasing their free software, especially if they do it in their spare time.
Also, if I recall correctly, MS has been able to get changes pushed upstream.
Are you not equating the resources needed to create a browser with the resources required to modify one?
Edit: It’s not clear why you think I did.
This is not logically correct. Let’s consider two statements:
1. If you are fit enough, you can run a mile in less than 5 minutes.
2. If you are fit enough, you can run a 100 mile ultramarathon.
Both statements are true, but clearly the level and kind of fitness required to do one is different from the other.
No offense, but this is the only way I understand your comment too, and apparently we are several people like this. If we take your two statements example, we understood your comment as if you were saying something like "if you are fit enough to run a 100 mile ultra marathon, you can run a mile in less than 5 minutes". Or "if you are fit enough to run a mile in less than 5 minutes, you can run a 100 mile ultra marathon", I don't know. Which might not be what you meant to say, but that's what we understood and why we are surprised.
No matter the logical mistakes people are doing while reading your comment, that's not what is important. What is important is understanding each other, and we apparently didn't get your point. You could rephrase it so we can understand what you want to say. You are telling us that we are wrong in our interpretation of your logical statement but that won't help us understand it. We are not trolling you or in bad faith.
It's not the only thing that is important, but it is still important. If you can't understand the logic of something, that is on you to improve your skills. If you made this mistake with what I wrote, then you will be making the same mistake elsewhere, often without knowing it.
> What is important is understanding each other, and we apparently didn't get your point.
People don't get each other's points all the time. This a is normal part of discussion.
> You could rephrase it so we can understand what you want to say. You are telling us that we are wrong in our interpretation of your logical statement but that won't help us understand it.
Are you saying you still don't understand it now that it has been explained?
> We are not trolling you or in bad faith.
How do you know what is going on inside other commenters heads?
Yes, because they suit Google. I suspect you'd not get your contribution to get back Manifest v2 features which allow tampering with requests from extensions upstream. It would go against Google's decisions. They can say that it's for technical reasons, but this removal also helps their business model.
Chromium is a wonderful piece of software, but it's not politically neutral. Software, in general, is not neutral.
Assuming I have the resources, I can fork it and make the changes myself. At an individual level, I'm covered thanks to Chromium being free software. But at the collective level, not so much. Most people will likely continue to use Chrome (or Chromium with some luck) and play inside whatever limits Google sets. Unfortunately, some network effect is present too, which raises collective issues (some websites might not bother with compatibility with other browsers, for instance). And the collective aspect matters (to me).
Because of this network effect, using Chromium and Chromium-based browsers is, in my opinion, a vote for Google's business model. Not necessarily in the intent, but in effect. The issue is that individual choices don't only have individual repercussions.
Software, including free software, can harm society. Programs are not neutral. Power games are in effect. Hence why I think the free aspect is not sufficient.
I could have used a caricatural open source missile launcher example to convey this idea, but also seams less interesting.
Isn’t manifestv2 basically the same as Apple is doing? Apple has no business reason to prevent better ad blocking in Safari. Having untrusted third party code intercept all of your request is a privacy concern.
> Having untrusted third party code intercept all of your request is a privacy concern
Indeed, but I trust uBlock Origin. More than Google's software.
In any case, extensions are a privacy concern themselves. I still want to be able to install them. Those I trust. Google does have a review phase in their almost mandatory Play Store anyway, they could use this instead of removing useful features if that's their concern.
Arguably indeed. I'll argue this all day. I'd argue that, for instance, Excel is mostly user-respecting, within its own limits. OneNote is, as well. (If you disable telemetry, which is a counterpoint, but could be argued is not a core part of those products.) Note for instance that you can save an Excel document to .ods format, the main format for OpenOffice and LibreOffice.
On the other hand, free software is (arguably) incompatible with being developer-respecting, as TFA demonstrates. Software needs to be developer-respecting to thrive as well.
> Software should be free. And more.
This is not compatible with the statement "developers should be paid". As a developer who would like to make a living, I obviously strongly disagree with this.
Nor is that statement compatible with any sensible intellectual property or copyright protections whatsoever, unless you really just hate software developers particularly. There's no reason why software developers shouldn't be allowed to profit from their work, but J.K. Rowling should be allowed to profit from Harry Potter, or Lin Manuel Miranda profit from sales of the Encanto soundtrack. If you truly believe no artist or creative person anywhere in the world ever deserves to be compensated for anything they do, well, I just really never want to live in the world you imagine.
> On the other hand, free software is (arguably) incompatible with being developer-respecting
If you mean developer-respecting as in "paid developer". That's not true. There are several ways of building a business around free software. Anyway, people releasing their software as free software do it willingly. That's strange to say that their software does not respect them.
> This is not compatible with the statement "developers should be paid"
No. As a developer, I chose to work for a company making money from free software. This company sells paid licenses for extensions (the code is free software, but people, especially enterprises, will pay for the convenience of having it built for them and installed from an easy-to-use UI), support, cloud hosting and customization.
I should restrict my statement however: end-user software should be free software. Not necessarily free beer. And if a customer wants non-free customization, that's fine with me. They are the ones who pay and use the software, under terms they outline in the contract they have with the company. Though I don't enjoy writing such non-free code if it could benefit others and will try to avoid this. That's a waste of my time, I'd rather have my time be spent on stuff that's useful for more people than just a customer whose values are not, by the way, necessarily totally aligned with mine. My company too, by the way. It encourages their customers to allow it to develop customization as open source components (by making a discount, and open source components are more likely to be maintained and get improvements outside this specific customer's contract - improvements can be paid by other customers needing them).
There are ways. Core WordPress and Nextcloud developers are paid too. That's true for many projects.
> If you truly believe no artist or creative person anywhere in the world ever deserves to be compensated for anything they do, well, I just really never want to live in the world you imagine.
There's no bad implication like people being locked up with a closed solution with non-free art. I'm not against it, though I have sympathy for people releasing art under a free license.
For multiple orders of magnitude less opportunity than paid software. You think some internal business to business data processing software backed by hundreds of database tables and containing trade secrets works as an open source model? Because you said "software should be free." Period. And that's software. Those big Excel workbooks with thousands of formulas: that's software too. Internal ETL scripts, R scripts for data analysis: all software. None of that makes any sense as open source software. So what you're really saying is: internal company software should not exist. Trade secrets should not exist. A huge range of what millions of people do every day is unethical because you're not allowed to have a copy you can do whatever you want with. It's selfish and narrow-minded and harmful to our profession.
> Anyway, people releasing their software as free software do it willingly. That's strange to say that their software does not respect them.
I'm sure you can find many examples of people abandoning open source projects because they're not making enough to live on and their users are being toxic to them. You know exactly what I mean.
> I chose to work for a company making money from free software.
"I won the lottery, therfore everyone should quit their jobs and just buy lottery tickets." There is not enough opportunity in OSS for everyone to do this, unless you want 95%+ of developers to lose their jobs.
> end-user software should be free software. Not necessarily free beer.
This is an arbitrary destinction; anyone can be an "end user". And for end-user software to be free, all libraries it uses must also be free, so you've really only excluded ETL scripts here. And you can't have the "free speech" kind without the "free beer" kind.
Every single argument in favor of "all software everywhere should be OSS" has the same fallacy: here's six examples of OSS projects that make money, therefore all 23 million developers in the world can do it, and we will forever ignore all evidence to the contrary. It's unbelievably idealistic and narrow-minded.
Come on, it's very far from what I said. What's more, I'm not particularly lucky. Software companies are struggling to hire, including OSS ones. They are looking for people. It's not like lottery at all.
> So what you're really saying is: internal company software should not exist
I was saying something implying this. That was wrong. My rephrased claim includes internal company software. What's important for me is that the user of a program has control over it. A company has control over its internal software. I still think it would also be better if companies released their software when it can be generalized, so the wheel is not reinvented at every company. But people and companies should be free to write their own code for their own use and not release it.
What I'm against is programs for which the users don't have control on the code.
>> Anyway, people releasing their software as free software do it willingly. That's strange to say that their software does not respect them.
> I'm sure you can find many examples of people abandoning open source projects because they're not making enough to live on and their users are being toxic to them. You know exactly what I mean.
I know what you mean, and nobody deserves this, but this is not most open source projects. You were claiming OSS was incompatible with developer-respecting. That's a stretch. But that could hint that OSS is not enough, not that OSS is incompatible with developer-respecting. I'd argue entitled users are the issue here and as a society, we ought to do a better job of educating people not to be such assholes.
I labored, happily, for free[0] on blender’s dodgy old code with virtually no documentation and the only way to figure out the really tricky bits was hope someone was on IRC who could point you in the right direction. Hell, with half the user features I’d have to read the code to figure out what a particular button did.
Frickin’ nightmare — did I mention happily?
I like to believe the time I spent was worth it because I mostly worked on filling out the python API so other people could write fancy extensions, this was right after the transition to python 3 so somebody had to put in the time as the old system was way too dodgy to be kept.
If I just didn’t work on the things I did because blender didn’t respect me (whatever that means) I can give you a bunch of examples that the users/artists were able to build which wouldn’t be possible because the core devs didn’t have the time to go poking all around and figure out there’s no reason <whatever> couldn’t work. Just needed someone to ask the question and someone else to go find the answer.
Oh, and last I looked blender is thriving. I wish I still had time to hack on it because I really like the abuse.
[0] I did get a hand-tracking doodad for free from the results of this and my name in the credits of one of the movies so not completely without compensation.
If everything is free, then no one has to pay for anything. But everything isn't free. Maybe a bunch of libraries are, but do the suits know how to stitch them together (or even read the documentation)?
And even if it was all free, do you think most people would have the background or patience to sift through it all and turn it into something productive?
Public library cards are free, do you see most people going to libraries and making the most of them?
Even if all software happened to be free, most people don't have the patience to read it. Hence we have people who get paid to read it and figure out what the fuck is going on
Personally i consider a software free if it born free, developed openly so to have eventually a community of different peoples with different ideas, set of interests, culture, ... have seen the code from it's early days when it was small enough to be fully understood and subsequent discussions/evolution happened in such open manner. It's not exactly a measurable thing, and it's not merely "freedom" but for me is a requirement to consider a software as a really free one: the freedom of knowing and trusting it with acceptable efforts.
> the source code of Visual Studio is available
You're talking about Visual Studio Code, but you're calling it "Visual Studio" when you say it.
I could make necessary changes for a customer, fork it, generalize it and then after discussions with the rest of the team, I could get my changes merged after the team came to a consensus. It was a relatively painless process. We could release any time we wanted to.
Then as the project became more popular, 5 years into its life (about a year after I got involved), it became more official and transferred to another team. Then any change had to go through “the process” and any proposed change had to go through levels of approval. I still had commit rights and they didn’t take away my access.
I found myself in the same position as the Haskell developers. Either I had to hard fork the code and have a customer specific implementation or go through “the process”. It wasn’t a fun skunkworks project anymore.
Luckily, one of my last changes before the project got transitioned to another team was an officially supported extension framework where I could customize functionality without changing the base code - much like the VSCode example.
Personally, for OSS I subscribe to "no one owes me anything, I can always fork or submit a patch or use something else".
Then he follows with a list of why compilation is not free and that is his argument why someone should do this for him for free instead of charging him $20.
He also continues with some far fetched arguments that serve as support for his claim that someone should do what he wants.
Open source is not enough: <http://web.archive.org/web/20150828195814/http://adamspitz.c...>
Free software is not enough: <https://jfred.dreamwidth.org/479.html>
A related comment (2020 December 17; 19 points): <https://news.ycombinator.com/item?id=25458080>
One thing I like about Smalltalk is I don't have to wonder what the process is to get to a certain place in the code very often. There's a lot less scaffolding and construction code than with a typical start-from-main program. Little pieces can be tested directly to see how they work.
Does any one really say this?
Every user has the potential to hack on it if they’re willing to put in the time and effort to getting up to speed with the codebase but the license doesn’t guarantee that right.
In fact they generally provide it “as is” with no expressed or implied usefulness.
So no mandatory security audits, no mandatory documentation, no onboard team to help the junior-woodchuck devs, nada. If it breaks you get to keep both pieces and if you manage to fix it you might be liable to share your changes with the rest of the world, depending on licensing and what you’re doing with it.
Requirements which make the developers responsible for anything more than what they want to provide will just kill open source because they also have the freedom to not labor for free if they choose not to. If they have to get approval from The Commissar of Free Software before every upstream push, well, silly argument but it makes the point.
I maintain forks that are frequently rebased on main/master with a few users. I have even suggested this as an action to people who wanted different features that I was not capable of maintaining.
However for many projects ‘just fork it’ is not a good faith suggestion, so it can’t be a blanket answer that applies to all FOSS.
As a matter of fact, I have sent multiple pull requests to VS Code recently. I have found the codebase to be relatively accessible (despite the size).
Even if few(?) individuals care about it, it can make a difference for companies. Both Google and Facebook are using VS Code internally (and they wouldn't if it wasn't open-source).
I think that instead of looking for a daddy to tell people what to do, the best thing is to come up with a reasonable standard for public projects. Projects that are not only Free by the letter of the law, but are actually designed to encourage and facilitate users in exercising those freedoms. And by "come up with," I mean compose them yourself and explain the reason for each goal that the standard is meant to solve, and how the rules within the standard address those goals. Like Stallman did.
I think it'd be nothing but positive to have some gold standard eminently publicly-hackable and accessible Free software projects out there. After criteria are laid out, I'm sure a few will be discovered in the wild.
Another couple of things about easy-to-build, well-laid-out, well-commented projects with few idiosyncrasies is that they're great to learn on, and often possible for experienced programmers to jump in and out of. Publicizing projects that want to prioritize those features, especially as models, could be consciously aimed at attracting the help to maintain those features.
Open source has always just been about the license... If you use OSS and distribute it, you make your changes available. That's it. There is no higher meaning. If people want to do more that's on them, if they don't, that's ok.
Free software has always been about freedom and licensing just as a technical aspect. At some point open source rebranded this and put more emphasis on the advantages this gives you as a company as opposed to as a user (which free software highlighted).
So, legally speaking it is just about the license, but humans exist and have opinions. For instance people like projects to be developed in the open and not android's throw over the wall. That doesn't make it not open source, but you have people complaining that it is not "proper open source".
> If they don't that is okay.
Legally yes, in practice people grumble and won't contribute.
Let's be real, that happens no matter what (both the grumbling and not-contributing). People bitch about literally every open source project I can think of... Linux (Linus is too mean), Systemd (not Unix-y enough), Gnome (too pretty and not enough features like KDE), KDE (too many features and not pretty), anything RH/IBM/Amazon/Google/Oracle/Apple/MS sponsors, etc...
I honestly can't think of a single open source project that people don't bitch about so yes, I don't really care about their opinions. Open source is what it is and you use it or don't.
You should evaluate projects for quality, but projects with low quality aren't any less Free -- you can do what you wish with them at your own risk with no warranty.
The ability to deploy - especially on user owned devices, seems underconsidered to me.
Then again, given the number of non-compliant routers in the world, it probably wouldn't make much of a difference.
Sound like he saying Linux should be a bit more like OpenBSD :) But OpenBSD, I think, audit their own code due to resource constraints.
Code is often very complex for good and bad reasons but very rarely is it done just to prevent comprehension. If it’s not being done intentionally then I’m sure that as long as you’re skilled and taking the time, you can understand the code.
This is true whether or not it has been done intentionally. Which is why it's not a "terrible take" but a completely trivial and obvious comparison. It can also take an enormous amount of skill and time to understand some code, and far less skill and time to understand other code, and this range is only partially related to what the code is trying to accomplish.
You can even make an argument that intentionally obfuscated code can be Free (I would make that argument.) The OP is making a different argument that whatever you think of them, both intentionally obfuscated code and unintentionally obfuscated code are obfuscated code, which is not a big reach.
I'd add to that argument and say, that even though whether software is Free or not is a binary (if it can be relicensed under the GPL, it's free), it's pretty obvious that some software is "Freer" than other software. As a metaphor, having legs and not having legs is pretty close to binary, but if what we're actually concerned about is walking, the quality of the legs you have irt walking can range from indistinguishable from a person with no legs to marathon runner.
Thinking publicly about the value of particular standards is neither gatekeeping or entitlement.
He’s simply making the case that as things stand, open source doesn’t enable people to do much with the code if they aren’t part of the project itself.
For the most part that seems true. Why is it such a problem for him to say it?
There is no other interpretation. "not enough" implies there should be MORE, which is a requirement. The requirement is never elucidated. This is a Mazouz gripe post for OSS issues that are not unknown, and provides no insight.
> open source doesn’t enable people to do much with the code if they aren’t part of the project itself
All code requires effort to utilize. Proposing that OSS should have some additional (hand-wave whatever you imagine) requirement lowers the effort to utilize it in some way and that result differs for each program. Imaging OSS code that simply does not compile. What more can you ask? Homogenization of code is a Sisyphean endeavor. The best we have to a uniform interface is source-code text.
Yes it is. At the top of the article he says:
> People will often claim that since X is Free and Open Source Software, every user of X is enabled to hack on it and bend it to their will.
Which is basically the same goal as Alan Kay had for smalltalk systems. Why is it so controversial to say we haven’t reached this goal?
As for looking a gift horse in the mouth, you may not be aware of how much that sentiment devalues FOSS. The implication being that as long as it’s free, it doesn’t matter how bad it is.
As long as it’s free, it doesn’t matter how bad it is, because at least you're giving others a chance to make it better, INCLUDING improving the code quality to enable less experienced developers, or even laypeople, to collaborate. No one should expect you to take that burden upon yourself. If all developers did everything right on the first try, we wouldn't need open source.
It’s strange to suggest that bad code is good because it provides a chance for others to fix it.
It’s also obviously not true that if developers wrote great code the first time we wouldn’t need open source.
On the contrary, that would make open source far more valuable because it would be easier for people to add to or modify, and a better example for newcomers.
The author is not attacking the existence of open source. He is saying it is necessary but not sufficient for empowering people.
Because he referenced the GPL, which includes such a clause indicating that there is no quality beyond the source that constitutes the property.
> It's strange to suggest that bad code is good because it provides a chance for others to fix it.
https://www.fsf.org/blogs/community/201cthe-printer-story201...
> It’s also obviously not true that if developers wrote great code the first time we wouldn’t need open source.
Moving the goalpost to another hand-wavy quality of "great code", is not meaningful. The fact you think this is some sort of concrete goal (as opposed to a quality about simple utility), is telling.
> He is saying it is necessary but not sufficient for empowering people.
That's circumstantial, like most things in life.
You continue to argue in bad faith along every one of these digressions from the article. Good luck with whatever.
That clause means that the author of the code isn’t legally liable for defects.
How is this relevant at all to the article? Nobody is talking about legal action.
>> He is saying it is necessary but not sufficient for empowering people.
> That's circumstantial, like most things in life.
Obviously. But that doesn’t mean it doesn’t matter, nor that we shouldn’t discuss it.
> You continue to argue in bad faith along every one of these digressions from the article.
Generally when someone complains about an argument being in bad faith it means they are personally invested in defending something they think is under attack. It’s not clear to me what you think you are defending.
> > People will often claim that since X is Free and Open Source Software, every user of X is enabled to hack on it and bend it to their will.
The requirement is never elucidated, stands. "bend it to their will" is not a qualitative or actionable statement, which is impressive hand-waving.
Nothing about this is related to Alan Kay.
Here is one of many places where Alan Kay talks about making programming available to everyone.
It’s a good starting point for work exploring the deeper idea of enabling people to ‘bend software to their wills’.
The lack of documentation is also a problem with specific projects only, not a widespread F/LOSS issue. And again, if the project lacks in this area, you have the means to improve it.
As for projects being difficult for newcomers; yes, this is an issue. But it's one you'll also encounter when approaching _any_ codebase, where you'll find it takes time and effort to understand and contribute a meaningful change. If you're not a programmer experienced in a particular tech stack, then it's obvious the barrier to entry will be even higher.
None of these issues are specific to F/LOSS, so the post reads like a rant from an entitled user. The right mindset to begin with should be one of gratitude that developers are granting you these freedoms which you don't get with the majority of consumer software nowadays.
And another benefit of F/LOSS: just because a project is inaccessible to person A, person B might find it easy to contribute, which encourages a community to exist, from which everyone ultimately benefits.
> The right mindset to begin with should be one of gratitude that developers are granting you these freedoms which you don't get with the majority of consumer software nowadays.
By this logic, FOSS is always impervious to criticism because non FOSS is worse.
That’s not an argument against the premise of the article.
F/LOSS projects have plenty to criticize, like any other project. The major difference is that they provide more freedoms, where these issues can be fixed by external contributors. Saying that's "not enough" is very entitled, and missing the point.
This is just not a logical reading of his argument. He is saying FOSS is necessary but not sufficient. His argument can clearly only apply to FOSS and doesn’t apply to other kinds of software.
> Saying that's "not enough" is very entitled, and missing the point.
Except that’s not what he’s saying. You are responding to the title of the piece but not that argument it makes.
He’s saying FOSS is not enough to empower people in general to hack on software and bend it to their will.
It’s not clear what you mean by ‘entitled’ in this context.
In that case, I'm unclear. Is he advocating for OSS devs to do more to make projects inclusive?
Or is he saying that OSS isn't all that, and the code to Asperite might as well be closed, given how much beyond the source code goes into making a software product?