Blog by Sumana Harihareswara, Changeset founder

08 Sep 2022, 12:01 p.m.

Reluctance To Process Contributions, and Tips from InnerSource

So there's a software development approach, borrowing techniques from open source for use within an enterprise, called InnerSource. It's "the use of open source best practices for software development within the confines of an organization." (Generally, people outside the org cannot view the source code and certainly can't contribute to it, but everyone inside the company can view it, and different teams can more easily collaborate to improve software they both rely on.) I haven't yet worked with an organization that was doing this, but I can grasp why a company, government, etc. might go this route.

And one interesting thing about InnerSource is that its practitioners and advocates are used to dealing with complex institutional environments with multiple trust boundaries. A big reason to introduce InnerSource is that colleagues on different teams have trouble working well together. Maybe my team doesn't trust the quality of code you're likely to merge into the codebase, or maybe the changes you want to make will get in the way of us meeting our deadlines. And that's a situation that we also experience in grassroots and multi-institution open source projects -- I discussed part of this friction, different contributors contributing at different rates and in different rhythms, in my talk on cadence shear earlier this year. So, just as InnerSource practitioners learned from FLOSS and reuse its social and digital technologies in a proprietary setting, we open source practitioners can borrow lessons InnerSource folks have learned.

This came to mind the other day as I was talking with a colleague about the fundamental reasons why some open source projects are procedurally but not substantively open, and how to mitigate the problems that friction causes.

For instance, civic technology nonprofits sometimes release tools as open source, and say they want to collaborate with other users and makers of related tools, but have a hard time genuinely negotiating with contributions or suggestions.

This especially slows down possible changes that affect fundamental strategy or architecture, but also reduces a user's chances of making smaller fixes. One of the benefits of open source ought to be that it's easier for users to suggest or submit little changes that would solve their irritations, and to get those changes incorporated into the next release. Sometimes that's as small as an updated hyperlink in a caption on a form.

Of course it would be great for projects like this one to develop strong multi-institution governance, so all their users can have a voice on the project's direction. But that change can be slow, if it's possible at all. And in the meantime, if users can't successfully get even superficial patches merged upstream so that the tool will suit them better, that's demoralizing, and the user's more likely to fork or switch to a more traditional proprietary-vendor solution. It's even worse when the maintainers don't offer the mercy of a quick rejection, but instead silently leave contributions in limbo, or make faltering gestures at processing them but don't follow through, so the users have a hard time planning what to do on their end.

So, how do organizations practicing InnerSource deal with this kind of reluctance to accept contributions? Here are a few relevant InnerSource patterns:

Trusted Committer: systematically and formally notice specific outsider contributors who are consistently helpful, and promote them to Trusted Committer status. They're not maintainers, but you fast-track their contributions, keep them apprised of new plans, and regularly ask for their advice.

30-Day Warranty: "When accepting contributions from outside of your own team, there is a natural aversion to taking responsibility for code not written by the team itself. Through the 30 Day Warranty the contributing team consents to provide bug fixes to the receiving team, which will increase the level of trust between both teams and makes it more likely that contributions get accepted."

Contained InnerSource: Adjust and set everyone's expectations to match reality. "Apply InnerSource methods to facilitate collaboration in a cross divisional project but don't invest in soliciting contributions from outside of that project....limit the scope of InnerSource practices to the project. No effort will be spent on facilitating and managing contributions from outside of the project."

I'm grabbing these ideas and putting them in my toolbox so I can consider reaching for them the next time I notice a team or interface stuckness around this issue.


Sumana Harihareswara
12 Sep 2022, 10:29 a.m.

Now that I've gotten the ok to mention it -- the colleague I was talking with was Dave Zvenyach.