)
Isabel Drost-Fromm is a true open-source believer who also knows how easy it is for companies to stall on the road to collaboration.
She’s a director of the Apache Software Foundation, co-founder of Apache Mahout and an active supporter of the Free Software Foundation Europe who describes herself as “just another humble software designer.” At the recent Free and Open Source software Conference (FrOSCon), she gave a clear-eyed talk about the problems people typically encounter when trying to adopt “inner source” and how to get past them.
For years, she says, people active in OSS projects have tried to bring the collaboration practices to their in-house teams. The resulting practice has been called by a number of names: open development, internal open source, inner source.
Now an open-source strategist at Europace, for the past year she’s been piloting inner-source efforts at this Berlin-based fin tech start up. As part of that campaign, Drost-Fromm has been following the development of and contributing to innersourcecommons.org – a global, cross-organization initiative to further practices that “apply the lessons of open source to all software engineering, using collaboration and transparency to increase quality, speed and developer joy.”
Don’t touch my cheese
But before joy, she says, often comes pain. For starters, even what seems the most obvious step can backfire. It’s good practice to make everything public, for example. You might use GitHub enterprise or hosted Git, so that everything’s discoverable. You need a means to submit code, make changes to projects, so the solution seems to be to put it all on GitHub or whatever your source forge is.
“Except that’s not exactly how it works. It’s a big cheese problem,” she says, attributing the concept to fellow inner-source thinker Denise Cooper.
Let’s say you have two teams team, A and B. Team B wants to reuse what Team A created. They find some issue, start fixing it and then submit a pull request. Team A says, “Hey, this pull request doesn’t follow our coding guidelines…And we don’t need this pull request, it’s not in our prioritization chain.” Suddenly everything has to be rewritten. Then Team A and B, both in large companies, escalate to management.
“So suddenly you are you’re back to where you were before, maybe even the inverse situation where everyone thinks that inner source is bullshit,” she adds.
Uncover the assumptions
Behind the code, there’s a hidden framework that Drost-Fromm says can also create roadblocks and misunderstandings. A couple of important ones include different working styles and undocumented working best practices within teams. “Even if you have rolled out a common coding standard across your company there’s different structures and those structures are often not documented,” she explains. “New team members enter a mentorship phase, but there’s no like mentorship phase for someone from another team contributing just a single patch.” There can be a fear of contributing, she says, because suddenly you’re no longer in your “safe team” where everyone knows your quirks.
Reach out and ping someone
To short-circuit misunderstandings and time-to-merge, try a ping. “We have found that pull request take ages, pull request reviews however are faster after a direct ping,” she says, adding that for those working in open source it like sounds familiar advice. “You want to publish your work very early and make transparent what want to work on to get early feedback.”
Mi casa es su casa
There is a way to deal with the “I-don’t-know-how-these-people-are-working”problem, she says: Create some house rules in the form of a public document. “I have to accept the rules of the other person, if I’m visiting you at home. You tell me how to behave. If I’m visiting, you’ll tell me what what kind of problems to fix, what to expect. Like if you stay in my flat for awhile, I will tell you not to turn on the dishwasher and the washing machine at the same time or the fuse will blow,” she says.
It can be a bit more complicated than because the community guidelines could potentially cover coding conventions, testing conventions, branching conventions, commit message conventions, steps for creating good pull requests, etc. “If you write all of that down, will anyone ever read it? Probably not,” she admits. That’s why the inner source guidelines were written whenever something went really wrong, “when something fell on the floor” she says.
Catch the whole 37-minute talk on YouTube.
- Exploring the Open Infrastructure Blueprint: Huawei Dual Engine - September 25, 2024
- Open Infrastructure Blueprint: Atmosphere Deep Dive - September 18, 2024
- Datacomm’s Success Story: Launching A New Data Center Seamlessly With FishOS - September 12, 2024
