Hacker News new | past | comments | ask | show | jobs | submit login
Apple Open Source (opensource.apple.com)
216 points by lladnar 40 days ago | hide | past | favorite | 212 comments



This is interesting from the external perspective, but let me provide the internal one: Employees are prohibited from so much as _thinking_ open source for anything not directly managed or maintained by Apple. Swift is one thing, but suppose on your own time, you had OSS interests. It was made abundantly clear to we lowly SWEs that _any_ perceived OSS participation - so much as commenting on a GitHub issue - without approval would be cause for immediate termination. Said approval requires the unanimous approval of multiple SVPs, including Federighi and Schiller themselves. IIRC the number of Apple employees given such arrangements was in the low 50s last I checked.


If true, the only question I have is "why?". Assuming the OSS projects aren't a conflict of interest, there is zero reason to block people in their own free time from working on other projects. Blocking any form of participation, even non-code contributions is extreme.

This sounds similar to Amazon policies I'd read on HN, but I can't remember if they were barring OSS activity or claiming ownership of.

As a Red Hatter I find this mindset mind-boggling, but I'm heavily biased and on the complete opposite side of the spectrum. There's always a balance to be struck around policy depending on the org/industry/etc, but a blanket "no" is ridiculous.


I remember this coming up in a blog post by the creator of Shellcheck a while back [0] and being discussed here [1].

One reason given is this:

> Assuming the OSS projects aren't a conflict of interest

Apple is so secretive even internally that you can never guarantee whatever you're working on in your free time does not conflict what someone at Apple is working on secretly.

[0]: https://www.vidarholen.net/contents/blog/?p=859

[1]: https://news.ycombinator.com/item?id=22279585


Sorry for the low-effort reply, but I think "because they can" is all the explanation that is needed.

It's easy to demonstrate diligence and commitment by forbidding, much easier than showing how good you are at your job by allowing instead. Which would demonstrate what? Wisdom and balanced judgement perhaps? Great qualities, but difficult to show off. Forbidding is the low-hanging fruit of appearing strong.


Presumably though, this policy makes it at least somewhat harder to acquire engineering talent? There have to be engineers who don’t want to work at Apple because of these restrictions.


It works the other way around too. No one knows which Apple employees to poach.


I, anyway, have never been tempted to work there.


That's not an Amazon policy. We have to take a 1 hour or so training course to participate in amazon-owned things on github and that's pretty much it. Basically zero rules around participating in our free time afaik.



Looks like that was only within the Amazon Game Studios org. I've never heard of any policy like that within AWS or the retail side of things.


There were certainly issues like this when I joined Amazon in 2005 until I left in 2010. For years before I joined, I was the primary maintainer of an open source tool that almost everyone in the Python community had heard of at the time (python.org linked to it). Amazon really wanted me to abandon it (to my knowledge, they did not use it). It alarmed me so much that I had it written into the offer letter that I could continue to be the maintainer for the project. They added into the letter that I could not contribute to any other project. I was also lined up to speak about the project at PyCon (lined up before taking the job, PyCon was after starting). I didn't think to mention that until after I started. When I did, my manager dug into the process required to get approval... spend a month going through Amazon PR training full time (i.e., not doing the job I was hired for) and, at the end of the month, the PR folks would determine if I would be allowed to speak. At my manager's suggestion, I just went to PyCon and talked "with" folks about the tool. It just happened that it was easier to talk "with" folks using a mic and some slides that didn't mention Amazon anywhere.

The general attitude I encountered inside the company was either feeling defeated about it or feeling that Amazon had a competitive advantage because they were one of the few companies shrewd enough to take without giving back.

S3 and EC2 were released while I was there, and that started to change things. Suddenly motives to interoperate with open source were appearing. Sometimes that even meant giving back improvements that made projects fit the AWS ecosystem better. Their customers were also now software developers, many of whom would not welcome their explicitly greedy posture. That opening up was just starting when I left so I don't have a very deep view of it.

A funny thing happened after I left. I was working on an open source project created by my new employer that ended up being popular for a while in teaching distributed systems to undergrads. It was a great "gateway drug" for a new-ish AWS service. The GM of that service asked me to come to their very first AWS conference to talk about the project. I asked if I should mention that I worked at Amazon previously. The GM didn't just say yes, they introduced me as a previous Amazon employee - they very much wanted to be seen as aligned with and supporting open source. They also gave me AWS credits to hand out when I spoke about the project at PyCon and elsewhere.


> there is zero reason to block people in their own free time

That's the thing - people don't have "free time". Most employment contracts are actually enslavement when it comes to IP. That's why corporations lobby governments to stop workers going B2B.


>Most employment contracts are actually enslavement when it comes to IP

Note this is a mostly US perspective, e.g. AFAIK in Switzerland what you do in your own time, and with your own equipment is entirely your own under Federal law. And that seems totally fair.

Of course if you steal code or ideas from your employer, then things get a bit more grey.


Do you have relevant sources for this? AFAIK some Google Switzerland employees are still bound by this stupid rule (what you do in your free time, with your personal device, is still Google's property), but I would love to be proven wrong.


> Most employment contracts are actually enslavement when it comes to IP.

That's a very one-sided take. (Not commenting on Apple's policy, just commenting generally.) This great article explains why IP contracts are the way they are: https://www.joelonsoftware.com/2016/12/09/developers-side-pr...


US employment contracts. The US is deliberately hell for rank and file. For "non-exempt" (hourly) workers it is worse than most of us can imagine.


Is that even legal? I’m not sure it would stand a leg in the EU.


But most Apple employees, especially engineers, are not in the EU


High time for them to work on changing their laws then.


I've seen people with promising OSS projects start working for Apple and having to abandon their projects. I think this is sad and such a net negative for the open source world, without any benefits to Apple (aside from their employees focusing on their work at Apple, maybe).


When you think about it. This attitude towards employees is just a reflection of company culture, let me explain.

Everyone talks about how the App Store is a "walled garden" but when you step back, all of Apple is a "walled garden" in a sense. Apple is in many ways like Disney when you think about it, they are masters of their respective domains, they have intense attention to detail, and they attempt to control and curate the experience for you. This is not necessarily a bad thing in all respects, in fact it's a very good thing, the whole reason I go to Disneyland versus Bush Gardens is that I want that impeccable attention to detail. Likewise I have an iPhone and I bought it precisely because of the attention to detail and the consistent experience.

But while this need for control is a huge advantage in some ares, it's a huge disadvantage in other areas, namely the App Store. We have all heard the grievances with apps getting pulled and this again is reflective of the walled garden. Out house, our rules, no exceptions.

But it's really interesting to see this culture extend to the employees themselves. Apple not letting employees contribute to OSS is again very reflective of the "walled garden" approach. Everyone else's employees work during the day and do other stuff on the side, but Apple employees are 100% inside Apple.

