A recent report suggests that Microsoft may open source its M# language upon its as-yet-to-be determined release date. M# is a language being developed in tandem with Midori, a research operating system Microsoft is also developing and, apparently has been developing since 2008. In many ways this plan to open source on release is an excellent demonstration of a classic misunderstanding of open source and the audiences for open source. When Microsoft people talk about releasing M# and open sourcing it, it strikes me that the company still doesn’t get open source as a development process and still sees open source as a deliverable, as something you do to clear some check boxes or unlock a market.
The “open source as a deliverable” approach is a perfectly valid way of creating an open source software if you assume that for the thing to catch on it needs to be ready to roll. This can be because you perceive the people who will use the code as predominantly end users rather than developers because you are making software for them to use in the form of, say, an application. If you believe that at release, end users will begin using the application, and that as a secondary effect, developers with a specific interest or other motivation use the open source code as an opportunity to develop and contribute, and, all going well, the project will develop momentum, then yes, it is a valid way of open sourcing a project.
But that doesn’t hold true for development tools and languages; by definition your users will be developers, they are just not yet developing of your tool or your language. Every user is a potential developer for your project or a source of feedback on design. No user of tools is without an opinion on their tools or a desire to craft a better tool. If you go down the “open source deliverable” release path though you’ve already not made use of that resource and are sitting at version 1.0 having internalised all the development processes within your organisation. When the release does occur you’ll now have all your internal processes grinding against outside contributions.
It gets worse though as the longer you take to get to 1.0, the more established those internal processes are, the louder and harsher the grinding. And all of that is assuming developers even want to get on board the open sourced language or tool you’ve released – they can easily come to a conclusion that if you’ve made it to 1.0, plans for 2.0 are already nailed down and if developers want to do anything meaningful setting a direction for development, version 1.0 is more a flag for them to fork the code base and do their own thing.
For development tools and languages, open source isn’t just a way of delivering code to users and ticking a check box. At its most powerful, it’s the core of an open development process which creates an engaged ecosystem of developers and tunes your internal organisation to working with that ecosystem. “Release early…” is core to that process; developers understand that releasing an open source version 0.1 of something isn’t saying its is anywhere near complete but releasing a 0.1 does let people look in on what is being created and if your code, and associated documentation and writings, convey what you are planning in a compelling way, it will bring people onboard. And that will provide the seed for a meaningful open source development process.
Some might ask won’t opening the development process early like that disclose other proprietary plans that your organisation may have. The simple fact is that if your work is closely enmeshed with those plans such that it is visible in the code of your project, your project probably isn’t a good candidate for being open source anyway.
Be aware from the start that this doesn’t all work like magic and you will have to drive your vision forward with the project and actively engage with the outside developers and users, but that friction can be a powerful constructive friction in a process which can scale up over the time it takes to reach version 1.0. By the time you reach 1.0, you will already have a community of developers around your project… and that’s far more potent than just dropping an open source deliverable at release.
It’s probably too late for Microsoft’s M# to benefit from this approach, but if you are planning on creating a open source tool or language or something else aimed at a development audience, remember to open your development process too.
This article was imported from the original CodeScaling blog