Placating the tech crowd by giving away fragments of low level code is really just marketing and a way to retain talent that would otherwise refuse to work for them. It's not as if their users can actually use any of that stuff to change how their macs work (without switching to a different OS or browser).
WebKit for one has fairly wide adoption outside of pure Mac OS X. As for the rest of it, just because something is open source don't expect many people to use it.
Yes but then it's also being developed by far more companies than Apple.
For 2012 Google submitted roughly twice as much code to Webkit as Apple (which came second), apart from them we have smaller yet notable contributors like RIM and Nokia (7% and 5% respectively).
Let's not forget that reduced maintenance costs are often touted as a reason to opensource code in the first place. And when you consider it was developed by Apple and so presumably fit there needs well when released it as working code, it's not surprising that adapting it to new use cases involves more work than maintaining it.
Actually, I was just pointing out that they are not open in any meaningful sense of the word - their products are very, very closed and controlling and that's how they like it. Comparing them to Canonical is in my opinion very silly for that reason, it's apples to oranges.
Didn't Apple buy CUPS specifically so that they could keep parts of it proprietary?
They're definitely only funneling money into LLVM so they can drop their dependencies on GCC, which will probably have a net harmful effect on the free software culture.
It's sort of obvious? I can't see any other reason Apple would have for it, other than making compilers researchers have slightly easier lives. It'd certainly make sense after they were forced to open source the frontend for Objective-C.
Apple had two technical needs that GCC could not reasonably satisfy. One was to compile Core Image filters. When you make a chain of filters, they treat it as a single complicated filter which they JIT compile and optimize for your GPU or CPU (I believe they decide at run time which to target based on what will be best for the particular complex filter you have defined).
Another technical need they had was for a compiler system that could be easily and tightly integrated with other tools, such as IDEs and debuggers.
Either of the above would have required extensive modifications to GCC, and they would not have been able to get those modifications into the upstream. The result would be Apple would have to maintain a fork of GCC. They'd be spending a lot of effort porting things from upstream into their fork.
1) Replace GPL code with BSD code
2) Release a subset of the features to open source community
Why would Apple be so allergic to GPL unless they want the ability to close stuff? If really you think Apple would stay open if they dominated the market look at the iPhone.
This is only "hurting free software" if you are a complete radical like rms, who believes that any closed source software is an affront to humanity, blah, blah. Otherwise, it doesn't matter what Apple closes, as everything that was Free before, is still Free afterwards. If you don't like Apple's stuff, fork it. If you don't like closed source software, don't use it. I don't see anybody putting a gun to anyone's head and forcing them to use Apple stuff.
Your metric is essentially "no knowledge is lost from the Free world." However, this means that all free software developers could die tomorrow and your metric would be satisfied.
A better metric is "the most free software that could be made is made." Switching from a GPLd compiler platform to a non-copyleft "freemium" Apple platform is worse for this.
If you don't care about free software as a political goal, there is no purpose to have this discussion in the first place, as you don't care about free software being hurt.
I think you're setting up a false dichotomy here. "You care" or "you don't care". Reality is more nuanced than that. Also, the idea of "all free software developers dying tomorrow' is just hyperbole, since the chances of that happening are essentially nil.
Yes, we'd all like to maximize the amount of F/OSS software in the world. F/OSS is a Good Thing, and I founded a company based around F/OSS for a reason. But it's not this horrible tragedy / affront to humanity, if Apple (or whoever) takes a step away from a purist "Free" software position.
To put it another way: no one owes you (or me, or anybody else) a world full of all the Free software we want. And even more so when plenty of people in the world don't care about software freedom. As long as those of us who do care have the option to fork and continue development of projects, then the actual freedom remains, as far as I'm concerned.
> Also, the idea of "all free software developers dying tomorrow' is just hyperbole, since the chances of that happening are essentially nil.
That is exactly my point. You proposed a metric for the health of the free software culture: "Nothing that is free now is non-free in the future." This is a bad metric because if you eliminate all free software development, it reports "everything is okay."
You proposed a metric for the health of the free software culture: "Nothing that is free now is non-free in the future."
It seems to me that you're turning something analog into something binary. "Nothing that is free now is non-free in the future" is true, relative to any particular project, and is - as a worst case - not so horrible. But applying that to "free software culture" in general, as a comparison to the idea of ALL free software development stopping, doesn't sound reasonable to me. It's like you're suggesting that, say, Apple, moving away from GPL'd "Free" software towards BSD software (and possibly a "free core" model) automatically implies that everybody else does too. But that's just as likely to happen as your hypothetical of every Free software developer dying tomorrow.
The "every free software developer dying tomorrow" is a hypothetical statement that has nothing at all to do with Apple. It was in my comment because it's a great way to illustrate that even if things aren't explicitly subtracted from the Free world, the Free world is harmed if its growth is slowed.
OK, but "harmed" is a broad term. I'm harmed if I stub my toe, but I'm also "harmed" if I fall of a bridge and land on my head and crack 4 vertebrae. But there's a big difference between those things.
And anyway, my point was (at least partly) that the growth doesn't necessarily stop because of - for example - the Apple deal (or something like it) because people can always fork. And if the last GPL'd version of something that goes closed is popular enough, it gets forked. See: Nessus[1] / OpenVAS[2].
Regardless of the technical considerations, Linux and its surrounding ecosystem has a long history of many different companies co-operating on core software. Canonical's philosophy seems to fly directly against that - so far we have:
Launchpad / Upstart / Unity / Mir
Launchpad is free-software by name only, and Canonical actively discourage you to setup your own instance.
Upstart hasn't been widely adopted outside of Ubuntu, and has been replaced by the technically superior systemd.
Unity has been extremely unpopular from a user-experience point of view, and now we have Mir. So past history isn't filling me with confidence. Their philosophy seems to be "patch first, ask questions later".
I'm amazed how Canonical has the resources to keep branching out so much while producing a distribution every 6 months. I was under the impression they weren't yet making a profit.
Upstart is a bad example. pacman is a package manager only used by Arch Linux and nowhere else. Should Arch abandon it because it hasn't seen wide use yet? Better yet, there are plenty of package managers that are better than both aptitude and pacman (http://nixos.org/). Should we abandon the technically inferior solutions for the technically superior ones?
Unity is the same way: it is open source. If you don't like it, fork it and fix it. Or use one of the alternatives. This is not Windows or OS X. Vote with your feet and move over to Gnome 3, Xfce, LXDE, or another DE. If enough people do, Canonical will see the effects and stop putting effort into Unity.
IMHO, Linux and its surrounding ecosystem has a long history of everyone trying to pull it into their own direction. Companies are often forced to cooperate when they don't have another choice, but if they did, they would push their own ideas of what the infrastructure should be on everyone else.
But I would personally much rather see pacman (and every other distro-locked package distribution format) dropped where everyone adopted debs or rpms.
What I would like the most, though, is that the most logically technically advanced and easy to use package manager win, and everyone just adopt that. I know that pacman makes building package builds insanely easy, compared to debs or rpms.
> Upstart is a bad example. pacman is a package manager only used by Arch Linux and nowhere else. Should Arch abandon it because it hasn't seen wide use yet? Better yet, there are plenty of package managers that are better than both aptitude and pacman (http://nixos.org/). Should we abandon the technically inferior solutions for the technically superior ones?
A couple of points:
- one example does not plenty make
- Nix has a really interesting technical design. However, it trades the ability to patch security holes across your entire system for the ability to install multiple packages side by side and have atomic upgrades.
More importantly (I was lying about the two points), the package manager is tied intimately to the guts of the distro, it's much less shocking than having Ubuntu implement Unity.
Now, we'll see what becomes of Mir. Whatever mindshare Upstart had went straight to systemd as soon as it came out. If Mir is primarily an expression of hubris, I expect it will follow Upstart in obscurity. If Canonical manage to convince enough developers in the community, they may get something going.
"better" is generally subjective. there's a reason why nixos, upstart, etc, don't catch on.
For pacman vs nix, well, pacman is extremely simple. Extremely reliable.
Nix has some design advantages, but that don't translate all that well in the practical world right now. Maybe in the future.
Upstart was used because it was better than traditional init, and was used by Fedora as well. Then again, Linux could have had a much better init system many years ago, but the GPL zealots wouldn't hear of having launchd, and its less restrictive license, be used.
To clarify, my comment was that even before relicensing, launchd was under a less restrictive license than the GPL -- the APSL allows for binary linking -- but had clauses that didn't allow people to GPL their code. By the time launchd was relicensed, ubuntu had already released upstart, and another init replacement so quickly would have alienated people.
I don't see the problem in wanting to keep the guts of the OS forced-free by license. If any of the deepest components of the Linux stack were MIT or BSD licensed, it wouldn't take long for some business to fork it into a proprietary blob they push for market adoption and you lose the freedom deep in the OS.
With something like init, I would have to disagree. The biggest problem with this decision is that they ended up with an inferior project that wasn't nearly as flexible as the open options. While there are certain areas where keeping things under a restrictive license like the GPL may be useful, the init system is one where I can't see of any way how a closed system would offer any sort of competitive advantage.
> Unity has been extremely unpopular from a user-experience point of view
Has it? Do you have numbers?
Because I see a small number of people who complain very loudly, and often make sweeping claims about how unpopular it is without any evidence, who always get followed by responses from people (like me) who love it...
upstart is used by the current release of RHEL, but it's true that Red Hat has signaled that systemd will come to RHEL as well (Fedora now comes with systemd as far as I know).
I don't see the problem with then using whatever they want, if it provides a good solution, when upstart was developed systemd wasn't even a viable alternative, for me it still is not if stability is what you want and run on a non-desktop system.
Exploring Android internals I much SurfaceFlinger than X in my understanding of its architecture.
