Common problems after Swift open source

[[136884]]

Apple said it would make Swift an open source project, but it still had reservations about the issue of software freedom.

So what does the involvement of open source for a programming language mean? This topic is a bit complicated, and it is also related to the core of the open source proposition. Specifically, its compiler may be open source, the entire tool chain may be open source, and the language itself may be supported by an open source IDE. Each of the items mentioned here can be regarded as a necessary element for a language to become open source.

The next question is: Can independent developers make a language open source? This is also a complex question. For example, Oracle, which has made Java open source, cannot tolerate alternatives to Java, as Google has discovered. So we have to wait for Apple to actually license it and see if it truly represents an open door or if it is just playing with patents and copyrights to stimulate innovation related to the project, as Oracle has done.

But there is more to the story. The most important question to consider is whether this programming tool will lead to software freedom. To answer this question, it is far from enough to simply focus on syntax, tool chains, or even the possibility of independent implementation.

A programming language is more than just a collection of SDKs — APIs plus code libraries — stitched together. On their own, a programming language can’t do much. But what really matters is that the platform has an open source SDK that can be used, plus an API that users can actually get. This is especially true for programming languages ​​that are built on software freedom.

Swift is designed to make programming for Apple's heavily protected mobile platforms more secure and simpler than Objective-C. Apple says it "plans for OS X, iOS, and Linux," but there are huge differences between the three. The biggest feature of iOS and OS X is that they are "convergent," while Linux is "loose" for a range of system solutions - specifically, the universal window manager alone is divided into two camps, GNOME and KDE, each of which contains multiple branches.

While Swift will bring better type and memory safety to iOS development, in our opinion, apps written in Swift for iOS and OS X will be difficult to port to other systems - except for the common "engine" code in the app. Perhaps apps that take a strict MVC approach will be able to interface more easily with Swift's controller mechanism, but we still find it difficult to believe that this will be enough to make view code portable.

So will Apple's Swift programming language go "open source"? Unless we see the specific licensing and governance terms of the toolchain, we can't give a definite answer, but Apple's answer is yes (including OSI-approved licenses, accepting code contributions, etc.). And even if open source becomes a reality, if we can't develop open source applications using the Swift language, then all this is still meaningless - this is by no means an academic question.

The programming languages ​​themselves aren't the problem; the SDKs they use are. When Apple announces SDKs that work in parallel with Swift, it's unlikely that they'll work seamlessly on Android or any other open source Linux-based platform (not to mention Windows).

Swift may be able to provide modern developers with lip service to the open source promise and leverage in their favor, but I personally don't have high hopes for this - especially considering Apple's consistent protective attitude towards its patented technology reserves.