Lessons learned from Symbian’s journey to open source and back

With word that the Symbian Foundation is transforming again, this time away from an open source nonprofit to a licensing operation of Nokia and other Symbian developers and backers, there are indeed some lessons for how commercial open source communities work, and how they don’t.

First, we’ll cover some of the meaning and implications for what remains of the Symbian Foundation, the Symbian OS and its primary backer Nokia. There is no question it is rightfully being viewed as a failure in terms of open source. While Symbian had some of the ingredients for a vibrant open source project — significant developer, manufacturer and user penetration, commercial backing, open source Eclipse Public License and community structure — it also struggled from the start to address one of the greatest challenges for open source projects: balancing control and community. As we’ve seen with other cases in the past, it seems it is difficult for a software project or community to succeed and grow beyond its roots and original supporters if it was not open source from the start. Even when open source from the start, it can be particularly challenging to benefit from corporate interests, investment and participation while still maintaining community independence and enthusiasm among open source developers. We also see continued evidence of this challenge and struggle with Oracle and its ongoing stewardship of and interaction with open source software projects and products that were part of Sun Microsystems, including Java, OpenOffice, and OpenSolaris.

The Symbian Foundation is not the only group that has something to learn from all of this. Open source projects, developers, companies, investors and others should also be aware of why open source did not seem to generate its benefits of faster development, flexibility and future path through community growth in the case of the Symbian Foundation. It would be a shame if open source developers and communities were unable to accept software or a project because it was not open source from the start, but that seems to be the case. The key to overcoming this, and to moving beyond perceptions that a single company or group is attempting to benefit to the exclusion of others seems to be in attracting cross-industry and cross-open source and proprietary support, similar to what we have seen with OpenStack from Rackspace, which incorporated NASA and its open source Nebula code at the start and has since won the support of a range of industry players, including open source vendors and non-open source vendors. In the end for Symbian, the use of the Eclipse Public License and establishment of a nonprofit foundation did not ensure the development and emergence of an Eclipse-type community. Instead, Symbian has continued to languish in terms of attention and developer mind share while iPhone, iPad and Android garner more.

So the lessons from the Symbian Foundation’s journey to open source and back are basically in order for an open source community to flourish, that community must take priority over control and commercial interests. It is also fair to say Symbian is a reflection of the reality that the odds of open source success are increased if the software project is open source from the start. At the very least, the challenges of building community around software that has transformed from proprietary to open source are much greater, and the need to involve and advertise additional involvement are also greater. Even aside from these factors, open source communities that succeed are also arguably the benefactors of timing and luck, and these also seem to be tipping the scales in favor of others.

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , ,

2 comments ↓

#1 Knickers on 11.10.10 at 5:31 am

Allow me to nit-pick. You write:
“the odds of open source success are increased if the software project is open source from the start.”

When something is expected to succeed, i.e. when an outcome is deemed (more) likely, the odds are DEcreaseing. A sure winner has no betting value and its odds are therefore (nearing) 1.00. The more unexpected the outcome, the higher the odds.

Too few are going to the races anymore 🙁

#2 Anonymous Commentor on 11.17.10 at 4:38 pm

> open source success are increased if the software project is open source from the start

People who haven’t had a chance to be involved in designing of the software have much less (emotional or other) commitment to it.

If there’s no particular itch with that software, like it being an _almost_ working solution to a problem somebody has, why they would get involved?

Software that’s too unmature or missing too many pieces doesn’t attract developers because getting _any_ value out of it requires too much investment.

And if it’s too ready or doesn’t solve a problem you have, why you would get involved?

I.e. if open sourcing isn’t done at start, it should at least be done before SW (design) is “ready”, it should have at least some overview documentation to help people delve into code and there should be clear & easy processes on how to contribute and get involved with the future direction of the software.