IMO this is what "source in the preferred form for making modifications" is all about. GNU themselves give the example that C source generated from a perl script isn't good enough - if the way you change the program yourself is by changing the perl script, then you need to release that perl script.
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.
> 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.
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.
The other problem is ancient codebases that have been through multiple version control systems. Or started with no VCS at all. For example, any history before 2000 is lost to LibreOffice. What is worse is that for some time the internal processes of Star Division meant that someone bundled up a bunch of code into a single commit, with a terse message about what they fixed.
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...
> 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.
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.
The difficulty with the argument that only publishing "final" versions is a GPL violation is that the FSF itself used to restrict access to development versions of their code and only provide final releases, back in the mid 1990s. Doing development in the open was something egcs pioneered; in the old days only a small set of contributors would have access to pre-release versions and they were strongly pressured not to share it.
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.
The FSF held the copyright on those projects (and required copyright assignment from outside contributors) didn't they? Whereas although RedHat is a significant contributor to Linux, there are many other copyright holders.
(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)
Not sure what difference this makes. The GPL is binding at the point where someone ships a release. They aren't obligated to ship the details of every internal partial version, which might even include things that can't be legally shipped (confidential information, for example), which is what a complete git history would contain.
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.
Now that is interesting. If you release a full Git repository, it may well contain a lot of information that is potentially PII. Names and email addresses may well be PII, commit timestamps might be as they may indicate someone's location.
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
> 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)
RMS have stated in several interviews that doing development in the open "bazaar style" is not required. Cathedral is equally valid, and he doesn't care.
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.
I thought it was fairly well known that this is intentional obfuscation on Red Hat's part in order to make it harder for Oracle to use their work. I can't blame them on that account.
> I thought it was fairly well known that this is intentional obfuscation on Red Hat's part in order to make it harder for Oracle to use their work.
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.
I was thinking of https://lwn.net/Articles/430098/ - I remember there being quite a fuss about it at the time, but RedHat employees were clear that it was their company's deliberate policy. Perhaps things have changed since then.
There has been quite a bit of change in that area since 2011 and I can't fault you for not keeping tabs on it. Bad news always travels quicker than good.
Things change more frequently behind the scenes than what appears publicly.
> 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.
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.
The article is mostly talking about things above the source code level though, including the economic and time investment needed to compile/install software, the sheer size of large projects, plugin/etc interfaces for easy extensibility, source code written in unreadable languages (b and APL are mentioned), available programmer time etc.
> The article is mostly talking about things above the source code level though, including the economic and time investment needed to compile/install software, the sheer size of large projects, plugin/etc interfaces for easy extensibility,
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 have re-read the post many times and I don't quite get the 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.
Minified JavaScript is OK if recipients can also receive the original JavaScript, just like it's ok to distribute executables if recipients can get the source code (this is for GPLed works).
Building software is often a massive pain in the ass. I don't think that's essential but it usually seems to be true. Occasionally a program is wholly in some interpreted language in which case it might run or you might have the same experience with dependencies.
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.
The root of most of these issues is the fact C/C++ has no package manager and central repo. If you want to build a fully Rust program, its trivial. As soon as it requires something C based you now have to track down the things it needs. And the build tools don't even know what is required. They just attempt to build and spit out some unintelligible error you have to search to find the stack overflow post telling you what package is needed and the 10 different names it has on different OSs.
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.
I don't see it. Say there's a magic central repo where all 'good' C++ goes. Each project still has it's own build system, which interacts with unexpected environments by falling over. Exactly like we have today.
At some level all software will be too complex to understand easily within one sitting. That is just the nature of life. In my opinion, learning to read someone else's code is a sign of maturity, the ability to not just jump to churn or replace something just because you don't understand it is very mature.
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.
> 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.
Yes, distributing modifications to GPLed code only in obfuscated form is a clear GPL violation.
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).
Eventually, we will rely on machines to help us understand software code. Think "fill in missing code comments with GPT-3." Now add 10 years of focused research to make this more reliable and intelligible. It must be inevitable, right?
Copilot can fill in type annotations in python, “resolve” some bugs, explain code, “make it more robust”.
The features are available in copilot labs, they are obviously very much WIP, but they are definitely not useless.
Type inference really doesn't require ML (and is probably better done without it in order to be robust).
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?
> Even languages with rich type systems like Haskell do require some types - even implicitly - to infer everything else.
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.
> and slapping a fuzzy ML model on top of it to suppress a class of errors is not a good idea.
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.
The question for me is probably "not enough for what"?
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.
Personally i consider Chromium as not really free. Simply because of it's development model (not developed in an open community form, from the start) and codebase size (no single human can know it all).
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.
I would think Chromium is just the opposite. If you have the resources and the knowledge, you can fork it and make it your own. I doubt Microsoft’s version has any Google dependencies.
Also, if I recall correctly, MS has been able to get changes pushed upstream.
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.
> They can say that it's for technical reasons, but this removal also helps their business model.
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.
I'm not familiar with the Apple ecosystem. But it is my understanding that Safari does this too indeed. That does not make it right.
> 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.
Not the parent poster, but likely because "If you “have the resources and the knowledge” then you don’t even need the source code. You can build your own browser from scratch." is true if and only if the resources required to modify the browser are equivalent to the resources required to build it from scratch - otherwise obviously most people who can do the former do not have the ability for the latter.
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.
> No matter the logical mistakes people are doing while reading your comment, that's not what is important.
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?
> Free software is (arguably) a requirement for being user-respecting.
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.
> There are several ways of building a business around free software.
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.
> I won the lottery, therfore everyone should quit their jobs and just buy lottery tickets
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.
> 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.
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.
> 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.
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
See also https://ghuntley.com/fracture which details how the source code of Visual Studio is available but it’s fundamentally useless by design as what people call Visual Studio (the product experience of the standard desktop edition) isn’t possible if you compile your own version. Yes, this includes VSCodium and the gap is getting worse as time goes on with the rollout of things such as GitHub copilot. Microsoft is locking down access to Top 6 LSP servers…
But it really isn’t. Sure the lower primitives are opensource but the value of what people call VSCode // the language servers and the market place. Yeah, they aren’t and you can’t use it if you compile from source. I detail this in the link above.
I worked on a company sponsored open source project for a couple of years. We were a small team from different departments who kept it going as both a labor of love and because we used it for customer projects.
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.
Author of this post should develop something bigger by himself, then mantain it and after all of this succesfully completed complain about status of "free software".
So on one side we have folks saying we expect too much from OSS devs and we're burning them out. And then on the flip side in this post were saying they need to support a variety of compilers and endless hardware configurations.
Personally, for OSS I subscribe to "no one owes me anything, I can always fork or submit a patch or use something else".
Mahmoud author of the blog post wanted to play around with a tool and found that he has to pay for something.
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.
Interesting, how image-based development can make a big difference in comprehensibility at the expense of more complicated sharing.
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.
> 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.
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 had never thought that the "you can always fork it" as a way of shutting down discussion.
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.
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 get the point, but credibility is dented a bit by making it about FOSS and then using an example that isn't FOSS licensed together with Arthur Whitney's b which doesn't even have a license.
Very good post with a lot of detail, but very vague on the action that it's looking for except for a vague, ominous nod to "regulation."
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.
Tons of people try to come up with more "meaning" behind open source, maybe they're bored and are trying to find a new religion or something.
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.
> 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.
I get where the author is coming from but I think they are conflating quality aspects of an OSS project (readability, maintainability, whether or not it builds on your machine) with aspects that make it Free Software or not.
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.
Seems sensible. Whenever i've had to do a code escrow with a corp customer, I've included the whole build system, documentation and enough to make it turnkey.
For Open Source, it's like Open Car Parts.
This has a really terrible take where the author compares javascript obfuscation to source code complexity, suggesting that source code that’s as hard to read as obfuscated JS is unfree. This is a pretty flimsy point - so much that I doubt this article was written in good faith. Firstly obfuscated javascript is intentionally modified by a program. Secondly, does this mean that any source code that’s too complicated for the author is suddenly no longer FOSS?
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.
> 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.
I absolutely despise this post. As an open source dev, politely fuck off with your expectations of me. The source code is right there, MIT licensed, go do the work on your own to work with it. Its not obfuscated, it's the same stuff I work on every day. I'm not required to accommodate or cater to other people wanting to develop it.
I don’t understand why people are reading some requirement for them to accommodate something into this post.
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?
Except it's not actually true. Build issues are mostly a solved problem with reproducible build systems, like Nix and Docker to an extent. If a project is not using this, kindly suggest it to its authors, or, you know, propose the change yourself.
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.
> 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.
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.
No, that's not what I'm saying. But the article criticizes general issues of _any_ software project. Where the critique doesn't make sense is trying to say these issues are specific to F/LOSS, and for that reason "source code is not enough".
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.
> Where the critique doesn't make sense is trying to say these issues are specific to FOSS
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.
> people are reading some requirement for them to accommodate something into this post.
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.
Because it's an expectation about the quality of the maintainer's work. FOSS and code quality are two very different things, and they should stay that way. The saying "looking a gift horse in the mouth" comes to mind.
You seem to be validating the original complaint - that FOSS alone doesn’t empower people the way it is often claimed.
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.
On the contrary, this is the sentiment that encourages us to make free software in the first place. This is the only reason FOSS exists, even. Who in the world would license something under the GPL if its terms didn't make it clear that the software comes with "ABSOLUTELY NO WARRANTY"?
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 not clear why you’re taking about warranties.
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.
> 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.
> Because he referenced the GPL, which includes such a clause indicating that there is no quality beyond the source that constitutes the property.
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.
> 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.
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?
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.