And this is a real issue for Apple, because the thing that makes their hardware so good is the same thing that makes all their software less than ideal to work with, to put it mildly. I think the best indicator of this right now is WebKit and Safari. Chrome and Firefox are light years ahead of Safari in terms of implementing new web technologies. At it's core, this is a problem with the culture at Apple of letting people in, and until they fix that culture or make a concerted effort to improve it, any attempt at them trying OSS is going to fall flat.

Apple needs to focus on diversifying its leadership and bring in new ideas. They could learn a thing or two about API's and Software from a company like Stripe.


Very interesting perspective, and I totally agree! I'm big into the Apple ecosystem, but their software issues are definitively a problem.


That would explain the weird experience of having your open software used in Apple products — no one from the company ever talks to you. I'm a bit baffled how they deal with upstream bugs with this mentality. Not my problem, of course. Just weird.


I'm a bit baffled how they deal with upstream bugs with this mentality

Probably the same way they deal with support: refer users upstream [1].

[1] https://daniel.haxx.se/blog/2021/11/18/free-apple-support/


There's the classic `tail -f` bug where they didnt upstream the fix, but on their own open source release have an #ifdef APPLE or something to that effect.

Link to Bryan Cantrill's humerus talk. https://www.youtube.com/watch?v=vm1GJMp0QN4#t=41m18s


thanks for the link! that was fantastic


A bit late with this reply, but the answer is: Make patches internally, to work around the problematic areas. Often done to avoid the legal necessity to contribute it back upstream. For example, hook code at runtime to jump out to Apple specific changes that are now not part of the OSS codebase directly.


Even Swift is only nominally open source. Apple maintains private forks of all the projects in the Swift umbrella, and the releases for iOS/macOS development come from those, not the public source.


I’ve seen at least one person from the Swift team involved in the Rust project on github - does the Swift team have special privileges in this case?


Are you sure that person currently works on Swift? There have been a number of people, including a few public faces, who have switched jobs from Rust to Swift and vice versa.


Nope the OP is just terribly wrong.


It would be nice if you could elaborate how are they terribly wrong?


Some projects have been approved and have internal "champions" of the project and you can get approval more easily for those projects since it's not a one-off, and a non-VP has been granted authority to approve upstreaming patches to the project they champion.


It's largely a waste of time due to the extreme anti corp bias on HN, but the idea that Apple employees don't value or contribute to OS is extremely misleading.


I'm not reading that Apple employees don't value OS in OP's message, I'm reading that Apple is banning OS contributions, unless special exemptions are given, and that it is hard to get those.

Is OP wrong in his description of Apple's rules and permission wrt OS?


That's a correct summary. This is the reason why people who join Apple suddenly abandon their OSS projects.

It's worth noting there was a huge debate internally about this around the time I left, with many people dissatisfied with the policy.


>It's largely a waste of time due to the extreme anti corp bias on HN

I like this. Sums up a lot of things about HN.


Then does the SRE team contribute to Apache open source projects and Kubernetes, before this announcement?


It's possible if Apple-the-organisation is contributing/driving back to some project, under the corporate entity. See WebKit for example.

However an individual employee could not just decide they want to submit some patches to Apache Whatever on their own time.


Why is Kubernetes up there? Webkit and Swift I get, they are two major projects started and maintained by Apple people. But I can't find Apple mentioned a single time if I ctrl+f in the the Kubernetes Wikipedia article. Nor has it apparently been started by Apple employees.

