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.
The good news today is that it looks like we’ve settled on an office in Capel St. as the place to grow the startup. You would think that getting space in Dublin would be easy – and yes, there is a load of office space available. You would think that you would pay a keen and competitive rate for it too, considering the depressed market, but on that point you would be very, very wrong.
We visited buildings that have lain vacant for two years and the lettors would refuse to lower their prices. This makes a sense in the most perverse way – the financial way, I mean – in that lowering the rental will automatically take value from the ‘apparent’ investment worth of the building itself. These guys are heavily delusional – and they are hurting startup businesses. A letter to Enterprise Ireland has been delivered by the usual suspects.
Back to the venue itself – we’re delighted that we are sub-letting a space from another technology company that are scaling up. I plan to pick those guys’ brains on all topics relating to making startups go.
Capel St is a fantastic street. There’s a mixed-use pub and music shop. There’s pet shops, pubs, camping stores, martial arts shops, adult naughty fun stores, Asian markets, Polish markets, Sari Sari stores, more pubs, chippers, more music shops, Asian restaurants and the highest concentration of Korean Barbecues I have ever had the privilege to see in one place.
Right around the corner is a large cinema, a gym, many second-hand book shops, an early-morning fruit market and 3fe, one of the best coffee shops in Dublin city.
If you go check it out on Google Maps, you will see the street as it was about three years ago, it’s changed a bit even in that short time. More restaurants, less headshops.
At this moment in time we are searching the skips and dumpsters of Dublin looking for furniture to put into this ex-Art Gallery space. Or maybe we are going to just visit Ikea, not sure yet. Once the furniture is in, I’ll be looking for developers to keep the seats warm 🙂
Google has come up with some kind of a like-a-like called +1. For those who may have not been part of an open source development community, ever, you need to know that this convention has been in place since the internet was a child, and Google’s arse was the size of a button. The full remit of of the taxonomy goes thusly
- +1 – I agree, and thanks for saving me the typing
- +0 – I don’t really care, to be honest, but slight preference on it happening rather than not, i.e. I’m emotionally content to be part of the majority here.
- -0 – I’ve no argument one way or the other, but I dislike change, and if there’s an issue I’ll veto this bastard.
- -1 – THIS IS THE DUMBEST IDEA I HAVE EVER HEARD. I CANNOT BELIEVE THAT YOU HAVE THE BALLS TO BRING THIS UP WHEN YOU KNOW THAT EVERYONE THINKS IT IS STUPID. Divers alarums, lying down in the road and Godwin’s Law ensue (exeunt omnes)
Update: Ok, speaker notes have turned up at this point! Also, @matthutchin did a bang-up job of editing some moody video and sound of the talk into this video+slides presentation!
Update: Still no sign of the speaker notes on Slideshare – here’s a bit of ruby to grab them from the slideshow and format them into an HTML page: https://gist.github.com/968161.
This the talk I gave at the Ruby Ireland meetup last night. I think it went over well – there’s plenty of interest in the plethora of non-SQL style databases, but the problem is over population of choice and the amount of time investment required before you can make a properly informed decision. I think the best approach is to try to find as many testimonials from companies that have incorporated these newer technologies into their data storage arsenal, and read them thoroughly. These will epitomise the (fleeting) state of the art.
In an ideal world, there would be a group of volunteers running a funded lab that can create independent assessments of all the different approaches and products.
Versioning in APIs is vital if you want to control the lifecycle, rather than it controlling you. If you are using Sinatra to do routing for your Web API, then you can easily stuff all the version compatibility testing into one place – a filter – and not have to propagate it through all your routes. Follow the gist to see the code.
On May 10, I’ll be giving a talk on Constructing Web APIs with Rack, Sinatra and MongoDB at the monthly Ruby Ireland presentation gig. It will take place at Seagrass in Portobello, Dublin. Kickoff is at 7pm.
I aspire to having the talk slides up on Slideshare beforehand – this topic may be old hat to some of you hard-core Ruby types, but it’s relatively new and interesting to me, and may be so to others. In any case we’ll be looking at some new stuff, in the case of MongoDB and having some fun with it.
Bí ann nó bí chearnóg, mar a deirtear.
Hope to see you there.
EclipseCon 2011 started today, with an awesome program of events going on over the week. I’ve attended the previous four instances of the conference, and had the signal honour to have been the Program Chair for EclipseCon 2010. Now, alas, I’ve lapsed. Instead of getting a nice easy job after my release from Progress last year, I’ve foolishly decided to startup a software business with a couple of guys. I hope this adequately explains my somatic non-presence at this years showcase of what’s wonderful in the Eclipse world. For example – if I was in California today, I would not have been able to load the mobile part of our product on the phone of a friend-of-a-friend who just happens to be attending a concert with the CEO of a division of a large cellphone company, with instructions to show it to this CEO and get a meeting for us. But if I was in California today, I would be enjoying beers with lots of people that are much smarter and much more dedicated than me.
It’s always a tradeoff.
Now that I have a brand new ‘user’ perspective, and am on the outside looking in, there are a few items within the Eclipse Ecosystem that are particularly interesting.
- EGit – I’m using git exclusively now for source code control, and having good support is very important. I think that the real decision-maker on using git all the time are hosting services like Heroku and Nodester adopting git push workflows for application deployment.
- DSL-based mobile device project scaffolding – projects like Applause and Applitude, both based on Xtext and mobl, based on Spoofax, can give you a chunk of starting point code to get your mobile application up and running on the cheap. I haven’t taken as much time to study these as I want to – a future blog entry I think.
- Orion – when I first saw the Bespin project, which then merged with Ace and is now the development-as-a-service Cloud9 IDE, it failed to stir me. However, when I started doing some node.js project experiments, then the option of being able to edit your JS code through the browser suddenly had more appeal, precisely because now you can edit server code. It will be worth a blog entry in its own right at some point (aside – Mr. Orion, @bokowski, just linked to another one, Akshell, a minute ago)
I just realized the other day that the last piece of Java/Eclipse a programming I did was in July 2010. Since then I’ve been in this dual world of the mobile app developer – programming
native code on iOS devices, programming Rails 3 and node.js on the server end of things, pushing data into PostGIS and Redis. I didn’t think I would end up here, but it’s been fun so far 🙂 As to the future, I’ve refused to plan anything beyond world domination for the moment. But maybe I can get an Orion talk accepted for EclipseCon Europe…