I recently found a slide I used six years ago to explain open source software in a business context to Jim Allchin back when I worked for Microsoft and Jim was executive VP of all Windows. My job was to develop an open source engagement model, working in a team called Platform Business Management, which reported directly to Jim. Jason Matusow was responsible for driving the Shared Source agenda, initially working in the Windows marketing team and later as an immediate peer in PBM. The meeting itself would have been sometime in June 2003 (so shortly after Sun's threatened injunction against Windows). I tried to ground the tactics in product practices Microsoft already well understood and with company examples pulled from other large multi-billion dollar corporations, i.e. while our shining open source company examples might have been Red Hat, MySQL, and JBoss, they were meaningless examples to Microsoft based on revenue size. The slide worked. Jim understood why Microsoft needed to adopt its own open source practices, and how we might start. [There were other slides in the presentation discussing options for engagement and contribution that are confidential.] The execution was another matter entirely within the software product executive culture of the company, and isn't relevant here.
There are a few things to consider as you read the slide and the notes I used to present additional material:
- The information density of the slide is normal at Microsoft (or was in my day) for exec presentations. It complemented a style of discussion that's come to be known as precision questioning. You simply don't have the discussion and decision making flow required if you're trying to drive a particular train of thought through a slide build and flow. This sort of info density is about presenting the maximum amount of related material visually and letting the exec drive the questions. It's amazingly effective if everyone understands the protocol.
- I've not changed any of the wording on the slide or the associated notes. [There's nothing confidential.] Some things may feel dated, and I've certainly evolved and expanded some of my thinking, but I still stand by what I wrote. There are few words I would change today and while I might pick more current examples, these ones were absolutely relevant at the time.
Here's the slide:
Here are the notes I used with the slide:
OSS Development Projects (technology buckets):
Bullet 1 and 3. Good developers develop good software. Good developers have discipline and process. They don’t know how not to have discipline. So version control, CM, design reviews, strong vision communication, automated build management, coding standards, automated test harnesses, bug tracking, peer code review, strong tool support. All understood and published for decades. None of this is attributable to OSS as a development methodology or licensing mechanism. You can think of this in the inverse: of the thousands of OSS projects hosted by SourceForge, why are so few (relatively speaking) noteworthy? (There's also a couple of good papers on how few people actually anchor the few key projects.)
Bullet 3. The projects in the OSS world that matter are anchored by good developers and they're developed using a UNIX development mentality. They have all been developed since the advent of 'cheap' networking (at least between the universities and major corporations) through the Internet (email, netnews, and ftp). The Internet enabled the rise of OSS -- not the other way around -- and it was the low-friction medium through which people could share the software. Add a license that requires source code publication and permits libre use of the source code onto the UNIX component model and you have the techno-social movement.
Bullet 4. Examples: the individual contributor to Apache (gives “3” bug fixes but gets back 100s), versus Shell Int’l contributions in a team (code/$) with management approval to Samba.org (while deeply protecting their own software assets), versus Sun contributing the accessibility features to the gnome desktop in return for a complete desktop for an advanced “UNIX” based desktop.
Bullet 4. People value the work they do differently in different contexts: think of a technical publications person using their writing skills to complete documentation at work, helping their child’s class room complete a writing project in a parent-child project, and writing a sonnet to someone they care for. Same skill set in all three situations, one for money, one as a contribution in community, one as an act of friendship. Or a program manager that spends time on a not-for-profit board in their community using the same skill set they use at work for money.
So what's next?
Applied OSS:
Bullet 3. Msft is an expert here. Publish specs to drive complement value add. Provide certification programs to ensure lots of service providers. Buy, integrate, and bundle. Etc.
OSS Becomes Big Business
Bullet 2. From IBM’s point of view in the product marketing space: every apache installation is a potential customer for Websphere. From a Linux perspective, they are driving home the message that OSS and Linux are the fulfillment of all “our” investments in open systems and open standards, using multiple congruent tactics of OSS participation, standards participation, and patent license management to control the AIX commoditization – which they publicly state is happening – then quickly qualify the remark to a 10 year time frame. With Eclipse, it’s no longer “buy” versus “build” versus “borrow”, it’s “share” to control the java development space and drive complement value add around their world.
