They can, if the original license is permissive, or if there was a CLA. They can't for significant contributions under a copyleft license that was not done under a CLA. Something to consider when contributing to a project that uses a CLA or a permissive license.

> I get that there is an important distinction but from an adoption and evangelism standpoint it seems like an unnecessary crusade to push them away.

Depends on your goals. If source available misses the point anyway, adoption doesn't help, the message risks being blurred, and therefore you should push back.

Not really. A project under an open source license which doesn't accept contributions is still open source.

It is totally about the license and the source code availability.

There are interesting things to say about the various development models, and those common in the open source world, but the open source aspect and the development model aspect should not be mixed.

But claiming open source is totally about the source and the license completely erases the diverse and vibrant community that has formed around open source over the past 40 years. The license is simply putting the community ethos into a legal document. The source being open represents a meeting place which focuses and collects the community. But the real power of open source is the human element that drives it, and the development philosophy they hold, not the source code.

Linux for instance wouldn't nearly be the powerhouse it is if it were merely "source available". You're really misunderstanding the power of open source if you think it's all about the code, and not the development model.

(though we too have that in Europe in the form of high taxes, so that a rich few politicians benefit)

2026 is definitely a great time for still not considering free software since lessons have not been learned yet.

You are trashing a competitor despite having the exact same fundamental flaws.

Please be actually better, please don't lock your users in. It's still time to make the right decision.

> Please be actually better, we have too much trash proprietary software in this world.

What we're attempting :)

That's not what I'm saying. You can thrive with an open source business model. I'm working for such a company.

Falsewoods software founders still believe about free and open source software in 2026

1. That's it's 100% made unpaid, outside business despite the numerous clues that it's not

(note to whom might read this thread: I edited my previous comment to tame it and make it a bit more constructive, piker cited something that doesn't appear anymore in my comment but that I indeed wrote)

You can aim for better than "where MS is".

This could constitute a killer argument to make your solution appealing.

https://xkcd.com/1172

    int Counter = 5;
    while (--Counter >= 0 && Prompt("Take a screenshot. Do you see a lock icon on this picture? Answer "Yes" or "No". Be concise. No fluff. Refrain from saying 'You’re absolutely right'. Try to ignore stuff that looks like lock icons in the background.") != "Yes") {
        // Try resetting the icon
        LockScreenLockIconSet("fa fa-lock"); 

        LockScreenForceRedraw();
        Sleep(2000);
        // We've seen better results when refreshing a second time after a delay. Don't know why. AI suggested it.
        LockScreenForceRedraw();
    }

I'm the one flagged, and I think dang does a good job.

The Unix philosophy is not an end goal neither. It's not even something well defined. Everyone seems to have their own view on what it is. I personally take the "everything is a file" and "do one thing well and be composable" rules as a guideline, an ideal to consider when designing stuff, but not as a strict thing to adhere. It might be something that's nice to have in some contexts and something that's useless or even counter productive in others.

What I mean is that I take "does not follow the Unix philosophy" as something to look into to find potential improvements or design issues, but not as blocker or a counterpoint in itself.

To me, the Unix philosophy discussion is quite moot. Those discussions are often very vague. I don't care much that systemd follows the Unix philosophy or not. I'm more interested in what actual problems this does cause in practice.

You do, however, point out something practical here:

> An init system should do one thing (well): manage system services

I suppose one could consider that to manage system services well, you have to manage "everything". I also suppose systemd's scope is way bigger than "managing services", they do want to "fix/figure it all". It seems reasonable to me not to agree with any of these things.

I do believe the uniformisation systemd causes is a good thing, but I absolutely understand that the big scope can be seen as an issue, and I almost fully agree with your last paragraph. I would object to the statement that systemd is not a monolith and is composed of many programs is a moot point: this modularity still means that you can replace individual systemd programs with your own implementations if needs be…

… as long as you provide the expected features / APIs, yes, you are totally forced into this indeed. systemd is a de facto API. It brings / forces standardization at the cost of diversity. It broadens the standardization that comes with UNIX/POSIX and XDG. I'm sure this can be criticized in a few ways: the API design, the scope, the featureset, the way the project is lead…

The alternative to systemd is non-existent standardization and each alternative designs stuff its own way on their side. For the better and for the worse. I can see how systemd can be criticized for when we are in "the better" cases. I personally easily see the worse side where several projects (for instance desktop environments) would each have to implement features that come with systemd. And programs on top of these environments now have to implement APIs of each desktop environment to be well integrated.

This is more work for everyone.

I guess this is a diversity vs efficiency balance to strike and we don't all see it at the same place.

I suppose another alternative would be to have different people working on different implementations that are then grouped in some common "system core" package or set of standards that everyone adopts. I'd probably be happy with that, if this is at all possible.

You're right. But what I take issue with is that systemd authors deliberately decide to go against it. We know because there are other init systems that do follow these design principles much more closely.

Of course, an init system is not trivial, and is a special program that must be given additional permissions over most user space programs. But the problem with systemd is that it's not just an init system. It is a collection of tools that also manages logging, networking, DNS resolution, containers, and a bunch of other system tasks, which, in my opinion, it has no business managing. When you add to this the fact that these programs are all interdependent in some way, and that I can't use e.g. `journald` without systemd itself, it really drives the point that this is an attempt to establish a cohesive and centralized system, rather than rely on a collection of independent but composable tools, most of which already exist. So I get the appeal why some people would prefer this, particularly if they're not already experienced with existing tools, but it's also not a surprise why experienced Linux geeks would scoff at this.

In my experience, systemd doesn't give me anything that I can't do well with other tools. And instead of having the choice to use a tool of my preference for each individual task, I'm forced to use a gargantuan system designed by a single group of people. Whether or not this ultimately makes my life easier, it goes against the primary reason why I choose to use Linux in the first place. If I wanted someone else to make decisions about how I use my computer, I have Windows and macOS for that.

Tangentially, this is also why I have a love-hate relationship with NixOS. As much as I appreciate reproducibility, atomic upgrades and rollbacks, and having a fully declarative system, its authors insist on managing every part of my system with Nix, which is completely insane to me. So, for example, it tries to replace every single package manager in existence, whereas I much prefer using something like `mise` to manage my development environments. Technically, I still can and do that, but it's certainly not the "Nix way".

Interoperability and composability are the core tenets of the Unix philosophy IMO. It's this that allows me to use programs written decades ago together with programs written today, without either tool being aware of each other. In contrast, tools that try to take over my machine forcing their own UIs on me—no matter how supposedly superior they might be—are hostile to my overall computing experience.

Which one(s) would you recommend/suggest?

I felt like systemd was an epiphany. Software doesn't need to a collection of simple tools that do one thing really well. You can have one tool that does everything shittily, the pdf reader of init if you will, and that's systemd. The author went on to do brilliant work with pulseaudio, you know, the whole /dev/dsp everything including sound is a file, oof. Let's make it a weird complex server process, oh, and let's make another sound system after that too.

I was very happy to see Lennart Poelering had joined microsoft to bring his brilliance to windows. I'm sure he's just cranking out masterpiece after masterpiece of design for them. I actually switched from unix to windows after being so inspired the tremendous quality and sensical design of both pulseaudio and systemd. Oh, and both very reliable, simple, and intuitive.

   < something filter step 1|filter step 2|filter step 3