This is the most surprising and interesting part, imo:
> Contributions to `container` are welcomed and encouraged. Please see our main contributing guide for more information.
This is quite unusual for Apple, isn't it? WebKit was basically a hostile fork of KHTML, Darwin has been basically been something they throw parts of over the wall every now and then, etc.
I hope this and other projects Apple has recently put up on GitHub see fruitful collaboration from user-developers.
I'm a F/OSS guy at heart who has reluctantly become a daily Mac user due to corporate constraints that preclude Linux. Over the past couple of years, Apple Silicon has convinced me to use an Apple computer as my main laptop at home (nowadays more comparable, Linux-friendly alternatives seem closer now than when I got my personal MacBook, and I'm still excited for them). This kind of thing seems like a positive change that lets me feel less conflicted.
Anyway, success here could perhaps be part of a virtuous cycle of increasing community collaboration in the way Apple engages with open-source. I imagine a lot of developers, like me, would both personally benefit from this and respect Apple for it.
> WebKit was basically a hostile fork of KHTML
Chromiom is a hostile fork of WebKit. Webkit was a rather polite fork of KHTML, just that they had a team of full time programmers so KHTML couldn't keep up with the upstream requests and gave up since WebKit did a better job anyway.
I personally would LOVE if a corporation did this to any of my open source projects.
And the creator of KHTML is now part of WebKit team at Apple.
Even KDE eventually dropped KHTML in favor of KHTML’s own successor, WebKit-based engines (like QtWebKit and later Qt WebEngine based on Chromium).
A web engine isn’t just software — it needs to keep evolving.
Recognising the value of someone’s work is better than ignoring it and trying to build everything from scratch on your own, Microsoft's Internet Explorer did not last.
Blink is the hostile fork of WebKit. And you would not like if any corporations did this to your Open Source project; on HN alone I see a small army's worth of people who bitch about websites built for Chrome but not Safari. That's how Konquerer users felt back when Apple didn't collaborate downstream, so turnabout is truly fair play.
> That's how Konquerer users felt back when Apple didn't collaborate downstream, so turnabout is truly fair play.
You are rewriting history here. The main KHTML developers were hired by Apple and Konqueror got on with the new engine. There was no fuss and no drama.
The reason why it’s fair play is that the license allows it. Google is no white knight out to avenge the poor KHTML users from 2003.
I think there was some perceived initial concern about the patches provided by Apple to KHTML in so much as they now had to merge a huge amount of code into the project and much of it was (IIRC) lots and lots of ifdef statements.
Yes, but the main issue was the volume and frequency of patches, not that the patches were intentionally hard to upstream (you can always complain about style, though). I don’t have the links handy right now but I remember the discussions amongst the KHTML devs at the time.
Okay. Just make sure nobody searches up the KDE blogs from back then, it might derail your argument.
> Google is no white knight out to avenge the poor KHTML users from 2003.
Nope. They're here to molest your runtime. Portions of are not expected to survive the assault.
Normally, this is where I'd say "us Linux and Mac users should join arms and fight the corporations!" but that bridge has been burning for almost 20 years now. These days I'm quite content with Safari's fate regardless of how cruel it's treated; after all, the license allows it. No fuss, and no drama. Healthy as a horse, honest.
The developers moved on, that’s all, that’s why there was no fork and no momentum behind the original KHTML library. WebKit became quickly the gold standard at the time of the Acid tests, replaced KHTML in most places and nobody looked back. It remained functionally identical, except that it had orders of magnitude more resources than before.
There’s more blood and drama every time there’s a GTK update.
> These days I'm quite content with Safari's fate regardless of how cruel it's treated; after all, the license allows it. No fuss, and no drama.
Well, bitching is not very productive. We can regret a Blink monoculture, but it would have been exactly the same if Chrome kept using WebKit (if anything, that would have been worse), or if they switched to Gecko. The drama with Chrome has nothing to do with who forked whom.
> There was no fuss and no drama.
I didn't write my initial comment here to relitigate this, but you are absolutely the one rewriting history. I remember reading about it because I was a KDE user at the time. But sources are easy to find; there are blog posts and press articles cited in Wikipedia. Here's a sample from one:
> Do you have any idea how hard it is to be merging between two totally different trees when one of them doesn't have any history? That's the situation KDE is in. We created the khtml-cvs list for Apple, they got CVS accounts for KDE CVS. What did we get? We get periodical code bombs in the form of them releasing WebCore. Many of us wanted to even sign NDA's with Apple to at least get access to the history of their internal vcs and be able to be merging the changes incrementally, the way they can right now. Nothing came out of it. They do the very, very minimum required by LGPL.
> And you know what? That's their right. They made a conscious decision about not working with KDE developers. All I'm asking for is that all the clueless people stop talking about the cooperation between Safari/Konqueror developers and how great it is. There's absolutely nothing great about it. In fact "it" doesn't exist. Maybe for Apple - at the very least for their marketing people. Clear?
https://web.archive.org/web/20100529065425/http://www.kdedev...
From another, the very developer they later hired described the same frustrations in more polite language:
> As is somewhat well known, Apple's initial involvement in the open-source project known at KHTML was tense. KHTML developers like Lars were frustrated with Apple's bare-bones commitment to contributing their changes back to the project. "It was hard, and in some cases impossible to pick apart Apple's changes and apply them back to KHTML," he told us. Lars went on to say, "This kind of development is really not what I wanted to do. Developers want to spend their time implementing new features and solving problems, not cherry picking through giant heaps of code for hours at a time."
https://arstechnica.com/gadgets/2007/06/ars-at-wwdc-intervie...
This uncooperative situation persisted for the first 3 or 4 years of the lifetime of Apple's fork, at least.
> The reason why it’s fair play is that the license allows it. Google is no white knight out to avenge the poor KHTML users from 2003.
You're right about this, though.
Anyway, there's no need to deny or erase this in order to defend Apple. Just pointing to other open-source projects they released or worked with in the intervening years, as many other commenters have done in reply to my initial comment, is sufficient!
> And you would not like if any corporations did this to your Open Source project; on HN alone I see a small army's worth of people who bitch about websites built for Chrome but not Safari.
Those are unrelated things.
> WebKit was basically a hostile fork of KHTML...
WebKit has been a fully proper open source project - with open bug tracker, patch review, commit history, etc - since 2005.
Swift has been a similarly open project since 2015.
Timeline-wise, a new high profile open source effort in 2025 checks out.
I find Apple to be very collaborative on OSS - I hacked up a feature I needed in swift-protobuf and over a couple of weeks two Apple engineers and one Google engineer spent a significant amount of time reviewing and helping me out. It was a good result and a great learning experience.
I too am more of a reluctant convert to Mac from Linux. It really does just work most of the time for me in the work context. It allows me to get my job done and not worry because it’s the most supported platform at the office. Shrug. But also the hardware is really really really nice.
I do have a personal MacBook pro that I maxed out (https://gigatexal.blog/pages/new-laptop/new-laptop.html) but I do miss tinkering with my i3 setup and trying out new distos etc. I might get a used thinkpad just for this.
But yeah my Mac personal or work laptop just works and as I get older that’s what I care about more.
Going to try out this container binary from them. Looks interesting.
If you’re looking for a hobby computer, Framework’s laptops are a lot of fun. There’s something about a machine that’s so intentionally designed to be opened up and tinkered with - it’s not my daily driver, but it’s my go to for silly projects now.
It's not that surprising. Much of Swift and its frameworks are contributed by the open source community.
That's true, but I always thought of Swift as exceptional in this because Swift is a programming language, and this has become the norm for programming languages in my lifetime.
If my biases are already outdated, I'm happy to learn that. Either way, my hopes are the same. :)
Jai has been one exception I can think of here. It hasn’t been publicly released yet, either (you can email/request pre-release access, though)
Apple has a lot of good stuff out there doesn't it? Aren't llvm and cups theirs more or less?
They gave up on CUPS, which was left in limbo for way too long. Now it’s been forked, but I don’t know how successful that fork is.
They took over LLVM by hiring Chris Lattner. It was still a significant investment and they keep pouring resources into it for a long while before it got really widespread adoption. And yes, that project is still going.
Tbf if you look at all the printer drivers out there. You know why they dropped it. PPD is also not a good standard. I mean it would not be too bad, but what printer developers do to make their shitty printers work… (like adding binary command filters and stuff, binary tray mgmt extensions…) xerox for one example ships really strange drivers. Most of the time I use their windows ppd and strip the binary stuff.
CUPS is still the only print system macOS has. Apple never dropped it in the sense of ceasing to use it! "They dropped it" only in the sense of more or less ceasing to maintain it-- there was only one commit in the course of about a year, and no patches accepted from outside contributors at that time-- until it eventually had to be forked.
The name stands for Common Unix Printing System, and Apple CUPS ceased to meaningfully be that after its author left the company. But Apple still uses CUPS in their operating systems!
cups seems to be properly maintained now https://github.com/openprinting/cups
Yes, that’s the fork I mentioned. The last version of Apple CUPS seems to be 3 years old https://www.cups.org/ .
Apple is heavily involved in llvm, but so are a several other companies. Most prominently Google, which contributes a huge amount, and much of testing infrastructure. But also Sony and SiFive and others as well.
It’s all very corporate, but also widely distributed and widely owned.
> I'm a F/OSS guy at heart who has reluctantly become a daily Mac user due to corporate constraints that preclude Linux
I suspect this move was designed to stop losing people like you to WSL.
As a long-time Linux user, I can confidently say that the experience of using a M1 Pro is significantly superior to WSL on Windows!
I can happily use my Mac as my primary machine without much hassle, just like I would often do with WSL.
I'm in that camp— I was an Intel Mac user for a decade across three different laptops, and switched to WSL about six years ago. Haven't strongly considered returning.
> I suspect this move was designed to stop losing people like you to WSL.
I am also thinking the same, Docker desktop experience was not that great at least on Intel Macs
Since this is touching Linux, and Linux is copy left, they _have_ to do this.
In addition to the other comments about the fact that this wasn't forced to adopt the GPL, even if it were, there's nothing in the license that forces you to work with the community to take contributions from the public. You can have an entirely closed development process, take no feedback, accept no patches, and release no source code until specifically asked to do so.
They don't have to do literally any of this.
Touching Linux would not be enough. It would have to be a derivative work, which this is (probably?) not.
Besides, I think OP wasn't talking about licenses; Apple has a lot of software under FOSS licenses. But usually, with their open-source projects, they reject most incoming contributions and don't really foster a community for them.
> derivative work
Or distributing builds of something that statically links to it. (Which some would argue creates a derivative work.)
If the license of this project were determined by obligations to the Linux kernel, it would be GPLv2, not Apache License 2.0!
The comment was about them welcoming contributions, not making it open source.