Archive for August 2011
Backstory: I’m spending some time trying to find 10 spare gigs on my laptop to house the monster Xcode 4 install. During the cleanup, I’ve unearthed several dozen bog bodies from my previous software and employment versions. Some are embarrassing, but they are like eccentric relatives, I cannot bring myself to deny them, plus I enjoy seeing the effect they have on other people. So, rather than throwing them out, I thought I might share them here so that we can all have a laugh.
This one was from when I worked in an Open Source organization embedded in a Closed Source organization – when OSS suddenly became trendy in Enterprise Software. It was a draft of a primer of how to do Open Source When You Have No Idea How It Works, meaning how to take part in projects and run a stable of OSS developers successfully. I don’t think it got beyond a second draft. I still think OSS is a better way to do most things, however it does have its own pathologies, which at least are fairly visible.
Committing to Open Source
So, you want to try out this OSS thing. It’s the new hotness in the press, and your competitors are all about competing only on the 20% and contributing to and using Open Source for 80% of their delivery. You could get fired if you don’t jump on the bandwagon. Measuring your success is crucial. Your old metric of revenue linked to products won’t really work with Open Source. You will need to build a force of highly-competent developers that can consistently deliver value to customers.
OSS is a services engagement in most cases. Customers must be kept happy – you need capable and competent developers and you got to have a plan to keep them coming on-stream. This is vital when you are dealing with potentially the most mobile workforce in the world.
Key Aspects of Open Source (OSS) vs. Secret Source (SSS)
- SSS is about chain-of-command
- OSS is about tribal pressures
- SSS is about running a factory
- OSS is about being a patron
- SSS is about being regulated and policed
- OSS is about self regulation by application of taboo
- SSS success is about moving up the hierarchy
- OSS success is about moving out into the world
Patronage in OSS
You are a patron. Think about how that model works – those receiving patronage want to practice their craft. Those giving patronage want to enhance their standing amongst their industry peers. By enhancing their standing the patron can build a reputation and upon that, a dominance.
Those receiving patronage will brook some interference in the execution of their tasks, but not much, so you need to maintain a loosely-coupled connection to the body corporate. This can be difficult. You need someone who has trust from the stable of developers, and also can communicate the corporate messages in a way that makes sense – really this is not about spouting corporate goals, but being able to construct competitive challenges like – “We want to kill XYZ, how do we do it?”, or “That QRPX repository looks good, but we can do better”. Basic, tribal goals, not code-speak for corporates, no mission statements.
OSS developer is a highly mobile position. If you are a good patron, your reputation will spread. You build the reputation for a year or two, then you can start trying to poach names from the other projects that you are up against, poach the bloggers, do this by word-of-mouth. Every single one you persuade will give you PR you can’t manufacture. You are also hitting those projects where it hurts, by taking their staff directly.
How to be a Good Patron
What you do is strengthen each developer’s community immersion. One of the big winners is to increase their physical presence in the OSS milieu. Allow each developer to attend two conferences per year, more if they are speaking. Profile the conferences, and make places available, limit them to encourage submissions. Review your guys’ blogs and suggest topics to them, keep feeding them competitive nuggets. You also need to let them investigate stuff that is new and interesting. Some small-scale and locally-constrained brownian motion is fine, as long as the general trend is moving forward. Make sure you send them to competitors’ conferences, even things like Microsoft conferences. These people are your eyes and ears, developers are mostly honest, and they will give you a level of relevant information you have never had before.
Making Good OSS Developers
Firstly, keep the ones you have. If you are a Good Patron, your attrition should be tiny. However, you need to educate developers to turn them into OSS developers, it is not an instinctive thing. Programs for committership must be established. A mentoring system must be present. Committers must be regularly assessed on their contributions in the areas of Code, Documentation, Bugfixing, Customer Queries, Outreach (blogs/speaking/etc). Developers must have training and committership in more than one project, and may move on to project-centric, or customer engagement-centric majors. Competencies need to be tracked, and gating system put in place for customer engagements, based on using this competency system. This will help keep a strong reputation for technical and product capability in field assignments.
Some of the Roles/Structures You Need
Much of what follows is stating the obvious. There is a strong bias toward the developer satisfaction theme here, since that is the element that is the most different in approach to the SSS method.
- The Project Selection Group – a small group that discusses and decides what projects to be involved in, what to pull out from, what projects to start and promote, etc. Meets quarterly and produces auditable decision trail. Revisit decisions on substantive grounds only after a test period to ensure commitment.
- The Community Manager – one committer in a project has the role of Community Manager. They have a number of responsibilities. One is as the eyes and ears of the project selection group as to the state of the project, community health, diversity, etc. Another is to help to ensure the smooth running of the project and its delivery to users, so community manager role should be strongly biased towards repeatable builds, good website material, strong demos, blogging about the project, outreach at conferences and the like. Also this person is responsible for gauging developer performance in the project (doc, code, marketing, customers). One per project. All project leads and community manager folks must blog about the project and aggregate any blogs that regularly mention it. Everyone needs to read these.
- The Doc Team – if one thing adds value to OSS, it’s the documentation. The Doc Team gets close with the community manager to see where the docs are missing, what needs to be done, etc. An enhancement to documentation on the OSS project website is a big plus to the project, but excellent comprehensive documentation is something that people will pay for.
- The Tools team – another value add is pain reduction. Hard-core developers will have no issues working directly with the OSS project elements as downloaded from the website. The great majority of developers will need tools. A dedicated team is required to produce tools and shortcuts to help customers in certain places to increase productivity. Act on feedback from the services guys, other field reps and the community.
- The Distro team – there’s a group of individuals that are responsible for keeping the distributions ticking over and building – they are responsible for nightlies, weeklies, integration builds and the eventual distribution. They make the distros.
- The Test team – team that builds integration tests that are used as smoke tests for distro quality. They also design the tests.
- Web team – don’t have one of these – outsource it, but make sure the developers can update at any time.
- Marketing Support – primary marketers in the OSS community are the developers – they are the reputation enhancers. However more advertizing-style marketing is required that is full-time. Competition is rife in these communities and it goes to the deepest level. Every now and then stir the pot with some controversy. People can’t help but respond. Don’t be destructive – keep the bridges uncharred.
- Administrative Support – office management, expenses, travel arrangements, etc are all things that developers are not so good at.
- Training/Services – competency-based tracking of developers employed to stream capabilities to customers. It is important that every developer takes some time every year to be in front of a customer.
- Legal – maximally important when engaging with enterprise customers. Consider paralegel education for developers, or at least support them where feasible. Employ lawyers who have provenance in this area.
Dealing with the Mud-Slinging
When operating (‘competing’) in the OSS arena, attacks from others can be directed towards the software, or to the organization. Challenges to the software are easily met – if they are untrue, show that is the case; if they are true, then address the issue, and make a show that you have addressed it and that your detractor will have to think of something else to complain about. Attacks on the organization are generally harder to grasp.
The top four muddy missiles are usually the following (where for X insert company name):
- X has not acted in the best interest of the community
- X has been divisive in the community
- X has been spreading FUD (fear, uncertainty, doubt)
- Our software has displaced X in every account we went into
These kinds of accusations are reputation-tarnishers and need to be addressed. Accusers need to explain their assertion, and it needs to be dealt with in the open. They will need to cite examples for any challenge. Be sure to track every single engagement with them at the customer level. Build competencies in competitor product so that you can keep ahead – delegate a team to track and build small systems with the competitor product. Competition needs to be strong and you need to be up to date all the time, and be ready with insight or analysis, indeed produce these regularly.
If you come across failures in competitive products in real-world scenarios, you need to record them and save them for deployment when necessary – for example when you get attacked or when the opponent is in a weak position. Keep references to your own successes.