On the other hand, I wonder why they haven't included LLVM. It has been led for a long time by Apple employees, and even if you look at the top 10 contributors on Github from last year, you'll find two Apple employees, so there is continued commitment (maybe there are more, I couldn't identify employers for all of them). Edit: seems that the frontpage only shows a selection. LLVM is present if you click the "View all projects" link.


They do contribute a decent bit to Kubernetes per https://k8s.devstats.cncf.io/d/9/companies-table?orgId=1, but they’re still prettyyyyyyy low on the list (31 as of this writing).


They're using opensource.apple.com it as a recruiting tool. Every big company embellishes things when recruiting.


You can tell their 'contributions' are not in good faith if you follow any downstream project that actually tries to build (or even just build against) their open-source code.

Lots of it requires proprietary tools to build, source releases lag way behind their binary counterparts, sources and headers sometimes just disappear with new versions, lots of downstream patches and hacks are required to get things working, etc.

Every project that actually tries to build Darwin (the open-source components of the OS) into a usable (headless) OS has foundered, and often the death blow is Apple just ceasing to release required sources. Whenever one such project is kinda working it seems to be just barely getting by.


It's not exactly much when DaoCloud Network Technologies Co. Ltd., a company which doesn't even have a website, beats them by almost 2x. For them to put it above WebKit - an incredibly important technology which they did build - is extremely bizarre. It does give the impression that this is a recruiting tool, and that they're trading on Kubernetes' name recognition.


“DaoCloud Network Technologies Co. Ltd.” is a translation from their Chinese name (道客网络科技有限). They do have a website: https://www.daocloud.io/https://www.daocloud.io/about


Ahhh, mea culpa, thanks for the correction. I can't edit my comment any longer - it looks like HN limits edits to a ~2hr window – but I would have if I could.


> Webkit and Swift I get, they are two major projects started and maintained by Apple people

True, though I would add that WebKit is a fork of KHTML and KJS, KDE's browser and JavaScript engine. Apple had to keep distributing the source code since KHTML and KJS are LGPL.


And Apple made no effort whatsoever to coordinate with KDE upstream IIRC. It was not the good kind of fork


Chrome is not just based on a Webkit fork, it's also compiled with Apple's open sourced Clang compiler.


llvm is there towards the bottom

https://opensource.apple.com/projects/


Why not? Just runnning the IT infrastructure for 140k employees is likely going to tread deep into k8 land.

There is also iCloud.


If someone just uses open source software, they can add it to their opensource.example.com website?

It used to be that the page should list things they're maintainers of..


Webkit was not started by Apple, please don't erase the original developers.


WebKit was started by Apple. You're thinking of KHTML/KJS.

And Apple made such significant changes at the early days that the two projects should be thought of as not having all that much of a relationship.


That's a dangerous line of thinking. The major change they made originally was decoupling it from Qt.


This is a typical case of openwashing. Just like Microsoft, Apple only opensources what they are legally obliged to or sideprojects they don't care about at all for business. And just last year, they silently stopped dedicating resources to CUPS (the printing server). The site says:

> You can access the source code for our operating systems and developer tools

Yes of course please send me the entire code for MacOS + XCode. I'm waiting! Fuck you hypocritical liars.


Apple would never allow the 3 interns working on Xcode to open source it, they couldn’t stand the embarrassment.


Microsoft open sourced "Service Fabric" that " Azure SQL Database, Azure Cosmos DB, Cortana, Microsoft Power BI, Microsoft Intune, Azure Event Hubs, Azure IoT Hub, Dynamics 365, Skype for Business and other" run on. Also .net.


The creator of CUPS was employed by Apple, to work on CUPS. He left, and doesn't work on CUPS anymore. It's not some cloak-and-dagger thing.


The creator of CUPS does still work on CUPS. He had to fork the repo in order to keep working on CUPS after Apple didn't accept any patches and added only a single commit to CUPS in the course of an entire year.

his fork: https://github.com/OpenPrinting/cups

Cloak and dagger? no

Terrible stewardship of an open-source project? yes

Surprising, given Apple's history? not at all


Apple moved to the Internet Printing Protocol (which they brand as AirPrint), just as Google did (after they killed Google Cloud Print) and Microsoft (branded as Universal Print).

The last thing Apple did with CUPS is add functionality to allow legacy printers that don't natively support IPP to function as an IPP printer.

>Products using the Internet Printing Protocol include CUPS (which is part of Apple macOS and many BSD and Linux distributions and is the reference implementation for most versions of IPP

https://en.wikipedia.org/wiki/Internet_Printing_Protocol

Going forward, the Printer Working Group is in charge of IPP, and the creator of CUPS now works for them.

https://www.pwg.org/ipp/



Oh wow. I literally visited this page last week and it was the same layout that it’s been for years. I was wondering when they’d update it to be more Apple-esque


I mean, like, congratulations to whomever it is that actually worked to try to make the worlds most vast & advanced computer empire seem like anything other than a insular, dark, consumer-supplying fixer.

I'm glad there's the bare minimum of sticks to try to rub together to give the impression Apple gives the faintest most minimal flying fuck about any compute other than Apple computing, that they see any value in a bigger computing ecosystem. Apple is not at all a company that gives any impressions that they care about anyone but those that fall within the light of their empire. When presented with challenges about what restraints they impose on computing, the default response seems to be, there are other platforms available for anyone who cares about choice or empowerment: here in Apple-land, our vassals are secure, served adequately. Trust us. All else is tertiary at best.

I still think the impression being given off here is pretty radically fantastically unrealistic. As far as I have heard, one of the primary terms of employment at Apple is that you basically have to give up yourself wholly to Apple. Your blog has to die, your personal open source projects are all dead now, you are now, wholly Apple, and anything you do must be Apple's. This is just the opening terms of un-openness that greet you if you want to join Apple. Almost nothing about this company speaks to collaboration or cooperation or general betterment of computing. Apple thrives off the futility of computing. Their whole essence is that of savior, making software for their following that serves them well, amid a world of grayer concerns and wider difficulty. The idea that open computing could be competitive, could be helpful in the planet: it's antithetical to the premise of the High Consumerism that is Apples most core being.


> Apple is not at all a company that gives any impressions that they care about anyone but those that fall within the light of their empire

Based on some of the experiences I've heard from iOS devs, I'm not even slightly convinced they care at all about most of the people in their empire either (unless said empire is excluding non-apple devs).


> I'm not even slightly convinced they care at all about most of the people in their empire either (unless said empire is excluding non-apple devs)

I'm not quite sure they care about Apple devs either: https://news.ycombinator.com/item?id=29493643


Apple engineers recently started to contribute bug reports, root cause analysis and even fixes to solve compatibility issues with their hardware and software platforms via a shared github account: https://github.com/Developer-Ecosystem-Engineering

For instance for NumPy:

https://github.com/numpy/numpy/pull/19926

Although it's weird to interact with such an anonymous account in github discussions, it is very welcomed by the maintainers of those projects because debugging without assistance those low-level platform specific issues was a significant maintenance burden.


Wow, in that bug report I can barely understand what he's talking about. I guess I really do have a long way to go. Thank God Apple is contributing such high caliber contributions to open source. This is why I use MBP.


Doesn't GitHub require 1-person-1-account? I hope that does not cause trouble.



Did you also know that it actually spawns the `sjeng` command line binary as an NSTask and attaches to stdin and stdout. So basically it’s just a fancy GUI around the Text based UI :)


Only 12 projects. I thought my CV was poor.


Also, how come Swift has not taken off outside of Apple?


My personal opinion is because Swift has turned into an "us too" language. There's a large rush for all popular language ecosystems to rush to whatever trendy development exists in language design now days to retain the momentum of community. I write/maintain a decent amount of code in Swift these days. I'm proficient in some parts of it, clueless in others. Like Kotlin, and Javascript, and even Python to some degree (I do a lot of Kotlin and Python too), these multi paradigm languages are sort of a "use it however you want." There's no unifying simplicity in them. So it becomes a race to the bottom of utility. Why use Swift, when it looks and feels like so many other languages, and when it's clear the rate of the changes in it will primarily benefit Apple?

To be clear, I don't hate Swift at all, I like some bits of it, it's just that there's no real draw for me to play with out side of the Apple eco system. If Apple made it so that I could use it write Android apps with it (kinda like Dart is supposed to be), I would be much more excited about. If Swift was dedicated to a small set of unifying principles (kinda like Elixir), I could get more excited about it.


For the record, Kotlin was open sourced Feb. 13th, 2012 [1]. Swift was open sourced Dec. 3rd, 2015 [2]. So while the first commits happened just a few months apart [3, 4] and these languages may have shared similar influences, Kotlin predates Swift by almost four years in the open. Perhaps their ideas simply were in the air ten years ago, but I think it would be unfair to insinuate that either language was in a "rush to whatever trendy development exists in language design".

[1]: https://blog.jetbrains.com/kotlin/2012/02/kotlin-goes-open-s...

[2]: https://developer.apple.com/swift/blog/?id=34

[3]: https://github.com/JetBrains/kotlin/commit/369b1974782b821e4...

[4]: https://github.com/apple/swift/commit/afc81c1855bf711315b8e5...


I was not trying to imply that they stole from each other.

Kotlin may have been around longer, but it did not enjoy the early momentum and energy that was granted because of Apple's energetic adoption and marketing. JetBrains didn't have the early resources to dump into Kotlin at first like Apple gave to Swift. In fact, I would posit, that if Swift had not gotten a giant kick off from Apple, Google may have never felt so compelled to support Kotlin like they did. They may have been fine "just do it with Java, or you can use JetBrains stuff if you want" indifferent attitude that existed for much of the early life of Kotlin.

Both languages want to remain objecty. But have added "systems" features. And are more functional. And more asyncish. And more actorish. More saftey-ish. So on and so forth.


Again, I would put it very differently. Despite having a fraction of the audience and resources of a multi-trillion-dollar company, and despite a long list of competing languages, JetBrains had the foresight to invest and innovate in the language design space. I think it's a testament to Kotlin's ergonomics, unrivaled tooling-support and interoperability with Java's ecosystem that it became so widely popular among the Android community. Amidst Kotlin's growing popularity and mounting legal pressure from Oracle, Google realized they could no longer ignore it and finally adopted their Kotlin-first strategy in 2019. [1]

[1]: https://developer.android.com/kotlin/first


Yeah Google has never said it but I think it's widely assumed Google pushed Kotlin as a hedge during their never-ending Java lawsuit with Oracle.


Or it became so “widely popular” (hardly outside android circles) because android java is capped at around java 8 features, while we are at 17.


There’s a few reasons, but mostly is due to economics and the way Apple builds its own software.

Swift came out of the iOS side of the company, and was sponsored to make writing iOS apps easier. It was therefore constrained to fit into a particular shape; in particular, Objective-C compatibility was a must have. Many of the frameworks and libraries on iOS/macOS are implemented in Objective-C including “std” libraries like Foundation.

When building Swift for Linux/Windows, there isn’t an Objective-C ecosystem, and rather than introduce one, instead the language just doesn’t have support for that. As a result, the “std” libraries are a complete rewrite of the libraries available on macOS. Even being able to include Posix basics used a different library name; Darwin vs GlibC. [There was a long battle to try and get a meta import of LibC which would import the right one on different platforms.]

So there are really two dialects of the language: Apple Swift and Linux/Windows Swift. They share the same overall feel but is like the difference between Diesel and Petrol/Gas. Same overall outcome, different completely under the hood.

Two other reasons exist; firstly, the internal builds are a fork of the open source project, so when a new feature lands on an iOS device, code and libraries are written to support that (eg SwiftUI) and nothing related to that fork lands until after Apple have announced it. What that means is you get giant blobs of diffs on an annual basis; in some cases, reverting bugs that have been fixed already in the open source world (because the internal version was forked six months previously).

The other reason is that Swift depends on a forked version of llvm/clang, to the extent where you have to install those to be able to compile Swift programs. Many upstream distributions already ship their own clang, which is essentially incompatible with Swift, but they want to follow their philosophy of only one version of a library (and don’t want to replace their own version with a Swift specific one).

So, Swift on iOS is a primary platform, and if you are writing iOS apps is the standard way. Every other platform is a second class citizen and software project management at Apple is not well suited to an open source workflow; since the iOS team are calling the shots on swift (and paying for most of it, to be fair) then the language evolves for their benefit primarily and then others as a side effect.


Even though it was obviously beta, there was a lot of early churn in the language and libraries. Some substantive, some trivial. And even in later versions, they like doing October surprises with language features, despite being open in development (SwiftUI and all it’s crazy dsl support came outta nowhere)

But the Linux story was garbage through v5, with half the standard library being unimplemented, and you getting to find out only at runtime.

Also, swift on Linux was (is) still just “here’s a tarball, dump it somewhere” or build from source.

That and the fact that static binaries aren’t a thing without a lot of work, if at all, means you have to ship a 2gb runtime to do anything — which sucks for casual tools.

I love the language but it feels like a bad time anywhere but on Darwin


Perhaps because everything else that Apple does screams "WALLED GARDEN" so the world is now wary af.


There are so many languages to choose from that don't take off outside their niche, why would Swift be different?

From an outsider's perspective, Swift is an attempt to replace ObjC as the "macOS/iOS platform language" with something that feels a bit more '21st century' (for better or worse), so it plays the same role as Kotlin on the Android platform.

IMHO a better solution would have been to provide more "language-interop-friendly" C-API wrappers for high level macOS framework APIs, so that it's easier to write macOS and iOS applications in all sorts of languages (the same applies to Android btw). But the NIH seems to be strong at Apple, so Swift it was instead.


  > IMHO a better solution would have been to provide more "language-interop-friendly" C-API wrappers for high level macOS framework APIs, so that it's easier to write macOS and iOS applications in all sorts of languages
that was arguably easier with obj-c already, and had java, then ruby and python [1] lnguage interops but alas were not popular...

[1] https://developer.apple.com/library/archive/documentation/Co...


I wish I could use it in more places. It checks most of my boxes and I feel reasonably proficient in it, so I would love if I could it in place of say C# on Windows or in place of C++ or Rust for cross platform desktop development.

Swift is also the bulk of what I write for my day job, and it's always nice to not have to allocate mental resources to the differences between languages when trying to work on personal projects in one's off-time. It's so nice to just sit down and just start writing code without having to spend a ton of time googling "how to do X in Y language".


I would imagine the churn is a big killer and lack of decent documentation on the current version. Apple cannot even keep their example code for their platform up to date. If you are on the Apple platform you have to deal with it, but there are other, stronger ecosystems for other language on other platforms.


Apple documentation has been like this for years, and its not even limited to swift.


I feel like the lengthy focus on the Swift for Tensorflow project by some of the key Swift figureheads (including Chris Lattner himself) slowed Swift done a lot. SFT was eventually scrapped, and I can’t help but wonder where the language would have been if those minds would have focused on things like landing async/await & ABI stability earlier and working on other new language features.


Unless you're making iphone apps there are much better languages for nearly every use case that are already heavily adopted


Why would you learn it if you aren't targeting apple users.


Because it is a really, really good language? It's easily the best language I've used, and I've used many.


Its in the Java, C# family of languages, where you can do pretty powerful things without the complexity of the likes of C++ and (now Rust) with a very good performance.

And when you take the family Swift is in, (now also with Kotlin), i consider it the best language over its peers not only given the design, but the fact that being AOT compiled from the start it's of great value.

Having said that, i feel inclined to invert the question as, why i would not want to use and learn it?

In my experience at least, a lot of IT folks, just don't have the mental energy for the likes of C++ and Rust, but can peak at a language like Java which can already be complex enough.

For instance, i deal mostly with C++ all day, and i don't think i would choose it if i were to create an application with buttons, multi-media, etc.. Nor Rust(same problem as C++) or Go(poor design for that goal). Given there's a language like Swift which combines the design and speed/efficiency to create such a thing.

If i were to create a backend service for instance, i would take Go into consideration, and probably in that case it would be a better fit than Swift or Rust or C++..

So its about being the right tool for the job.


I'd dispute that you can achieve high performance in Swift without paying a similar Rust/C++ complexity cost. You can write high-level GUI code that is relatively straightforward, but if you are about speed and memory usage, there is a lot of intricate knowledge you need about what things to do and which to avoid.


Of course, if you want a very efficient application, you are completely right. But the thing is that with Swift you can get a Java like performance (which is pretty good) out-of-the-box even while paying the ref-counting penalty, without the Java memory penalty (it has a low memory footprint) and without having to run it all with a external VM.

Of course, if you want to catch-up with the average speed of C++ you will need some effort, but knowing that it will be pretty fast without much effort and without all the other penalties is reassuring.


million dollar question right here


The same reason as Objective-C did not took off outside NeXT/Apple, you just get the bare bones compiler without the ecosystem.


When Swift was released, it was not open source. At the moment it was open sourced, Swift was not in the news anymore and I remember thinking "ok, whatever".

I wonder if this late open sourcing contributed to this.

And yes, from the outside, it seems very Apple oriented. For any use case outside Apple there seems to be a (more?) suitable language.


Last time I looked, it didn't have a stable way to export a C-compatible ABI for FFI. Unless the majority of your project is in Swift, or there is are bridges for the project's other languages, interop with existing code can awkward or expensive.


I'm curious why Mach/Darwin/XNU is entirely absent from that page.



Hey, how come nobody has used webkit instead of chrome as the basis for an alternate browser.


Chrome and friends are technically children of WebKit. WebKit actually used to be the backend for Chrome, but forked it into a new engine called Blink (8?!? years ago, I didn't think Blink was that old).


We are using it for Orion browser, currently in beta. Very grateful for WebKit being open-source.

https://browser.kagi.com



For completeness sake, anything on iOS needs to be (App Store guidelines) actually Safari under the hood, hence WebKit. That's why there are so many iOS browsers being WebKit.



If I remember right, Midori has moved to Chromium.


They did. It's called Chrome.


Many have done and still do. In fact its about the only alternative there is if you don't want to be another Chromium variant.


Is gecko a joke to you? Though IIRC it's harder to embed than CEF.

I wonder how servo does these days: https://servo.org/


Well, chrome is based on webkit, so all of those alternate browsers are based on webkit.


And WebKit is based on KHTML, so in the end it all comes from KDE


All browsers on iOS are based on WebKit. It’s an Apple requirement.


That’s not exactly true. They’re not based on Safari, they ARE Safari. The browser maker controls the chrome and can add some kids of features (bookmark/history sync, password management/etc.) but they can’t modify the rendering engine outside of any hooks Apple provides them.

It’s not like when Google forked WebKit to make Chrome on the desktop and could truly modify it. On iOS you can’t add new tags or syntax, as a simple example.


It is a common misconception. Browser != rendering engine. It takes tremendous effort to build an iOS browser even when you have WebKit as given as you need to build every single browser feature from scratch. "Open in new tab"? "Favorites"? "Download file"? "Switch tabs"? "Find on page"? All of them need to be built. I know because we are building one.

Chrome on iOS can do pretty much everything it needs to do - settings, telemetry, sync, any kind of custom browser chrome and features and is a _very_ different browser than Safari in many important aspects. For a few that particularly matter to user - consistency of web page rendering, performance and battery life - the user is actually better off as they get a rendering engine built by the phone manufacturer.


> the user is actually better off as they get a rendering engine built by the phone manufacturer

But also worse off, because features like WebGL2 are released literally 5 years after other browsers supported them.


It is a balance you have to strike. The benefits are very strong IMO.


That makes them WebKit, not Safari; they share the engine, not the chrome.


Most of the "lightweight" alternative browsers are. For example Qutebrowser.


Looking at the logos and naming of the OS projects by Apple, I must say that it is weird how consumer facing and polished Apple is.

Instead of hack-y names, that consists of but not limited to sci-fi reference, generic names etc., they have corporate-like names like WebKit, ResearchKit, CareKit, etc.

So weird.

______

Also, TIL there is something called Objective-C++.


What about all the other Swift packages like Swift Algorithms, Collections, Numerics etc?


It's on their Github, which is linked on https://opensource.apple.com/projects/swift/


Yes, I was hoping they would be showcased on this new site?


It's a real desert.


It's clearly shows Apple doesn't support Open Source. So few projects. It's embarrassing for the company which sprout out of an Open Source project. For those who don't know, MacOS is a fork of FreeBSD.


Careful with that assertion. macOS is a derivative of NextStep, which is a derivative of 4.4BSD which also spawned FreeBSD and NetBSD. That makes macOS and FreeBSD cousins at best. See https://en.wikipedia.org/wiki/Unix-like


macOS is absolutely not a FreeBSD fork, but there are lots of bits and pieces in current macOS that are direct derivatives of FreeBSD code, including kernel code, libc and lots of userland stuff.

https://developer.apple.com/library/archive/documentation/Da...

"The BSD portion of the OS X kernel is derived primarily from FreeBSD, a version of 4.4BSD that offers advanced networking, performance, security, and compatibility features."


That was decades ago. Since then Apple went their own way. Anything of significance has been rewritten or mothballed as legacy baggage. Their open-source efforts were left to wither and die. It's been 14 years since Apple got scared of GPL3 and abandoned everything GNU-related.


If FreeBSDers want to complain they should have used the GPL.


It is -because- Apple is opposed to Open Source that they are unable to even ship a version of bash from the past 10 years out of fear of the big bad GPLv3 licensing might make them actually allow public auditing of their proprietary OS.

The Apple commitment to Open Source is mostly one direction and largely limited to cased where they have no legal choice such as GPL. They allow some contributions to happen to appease Apple engineers they want to retain, but as a whole Apple is fundamentally committed to walled gardens.

https://github.com/apple-oss-distributions/bash/tree/bash-12...


>out of fear of the big bad GPLv3 licensing might make them actually allow public auditing of their proprietary OS.

Or because, you know, they make money selling that OS. And they understandably have no desire to make the entire thing GPLv3. And they also have countless contractual obligations to other vendors whose closed-source code is also bundled in OSX.

I find this attitude kind of troubling around here when every other day there's some "open source" project that has had to change licensing because insert cloud provider is stealing their lunch making it impossible for them to make a living. It turns out that someone has to pay the bills, and giving all of your software away isn't a great way to do that. Outside of Redhat, barely anyone has figured out how to make a business out of giving away software, and I'd argue the sale to IBM shows that even Redhat saw the gorilla that was AWS standing in the corner and decided it was time to throw in the towel.


I open source everything I legally can.

People pay me for custom advice and integration of otherwise generic publicly available work. That public work also is what gives me the credibility to get gigs I otherwise never could. Others can go make money offering consulting based on my work if they want. I hope they do! There is no shortage of companies in need of consultants to unblock them in niche areas.

It is kind of the "paid support" model, and it works well for a lot of open source projects whose creators actively market themselves as the defacto subject matter experts offering support.

Likewise when I have worked for big companies and am having trouble or need a feature from an open source project I use my elective budget to pay project authors to implement what I need. Bailed me out many times in ways I would have never seen from a big tech firm like Apple.

Let's be honest though. The people that love the Apple brand enough to use Safari in spite of all the shortcomings don't use it because WebKit is open source or not. They use it because Apple supports it and they trust the brand.

Apple could open source everything and still be a top player for the foreseeable future.

They just want to be -the- top player making a little bit -more- money by monopolizing control of a major software platform even if it means developers have a shitter experience being stuck with decade old software they can't easily update in a safe way.


I use WebKit because it’s good enough and syncs passwords across iOS and multiple macs seamlessly and without a bullshit subscription for a password manager.


It's a single userland component; why would it make the rest of the system GPLv3? I mean, Linux distros ship BASH without it somehow infecting the rest of the system, why would Darwin be any different?


The real reason isn't that the system would be GPLv3. The real reason is that GPLv3 includes a patent grant clause, which many companies (Apple included) are very worried about applying to them if they ship GPLv3 code, therefore they don't.


Afaik GPLv3 is "infectious". If you use a v3 licensed component, you basically have to license the entire codebase as v3 to be in compliance. This is the reason why Apple only ship GPLv2 and MIT/BSD licensed components


Is bash integrated into xcode or something, or just sit as a standalone binary?


Ships with the base OS.


That's not how it works. An operating system does not become a derivative work by shipping with a program.


Does that count for GPLv3 purposes though?


Ubuntu and Fedora ship GPLv3 bash with a GPLv2 kernel (Linux), without relicensing it, so empirically not.


I am just going to say that it does not matter if the software is open or closed source. The people are going to pirate the thing, I mean like there are projects on linux that literally make the posibility of having a VM of MAC really easy.

I mean like I kind of understand the point that you are trying to put, but Apple is not trying to make software for industrial applications, they are making software for end users and AWS literally has nothing to do with that.


Apple hasn't made money from selling their OS for almost a decade


What makes you think they don't include the price of the OS when you buy their hardware? In fact, that's how many justify paying a higher price for Apple products - you get macOS, Pages / Numbers / Keynote, iMessage / Facetime etc. That's also why they stop supporting old hardwares after a period.


Yes and no. I'm sure they'd lose approximately some customers if were as easy to install macOS on commodity hardware as it is to install, say, Linux.


That is already true anyway with OSX86. I have known a number of people too poor to afford macs that rig up a hackintosh.

Apple has never stopped the DIY crowd. Their core market is the people that want the support and the branded aluminum.


That’s not strictly true. It’s hard work keeping a hackintosh working. I think apple is part of that.


> I find this attitude kind of troubling around here when every other day there's some "open source" project that has had to change licensing because insert cloud provider is stealing their lunch making it impossible for them to make a living.

When such licenses are to another free software license (like AGPLv3), you won't here complaints from most F/OSS people on the basis of the license being untrue to F/OSS.

You will hear complaints from customers who now have to change what they're doing (pony up for a different license or switch to a fork). That's not an attitude problem, just a reality of having your toolchain disrupted.


Darwin, Apple's OS, is open source.


Calling it an OS is a bit generous—although XNU is open-source, actually getting it running on hardware from just the publicly released parts is not particularly feasible. PureDarwin exists, but it's mostly just a curiosity to run in QEMU at this point.


It is, but it's also a complicated story that doesn't seem to go well. Basically past honeymoon period, the open source part of the project just was increasingly left on the side of the road.

https://en.wikipedia.org/wiki/Darwin_(operating_system)


And yet it is not possible to run a single MacOS targeted GUI application on it without many proprietary components on top.


Since macOS is / was a port of xBSD, how much difference is there between Darwin and xBSD kernel?


The userland was largely BSD, but the Mac kernel was a Mach kernel w a BSD shim for syscalls, iiuc.


A significant part of the FreeBSD kernel was used in XNU.


They do contribute to Kubernetes, albeit at a pretty low level, and for self serving needs.


What about FDB?


FoundationDB is awesome


Vouch for this


GPL != OpenSource


Indeed, GPL is libre software, but libre software is also a subset of open source software so they are often mistaken as the same.


GPL == OpenestSource


Nah. That's probably MIT.


Depends on whether you think "openest" means "most free to do whatever you want with" or "most guaranteed to remain open" ...


Yeah, I'm familiar with the FSF's philosophy. Limiting freedom in order to protect it. No thanks.

It leads to exactly the sort of problem pointed out by the GGGGP comment - Apple shipping an ancient version of bash because of license incompatibility. Apple cannot open source all of their software. They'd go out of business. So instead we have GNU folks high-fiving because they stopped Apple from using their work without giving back, but millions of users are also prevented from using their work.


Nobody is prevented from using newer versions of Bash. They just don't ship from Apple.


Well how will you get it installed?

Brew? Well that has no signing support and no supply chain integrity. Hundreds of people have access to push whatever they want to a git repo and anyone is free to forge commits and backdoor all brew users as they like. It is worse than NPM.

At least on Windows you can install WSL and then get access to APT which checks RSA author signatures on everything regardless of mirror.

MacOS only provides signed packages via their app store. The end. If you want software they don't offer like a modern version of bash, you have to get it from untrusted sources like Brew that risk compromising your system.


>Well how will you get it installed?

download source code ./configure make sudo make install

seems to work for lots of software. By default it should install in /usr/local/<bin/lib> but I've done this for lots of OSS software (e.g. postgres and nginx) on Mac with few problems.

Yes, sometimes you have to pursue the odd missing dependency and build that too (e.g. openssl or readline), but I've always managed to build from source in the end without brew or (what's the other one called?).


Fair enough, but I have never observed another MacOS user in the wild compile from source.

No matter the risk, every engineer I know uses brew.

MacPorts is the other one and it at least uses some crude bulk openssl signing, but the higher barrier to entry means fewer packages so devs don't use it.


Until this moment I didn't know the Apple version of bash was outdated, I reluctantly started using zsh when Apple defaulted to that. Now I don't care about bash.

Was that good for bash?


What does it matter when you don't care about it? Tomorrow if Apple replaces Zsh with something else, you are the kind who won't care about that too. Those who care about bash, can still install and use it, and more importantly enjoy the freedom of modifying it as much as they want, without any hindrance from Apple or anyone. That's because with FSF opensource licensed softwares, Apple or others using it in their product cannot refuse to give you the source code. Other opensource license don't guarantee such freedom.


I mean, they probably could open-source all of their software, although at a price of weaker lock-in.

They are primarily a hardware company with really great solutions for many problems, so it’s not like iphones or macs wouldn’t sell. Hell, in a way not providing decent support for other manufacturers devices could be viewed as anticompetitive (why can’t I goddamn send a file over BT to android in 2021?)


> I'm familiar with the FSF's philosophy. Limiting freedom in order to protect it.

I don't think that is a good characterization of FSF philosophy. Better characterization is maximizing freedom for the [end-]user, as opposed to, for you, the developer, or other parties involved.

> millions of users are also prevented from using their work.

That is extremely weird to blame on GNU (sort of akin to "victim-shaming"). First, how are they prevented exactly, when the can download whatever GNU bash they want themselves? Second, it is Apple's deliberate choice to boycott and not to ship the software due to a perceived burden on them (or rather their active desire to keep unreasonable control,) than a legitimate concern imposed by the GNU GPL license. If any user is deprived of anything you got to blame Apple first for doing so.


I think it's quite a good characterization. The FSF is pretty clear about their philosophy. They define four essential freedoms, two of which relate to redistributing software. By definition, someone who redistributes software is not the end user. In What is Free Software[0] the FSF says, "Freedom to distribute (freedoms 2 and 3) means you are free to redistribute copies, either with or without modifications, either gratis or charging a fee for distribution, to anyone anywhere. Being free to do these things means (among other things) that you do not have to ask or pay for permission to do so."

It looks to me like the FSF takes the freedom to redistribute software fairly seriously. Yet the GPL explicitly forbids redistribution unless certain conditions are met. In other words, they limit freedoms 2 and 3. Given how seriously they take freedom, you'd think they have a good reason for limiting it. They do: to maximize the spread of freedom, even if it is limited. RMS, for example, wrote[1] "I make my code available for use in free software, and not for use in proprietary software, in order to encourage other people who write software to make it free as well."

RMS also wrote an article called Why Open Source Misses the Point of Free Software[2]. But I'm not missing the point of free software. I understand the point very well. I just have different values. I don't care if other people who write software make it free. I want to maximize the value and utility of the software I write, and restricting freedom gets in the way of that.

Here's the thing: the FSF is basically trying to make the world safe for coders. All software should come with source code, so that everyone can tinker to their heart's content. But most people can't do that. Being able to modify the source is useless to them. Heck, even downloading and installing it is difficult. I guarantee you that the number of people who could install bash—even a binary distribution—is dwarfed by the number that could use it to run command-line tools. They'll just use whatever shell comes with the system. And if the FSF won't let Apple ship bash, they'll ship something else. So yeah, the FSF is preventing people from using bash. They think it's justified. I don't.

  [0] https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms
  [1] https://www.gnu.org/philosophy/pragmatic.html
  [2] https://www.gnu.org/philosophy/open-source-misses-the-point.html


They will go out of business? This is nonsense.

The Android Open Source Project and ChromiumOS have hardly made Google go out of business.

Would any significant percentage of Apple fans see an "Apple open sources MacOS" announcement and suddenly throw their Apple gear in the garbage?

Of course not. They pay for the support reputation and the pretty well marketed aluminum they can't impress their friends without.


It wouldn't be overnight, but Apple's business would no longer be sustainable. Samsung and a dozen Chinese companies would instantly start shipping iOS devices. Sure, the hardware wouldn't be quite as good as Apple's, but they'd still steal a big chunk of Apple's market share. Then it'd be a few years of slow bleeding where they subsidize their competitors, unable to compete on price and eventually die.

This same dynamic would apply to Macs as well, of course. In fact, this very thing came this close to killing Apple in the 90s. They licensed MacOS to clone makers, who immediately took the high-end high-margin market, and left Apple to develop MacOS and sell low-margin, entry-level machines. It took the return of Steve Jobs to turn the company around. They were weeks away from bankrupcy. He immediately killed the clone makers, begged/threatened Microsoft into giving them bridge funding, and started work on the candy-colored iMac.

As for Android, well, it's nominally open source, but an awful lot of the stuff you need to ship a competitive OS is actually closed and closely guarded by Google. It's a bit more open than Darwin, but not much. If you stick to ASOP, you've basically got Froyo.

So, yeah, Chromium and is for real, and again it's a bit more open than WebKit in that it also includes the app chrome, and not just the web engine. But coincidentally, Google benefits from an open, standards-based web; it doesn't threaten their revenue at all. Go figure.


CalyxOS and others which is a daily driver for myself and many I know is all based on AOSP and freely available software from F-Droid and Nextcloud ETC which replicates virtually everything I once used Google for.

This fact has not killed Google because Google controls the App Store that has all the proprietary social media apps most people want.

Apple could dictate their App store and cloud services are only licensed/supported for use on Apple branded devices just like Google does and still keep the overwhelming majority of their market.

Open source won't kill a monster as big as Apple, but this rabbit hole is kind of moot because Apple will always maximize profit, consumer freedoms be damned.

A forcing function would need to happen like some of the scattered mandates in Europe that only open source software be used in some education, government, and critical infrastructure environments to avoid lock-in.

If enough did this Apple would have to open source or else lose support contracts to those that do.

That's what I will be pushing for longer term.


Not suddenly, but looking at what happened to IBM and PC clones (hardware) and IBM and OS/2’s compatibility with Windows (software): yes, probably.

They’re both different cases, but, IMO, still apply.

If Apple open-sourced their platform, Microsoft could choose to offer Windows Services for Macintosh, and hardware manufacturers could offer cheap hardware that runs Mac OS.

Microsoft could follow up by stopping offering Office for Mac OS or to by letting it (further) fall behind the Windows version. Adobe could follow suit.


> ... FSF's philosophy. Limiting freedom in order to protect it.

You sure have some lopsided idea if you think that the goal of opensource is to protect the "freedom" of the businesses, who want to make money from free labour. FSF opensource license exists to ensure freedom for the end consumers of the software.


No, that's not the goal of open source, obviously. In my case, the goal is to let as many people as possible benefit from my labour. I have no problem with businesses using my code to make money and not paying me a dime. It's happened a few times. The end consumers got better software as a result. It wouldn't have been possible with the GPL, which is why I use MIT.

I get that the FSF sees it differently, but honestly I don't see how the GPL helped anyone in the case of Apple and bash. It's not like Apple was making significant changes to bash, refusing to contribute them back and making a fortune on the backs of the FSF. Are contributors to the zsh project being exploited by Apple's evil plan to put their work in the hands of many more users? If I find a bug in my Apple-supplied copy of zsh, am I prevented from fixing it like RMS and the printer driver? No.


> In my case, the goal is to let as many people as possible benefit from my labour ... The end consumers got better software as a result

That is your prerogative for your own software. FSF's goal, likely shared by the author when they picked the license, is not and has never been the maximal popularity of their own software. You may not like their goal or see it as valuable, which is a reasonable question of values, but that does not make their strategy poor for achieving what they care about, which, I repeat, is not "popularity," nor even "better software for end users," strictly speaking. Confusion arises when people subconsciously project their own goals/values on FSF and then evaluate FSF's strategy under that pretense. GPL is a very effective tool for accomplishing what FSF wants, and the trade-off with popularity is very much deliberate, not some surprising side effect.


> No, that's not the goal of open source,

That is the goal of FSF opensource projects - protect the rights of the developers and users to review and modify code.

> The end consumers got better software as a result.

I disagree. If they don't have access to the accompanying source code, it is an inferior product.

> I don't see how the GPL helped anyone in the case of Apple and bash.

Thanks to FSF license, any user can ask the distributor to provide the source code of an FSF licensed app. In our example, that's Apple and they cannot refuse to give you the source code of bash along with the modifications they have made. Which brings me back to the point that needs to be emphasised - GPL and other FSF license was not designed to help businesses and corporates. It's aim is to ensure the freedom of developers and user to review and modify code is preserved.

> If I find a bug in my Apple-supplied copy of zsh, am I prevented from fixing it like RMS and the printer driver? No.

Yes, if Apple refuses to give you the source code of their customised zsh, then you are indeed being prevented from fixing any bug or adding any new feature! I hope you finally understand - FSF license ensures that Apple (or anyone else) cannot refuse you the source code. Other opensource license don't come with such guarantees.


> If they don't have access to the accompanying source code, it is an inferior product.

I agree with the overarching preference for GPL over MIT, but this point is one of the most insular HN-bubble comments I've seen since the Dropbox comment. Most users – hell, most developers – do not give a toss about having the source code for software that's shipped with MacOS. I have never spoken to anyone who's wanted or needed the source code for Bash or Zsh.


There's a big difference between wanting personal access to the source code and wanting to know that the source code is available should the need or desire ever arise.

I've been developing FLOSS for several decades now, but I rarely compile stuff from source anymore (except my own projects). However, the availability of the source code for the tools I use is very important to me, even if I never exercise it myself.

In addition, general access to the source code is important as a learning tool for programmers, if only "to see how it's done". You may never build such code, but being able to take a look at it can be an important foundation in the continuing education of software developers.


Like I said to the other commenter, the source code for the software being discussed already is available - by definition - and much more easily than if you had to go searching through /usr/lib. It's an absolutely moot point[0] whether Apple bundles the source code for Bash into their operating systems, for 99.99999% of intents and purposes and users.

We're not discussing whether the source code for XNU/Darwin/Mach/MacOS itself ought to be open, which is another question entirely. (Obviously everyone would sooner it be open than not open, in a first-order analysis, but, as with medical patents and the like, a proper analysis would have to ask whether it would even have existed if its source code were to be open.)

[0] Or rather a non-moot point, for the pedants.


>[ ... ] as with medical patents and the like, a proper analysis would have to ask whether it would even have existed if its source code were to be open.

The overwhelming majority of XNU/Mach was created as open source. It is quite unlikely that macOS would exist today if those components had not been created under an open source license.


> Like I said to the other commenter, the source code for the software being discussed already is available

I was replying to this remark:

> Most users – hell, most developers – do not give a toss about having the source code for software that's shipped with MacOS.


> but this point is one of the most insular HN-bubble comments I've seen...I have never spoken to anyone who's wanted or needed the source code for Bash or Zsh.

It might be in-bubble, but "I have never spoken to anyone who..." is a poor heuristic for evaluating the superiority/inferiority of a product.

I have also never spoken to anyone who needed a repair manual for a truck, but I can probably agree with the statement that truck companies that publish comprehensive repair manuals are better than truck companies that don't.

Similarly, I can guess having the source for bash or zsh probably helps people who work with them more closely than I do.


> It might be in-bubble, but "I have never spoken to anyone who..." is a poor heuristic for evaluating the superiority/inferiority of a product.

∃x→¬P(x) is a poor response to ∃x→P(x), but a good response to ∀x→P(x). In this case, the parent commenter was claiming - in context - that all end users need or benefit from having the source code to their software, so it is relevant to say that that statement is true of absolutely nobody I know.

If he were making the abstract statement that publishing the source code might benefit some people, that would be another thing. In reality, I don't think it makes any difference whether Apple bundles the source code to these programs, when the source code, by definition, is openly available, and can be accessed much more easily by Googling it much more quickly and easily than by searching for it somewhere in /usr/lib.


It'd be really great for the Nix project if up-to-date sources for what comes on macOS were available. Probably for MacPorts, too, and maybe even Homebrew.

If source code were available for the end-user applications that come with macOS, I'd give them a try, too.


My reasoning is simple - access to the source code preserves your right to repair. Since closed-source application deny that, they are inferior.


Yes because Apple users are too stupid to manually install anything.


Well, I manually install bash, but most people just use the shell that came with the system. If the FSF wants it to be some other shell than bash, well, ok, mission accomplished.


MIT is the most permissive--not the same thing.


Without WebKit being open source and maintained, Chrome would never have existed.


WebKit had to be open source, because it was based on KHTML, which was LGPL-licensed. Apple had no choice there.


In in alternate universe Chrome would have adopted KHTML.


I don't know what shape you think KHTML was back in the day when Safari 1.0 shipped, but it was vastly different a few years of development work later by Apple.


It was decent. Being a Konqueror user before Safari came onto the scene, I'd argue it was the best browser around at the time. The work no doubt continued to improve as time moved forward, as software tends to.


Yup. I did some hacking on khtml before Apple's announcement in my attempt to make the early 2000s the year of the Linux desktop. To be fair, every browser engine was kind of a mess at that time because everyone was trying to reverse engineer IE (or gecko's) undocumented quirks.

