Have you ever jumped off – or even out of – something that existed rather higher up that you’d have liked? I once got to climb to the top of a telegraph pole, stand on top of it and then jump to catch a trapeze swing suspended above and a little way away from it.
This experience came with two negative aspects. The first of these was the sledging I got from a group of adolescents watching me whilst I wobbled my way onto the top of the pole. There is no graceful way of climbing onto the top of a telegraph pole in a stiff breeze. “Are you a little teapot?” was, however, an overly direct way of pointing this out. 
The second negative aspect was discovering that climbing up onto something before jumping from it is easy up until the point where you have nothing to hold onto apart from thin air. At this point my brain decided something was badly wrong and tried to shut down my ability to perform a simple jumping task by issuing urgent alerts. These alerts were rather uncomfortable and said something like “danger: you are about to fall and die whilst looking like a grown man trying to perform ‘I’m a little teapot’”. 
All the wrong reasons
I’ve internalised the cadence of the digital service standard’s catechism over a few years. In my experience the point most likely to cause a visceral “but we can’t… because and… and… well I can see why you might ask other places to do it but it’s not really possible for us” reaction is point 8: make all new source code open.
I think the reason for this is that it’s a cultural change. It’s what Eric Raymond is talking about when he says:
I believed that the most important software needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation” 
It’s not an ask for a slow, gradual change. It’s an ask for a change that initially feels like leaving all support behind you, slowly pulling yourself up to stand unsupported on something tall and wobbly while the wind blows around you. And then jumping.
Learning to fly
Just as I had a harness, there are a few things that you should do before leaping into sharing your code. Working out how to make code accessible, what licence you should use, how to handle a change from an external contributor, who gets contacted if someone external spots a problem in the code and making sure that people are aware of this process are all things worth doing. Anna Shipman, former Open Source Lead at GDS, has collected some helpful resources that cover a range of concerns (yes, including security) and this is an old but useful post from Mozilla.
My experience of being part of this process is that there’s a lot of people who will have a vested interest and they will have different experiences, backgrounds and concerns. Simply setting out an approach isn’t likely to get you very far until you address the thoughts and concerns that exist. If you can get everyone  together to discuss, then you’ve got a good chance of agreeing a process.
Terence’s 11 barriers post and 18f’s shared experiences of working openly are helpful here but make sure that you listen to the views around the table in your organisation before getting tempted into thinking that there is no possible case against what you’re proposing. There probably is, and you’ll be better equipped to facilitate change if you know what this is, and what you need to resolve or check for before starting. (For example, releasing code that has a set of plain text passwords that allow access to sensitive data is bad for many more reasons than the fact that you’ll find it hard to persuade anyone to release anything in the open afterwards.)
Sometimes this conversation will mean initially agreeing to a process that both goes too far and doesn’t go as far as some people in the room would like. One example of this is to agree a per-sprint review and release of code as an interim step towards working more openly. This might not achieve everything you want straight away, but it will build trust that bad things are not going to happen. And if that’s trust among people who’ve never considered the possibility of working like this before, then perhaps that’s a good first step.
Too good to be true?
Why is this worth it? It’s partly because “one of your outriders may well find a huge win nearby that you were just a little too close focused to see”  and it’s partly because doing so makes you part of a huge community, which might be able to help you:
openness is key to scaling everything. It is how we influence the system, how we inspire and enable people to individually engage with and take responsibility for better outcomes and innovate at a grassroots level. It is how we ensure our work is evidence based, better informed and better tested, through public peer review. Being open not only influences the entire public service, but the rest of the economy and society. It is how we build trust, improve collaboration, send indicators to vendors and influence academics. Working openly, open sourcing our research and code, being public about projects that would benefit from collaboration, and sharing most of what we do is one of the greatest tools in try to scale our work, our influence and our impact.”
It’s also because there’s a diversity aspect to widening the group of people who can be involved in creating your product. As Allen Gunn says, “working in the open changes those geometries of ownership. It means a much broader and more diverse set of stakeholders feel they have a hand in creating, envisioning and bringing the outcome to bear — whether it’s a piece of code, a body of work, or any other advance.”
Finally, the community may be able to use something that you’ve created to help make something else. Eric Raymond notes that most great software starts not from zero, but by modifying something that exists:
“Linus Torvalds, for example, didn’t actually try to write Linux from scratch. Instead he started by reusing code and ideas from Minix, a tiny Unix-like system for PC clones.”
Your little fix could actually become the foundation for something that changes the lives of people on the other side of the globe via the internet. You’ll never know unless you open it up.
Built to last
My telegraph pole jump was successful, unlike my first try at abseiling. With abseiling, the over the side bit was similarly scary but rather than telling me I was going to die my brain simply insisted that swiftly returning from a horizontal to a vertical approach was a good idea. It wasn’t. In a similar way, I’ve seen people release a limited amount of code, or some research findings, and then retreat to their comfortable cathedrals.
Publishing something – whether code or research findings or ways of working – openly is an important step. In my experience, it’s often the best first step for an organization. But you’ll only realise the full benefits if you use this experience and go beyond this to work fully in the open, where publishing and sharing things  becomes a default to the extent that people only notice when you don’t publish.
Whilst the rewards are amazing, it takes work to remain open. To continue to publish findings, write blog posts, share work even when you’re not sure where it’s going to take you all takes time. That’s why I have asked in the past to have working in the open as part of my formal objectives. This made sure that I had approval to spend time on being open, but it also made sure that I was regularly challenged on whether I was doing enough to be open.
Into the great wide open [reprise]
Working in the open is driving-abroad-for-the-first-time-in-the-dark-with-strange-noises-coming-from-the-brakes-while-telling-someone-that-you-love-them grade scary. You should still do it and you should still do it not just because it’s the right thing to do. You should also do it because it’s genuinely a thrilling, enriching, addictive thing to do. It makes you feel better. It makes you better. And it makes all of us better.
 To be strictly accurate there was another word between “are you a” and “little” but I’ve redacted this in case my mum is reading.
 This was over-dramatic. Falling might have involved hitting a few things, but I was wearing a harness that I’m reasonably certain would have removed the death part of the equation.
 This can be a lot of people: representatives from multiple teams; heads of information security, architecture, software development, infrastructure; service managers… Don’t let this put you off.
 Eric Raymond (see ) again.
 I’m using “things” here because this is about more than code: it’s also about research, designs, working practices, thoughts, findings, and – as far as I’m concerned – any artefact that allows a team to work in the way that it does, right down to the playlist that accompanied the creation of something.
 Random extra footnote for people who read them all for completeness. If you’re wondering why I didn’t include the reason why I did the telegraph pole thing at the beginning, I was hoping that you might think that I was training to be a spy or a stuntman or something dramatic. The reality is that I was a council youth worker on a project working with young people from highly deprived inner-city areas. And to be fair to them, the adolescents sledging me later acknowledged that my telegraph pole jumping skills far exceeded my abilities on the PS2.
Also, I wrote a draft of this on the day that Tom Petty’s death was announced. The subheads are therefore in his honour. [Yes, I know that was a long time ago: I like to kid myself that my blog post drafts folder is more of a wine cellar than a morgue.]
And a final jump that’s worth seeing for nothing to do with ridiculously extended metaphors:
— Mo Downey (@madmo55) August 1, 2017