The Eiffel Tower was erected for the Paris World’s Fair in 1889. Nobody much liked it though, and the plan was to let it stand for twenty years, and then tear the horrid thing down. But, here we are, over 100 years since its planned demise, and the Eiffel Tower has become a symbol of all things Parisian, the city of love. What saved it, in the end, was the invention of radio, when some smarty took one look at the the massive towering grid of steel, and thought Merde! Une antenne!
Like the Tower, in open source we rarely set out to achieve what we end up with. Sometimes, we set out not really having any idea what we want to achieve at all, and then we just spend the whole time rolling with the punches. Neither is necessarily bad; in open source, those approaches tend to work just as well as any other, most of the time. Where it becomes difficult, though, is when working on upstream becomes part of your job description. All of a sudden, you have to try and fit the square peg of open source into the round hole of your day job. So where you once had a process of “find something interesting, and then work on that”, you now have a process that involves planning, metrics, deliverables, and probably Gantt charts.
I knew about Linux fairly early on. I didn’t use it of course, I was a Business student, not some nerd. All of which meant I knew about Linux, but I didn’t understand it. Understanding came later, when I picked up an Information Systems major (much to the confusion of my non-nerdy friends, and still to the confusion of my parents). This was in the mid-nineties, so it was also around the time I discovered many new and exciting things: like IRC (a text-based chat system), the early years of Google (back when it was just a search engine), and open source. Some might say that my destiny was more or less set right from that point.
Fast forward a decade or so: I’ve gotten married, had a daughter, and somehow landed an office job at a startup that is only barely funding my MBA and my divorce proceedings. The CTO (employee #3) was an open source nutjob, and along with teaching me what a tech writer was (and blowing my mind in the process), he also managed to reignite that fascination with open source that I had first discovered during my undergrad. As far as I could tell, he achieved work by typing binary directly into the Linux kernel. And while I figured I’d never get to that level of wizardry, I was pretty proud of myself for learning LaTeX out of a book, and actually managing to produce useful technical documents for the company.
Sadly, like many startups, the dream didn’t last long, so when they missed my third paycheque in a row, I started looking for new opportunities, this time armed with a working knowledge of open source, and a desire to write documentation. After some tumbling around, I landed in Brisbane, Australia writing tech docs for Red Hat, rose into a management role, and was then offered a similar role at Rackspace about a year ago. So here I am, with nearly a decade of experience in working in enterprise-level open source documentation.
For those of you who haven’t been lurking on the edges of the open source world for the better part of a quarter of a century, open source tends to fall into two main categories: the single person project that starts as a simple solution to one problem and never really grows much past that, and the bigger more organised project that organisations start to notice. Projects like OpenStack, Libre Office, Inkscape, and Linux itself all fit into this category. When a company starts wanting to offer these products to their customers, they usually hire staff to work on an internal version of them that they can tailor to suit their needs. In this situation, the open source project is referred to as the ‘upstream’ or ‘community’ version, and the branded version produced by the company is referred to as the ‘downstream’ or ‘enterprise’ version.
However you fall in to this weird world of enterprise-level open source, it always starts out with that amazing feeling that someone is paying you to work on something you were perfectly willing to do for free. Eventually that wears off, though, and you find yourself in a place of competing deadlines, mismatched workflows, massive differences of scope, and oddball enterprise requirements. The first thing that will probably be apparent to you is that, despite wanting (or needing) to do more or less the same work on both your enterprise and upstream projects, you probably hold different roles in each group. You could be an entry-level programmer at your workplace, with a core role in upstream; or a manager at work, but a plebeian technical contributor in upstream. Even if you have relatively comparable levels of seniority in both, those roles will necessarily mean different things in each group. This is naturally going to lead to your first real issue:
How do I organise my time and achieve any kind of work/life balance?
Like many lists of hints and tips, this one also starts with the obvious: get organised. As soon as you know your enterprise release dates, let your community know that you won’t be around much during that time. Likewise, make sure your company knows when you’re busy with community work, too.
You won’t always have control over release schedules, especially in bigger projects, but if you do, try and stagger them. Having enterprise releases a set period of time (a month or more) after a community release can be a really good way to do this. This gives you time to take the community release and fiddle with any content that you need specifically for your enterprise customers, and also allows the community time to find and fix the bigger, more damaging, bugs.
Always prioritise your time and pick your battles. Don’t spend three days nursing a non-critical patch through the review process, or arguing over a minor technical point on a mailing list if you don’t have to. If you’re lucky enough to be in a management or senior community position, then delegation can also be helpful. Consider assigning a proxy to attend non-essential meetings or monitor mailing lists.
Finally, don’t fall into the trap of doing only enterprise work while you’re in the office and your boss is watching you, then doing all your community work at home after hours. That’s a recipe for burnout, regardless of how much you enjoy doing the community work. You still need to make sure you get time with your friends and family away from the computer, hit the gym occasionally, and get in some all-important couch time.
How can I be a good community member without looking like a company shill, *and* keep my job?
It’s natural to assume that there will sometimes be conflicts between what your company and your community wants. The best way to handle this is to have already created a culture of honesty and respect in both groups, but that is often beyond your control. Whatever the prevailing culture, though, you can always create your own reputation. Doing this right from the beginning will not only help you when trouble arises, but should also help influence the community’s culture too, even if it’s only in a small way. (If you’re interested in hearing more about creating culture in technical writing teams, come along to my presentation “8 writers in under 8 months: from zero to a docs team in no time flat” at linux.conf.au in Auckland, New Zealand 12-16 January, 2015. The talk should also be made available as a recording after the event)
To create your own reputation, start by being honest with both your company and the community. If you’re pushing a feature upstream because your company wants it, say so, and consider it a use case. If your company has customers wanting a feature then that’s a good reason to do it. If there aren’t any customers asking for the feature, though, question the real reason why it’s being requested, and don’t just pull rank and shove it through the upstream process because your boss told you to.
In order to keep your job, and to keep on being able to work on upstream, it’s important to make sure your company understands what you do in the community. It’s a good idea to have your upstream responsibilities enshrined in your job description, and reinforced at performance review time. If you can, make community contributions and achievements (lines of code, number of patches accepted, achieving more senior community roles) a performance goal. The other side of that coin is to make sure you’re actually doing it. Even if you’re super busy with an enterprise release, spend a little time every day on community work. Even if it’s just triaging a few bugs, or completing a code review or two over your morning coffee. It’ll help the community to not forget that you exist, and it’s a constant push of effort you can show your manager when you need to justify your existence.
How do I get the stuff in the enterprise version into upstream, and back again, without losing my mind?
This is obviously going to be different with every project and every company, but the main thing to do is to create a system. It could be tools based, or just a method of organisation. Perhaps keep a log of things that need to go up or down as you come across them, then check things off the list once they’re done. This is easily achievable with a Kanban board (either sticky notes on a wall or one of the many internet-based tools), and they’re especially useful if you’re working with a team.
It’s also important to be realistic. Don’t just take things upstream (or down) because you wrote them and you think they’re pretty neat. Make sure they’re valuable contributions that suit your stated use case. The audiences for enterprise and upstream will often be different, and different content will be required to satisfy each. That said, always be as fair as possible. Don’t be all take and no give, or vice versa. It’ll only erode your goodwill with the community, or make you That Guy at work. No one wants to be That Guy.
How can we make this better, and less painful? Won’t someone think of the yaks?
Until we’re all plugged mentally into the Internet of Things, and all thought becomes networked, this is likely to remain a difficult problem to solve. Every community and every organisation is different, sometimes radically so, which means trying to get two to work together can be like picking two random cogs and hoping they fit. Sometimes, miraculously, they do, and sometimes there’s just a grinding of gears. Often, though, they fit imperfectly, and those are the ones we can work with.
It’s important that enterprise and upstream are as aligned as possible, and that the organisation has an understanding of upstream concerns. This can often depend on whether your organisation was grown with open source as a core consideration from the beginning, or they only decided to go into upstream later on, as it will massively impact the prevailing company culture.
That said, even a company that decided to work with open source last Wednesday can be taught how to be a good corporate open source citizen. Firstly, the more people working on upstream within your organisation, the better the organisation will get at it. You also want to avoid being the single touch point between your company and upstream. If your company is hiring, make sure you spread the word around your community, and if you find someone looking for work in your community that would suit your organisation, make a case to get them hired. You also want to make sure that you talk about open source with your management team as much as possible. The more your manager understands, the better able they will be to talk about open source to their manager, and so on up the chain of command. If, one day, the CEO declares an open source strategy, then you know you’ll have gotten somewhere.
Finally, don’t be disheartened if you sometimes feel like you’re working two full-time jobs, fighting fires in one and saving drowning kittens in the other. Take a holiday, and when you’re refreshed look at your processes again. If you can take a step back from the trees, you’ll see the forest more clearly and work out the little things you can implement or change to make your life just a little bit easier. Don’t give up, the open source world needs all the corporate advocates they can get, and with your help both your company and your community will be better off in the long run.
This article is the text version of a presentation of the same name to be delivered by Lana Brindley and Anne Gentle at the OpenStack Summit in Paris, France on 3 November, 2014. The talk should also be made available as a recording after the event. It first appeared in article form in the Society of Technical Communicator’s publication Southern Communicator.