The DOM implementation in khtml was particularly well done. I remember one of the major things Apple did was rewrite kjs (into JavaScriptCore), but from what I recall, it wasn't like they did a complete overhaul of khtml right away.

One thing to consider is that Apple, unlike the khtml project, had a lot more power to steer web standards and that tended to clean up browser impls.

It's a shame that Apple decided to have a pretty arcane development process for Webkit, it was not what people expected when they announced Webkit.


> It's a shame that Apple decided to have a pretty arcane development process for Webkit, it was not what people expected when they announced Webkit.

This is a fair point. I believe they milked the, "it's Open Source (Come on In!)" and then would periodically release diff blobs and wonder what else the common folk would possibly find wanting.


This is ultimately why WebKit was forked again into Blink. Because Apple is such a poor steward of open source and WebKit is absolutely riddled with bugs and incomplete implementations of web tech that are pretty much table stakes at this point (WebRTC, among other things). At this point I think most people agree that Safari is the worst mainstream browser in existence.

This is why Apple is met with groans instead of praise when their open source contributions come up.


Apple stole WebKit from KDE


It is not stealing when the license allows for it.


wasn't that just a fork of khtml. what exactly did apple do


Rewrote the entirety of it, added most of the new features for the web over more than a decade?

Or do you believe chromium is also “just a fork of khtml”?


yes they're all derived from the fork of khtml. is that what you're asking?


No, I was asking about "just a fork of khtml". That implies that there wasn't meaningful work. WebKit is at this point (and probably a decade ago) a functionally complete rewrite.

When webkit forked KHTML, KHTML couldn't render the vast majority of the top 100 websites properly, just by the time the first safari was released webkit was already able to render those correctly, or in many cases even usably.

When I say WK rendered correctly, I mean matching Firefox/Explorer, not just a bare "is useable".


Not saying you are wrong, but I remember that KHTML was the first renderer that was able to pass the ACID2 test. So this doesn't sound right to me


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: