At the most recent Apple World Wide Developers Conference, Apple announced they would "open source the next version of its programming language Swift." This minimally means they will publish the source code to Swift using an OSI approved open source license. That's all really. Indeed, the last paragraph of Klint Finley's (@klintron) otherwise excellent article gets it wrong when it says, "But by moving programming languages and other core developer technology into the realm of open source, companies like Apple can provide some assurances that developers will be able to adopt these tools to their own needs without facing legal action." Not even a little bit true. The risks are all still there. Another company could still happily sue the living daylights out of anyone they believe to be infringing their property.
And it's not simply the community and legal basics people continue to misunderstand. There's still a surprising lack of understanding in companies big and small about the business and economic basics. John Mark Walker (@johnmark) recently completed a brilliant four-part series of posts outlining the basic "how to make money" with open source. The opening paragraph to the series begins:
"I never thought I’d have to write this article in 2015. By now, I thought it would be self-evident how to derive revenue from open source software platforms. But alas, no. Despite the fact that the success of open source software is unparalleled and dominates the global software industry, there are still far too many startups repeating the same mistakes from a thousand startups past. And there are still far too many larger companies that simply don't understand what it means to participate in, much less lead, an open source community."
I encourage you to find time to read all four posts [1][2][3][4]. While John Mark presently works at Red Hat, a company that deeply understands the business of open source, his experience goes back almost 20 years to when he worked at VA Linux.
Companies are indeed contributing more and more to software licensed as open source. Google is building a community around Go and last year began a community around Kubernetes. Go is certainly an interesting language growing in popularity, but Kubernetes represents a decade of Google research and experience in deploying, managing and orchestrating application containers at a time when the industry at large is just catching up. Apple will launch Swift into the public eye. Even Microsoft has learned that they must engage differently with developers and has published .NET (for the second time) late last year. It is no longer about broadcast communities like MSDN.
Building community is where the work gets done for a company sharing assets and collaborating around software, and building community is hard work. There are lessons for Apple to learn and quickly. To build a community, it has to be blindingly easy to engage. The software needs to download and build to a known tested state on a known platform (ideally many) if you want developers to spend time. Otherwise your project becomes one more moribund collection of software thrown over the wall onto github or SourceForge that will frustrate developers and finally chase them away. There are a well known set of patterns and practices that work to enable and build successful communities. This isn't a secret.
And early communities are skittish fragile things. I was part of the original publishing of .NET under an academic research license. There are lessons here for Apple in how to get it "right". We published roughly a million lines of code for the C# compiler, Base Class libraries, and Common Language Run-time (and a complete platform abstraction layer, and a full test harness). Once a developer unpacked the source archive, it was a two [simple] line sequence to build and then test the components into a known state on Windows, Mac OS X, and FreeBSD. The two pages of documentation essentially told you how to do this small amount of work to get to a guaranteed known state, how to prove it running the sample code, and gave a brief discussion of the source tree so people could quickly begin to explore it. [There’s a good description of the original project on MSDN.]
Within 24 hours we received our first righteous patch. A simple 15 line change that provided a 10% boost in Just-in-Time compiler performance. And we politely thanked the contributor and explained we weren't accepting changes yet. Another 24 hours and we received the first solid bug fix. It was golden. It included additional tests for the test suite to prove it was fixed. And we politely thanked the contributor and explained we weren't accepting changes yet. And that was the last thing that was ever contributed. This was done with malice of forethought. And it was heartbreaking. The project was still successful for what it was -- a research platform for programming languages, but it never became a collaborative community around the platform itself. At the time, Microsoft was still very concerned (and conservatively hyper-cautious) about how close the academic code base was to the mainline .NET product space.
So I wish Apple well. It's great to see them participating more broadly in this particular space. They will have challenges in community building, getting the governance right, and thinking through how they want it to contribute to the business. Fortunately there are lots of excellent resources for them to use as they join the broader open source community. Maybe we’ll even see folks from Apple at this year’s Community Leadership Summit. Because as we all know, collaborative innovation is the new engagement mechanism.
Recent Comments