Apple Open Source
opensource.apple.com
opensource.apple.com
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.
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.
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.
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.
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.
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.
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...
Is OP wrong in his description of Apple's rules and permission wrt OS?
It's worth noting there was a huge debate internally about this around the time I left, with many people dissatisfied with the policy.
I like this. Sums up a lot of things about HN.
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.
Probably the same way they deal with support: refer users upstream [1].
[1] https://daniel.haxx.se/blog/2021/11/18/free-apple-support/
Link to Bryan Cantrill's humerus talk. https://www.youtube.com/watch?v=vm1GJMp0QN4#t=41m18s
However an individual employee could not just decide they want to submit some patches to Apache Whatever on their own time.
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.
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.
There is also iCloud.
It used to be that the page should list things they're maintainers of..
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 such significant changes at the early days that the two projects should be thought of as not having all that much of a relationship.
> 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.
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
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.
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.
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 quite sure they care about Apple devs either: https://news.ycombinator.com/item?id=29493643
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.
https://github.com/apple-oss-distributions/Chess/tree/Chess-...
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.
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.
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.
[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...
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.
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".
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
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.
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.
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
[1] https://developer.apple.com/library/archive/documentation/Co...
XNU is there
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.
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.
But also worse off, because features like WebGL2 are released literally 5 years after other browsers supported them.
I wonder how servo does these days: https://servo.org/
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++.
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."
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...
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.
Was that good for bash?
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.
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?).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
∃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.
If source code were available for the end-user applications that come with macOS, I'd give them a try, too.
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.
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?)
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.
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.
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.
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.
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.
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.htmlOr do you believe chromium is also “just a fork of khtml”?
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".
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.
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 why Apple is met with groans instead of praise when their open source contributions come up.
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 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 has never stopped the DIY crowd. Their core market is the people that want the support and the branded aluminum.
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.
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.