Microsoft is going big on “inner source,” trying to apply open source principles to internal engineering. If you think that sounds backwards, given that Microsoft is arguably already the world’s biggest open source contributor (as measured by total employees actively contributing on GitHub), you clearly haven’t worked for a large company trying to break down internal barriers to collaboration.

In fact, as some companies find, full-fat open source may actually be the easier way to achieve internal collaboration.

Why open up inside?

If you’ve worked for a large enterprise, you know how difficult internal collaboration can be. Just because two engineering teams share the same firewall doesn’t mean they open up code repositories to each other. Nor does it mean they invest the time in documentation to make it easy to consume their code, even if repository access is open. Indeed, the only thing engineers within the same large organization may share is an employee badge.

SEE: Open source vs. proprietary software: A look at the pros and cons (Tech Pro Research)

Which is why inner source can be a game-changer. As Mary Jo Foley has written on ZDNet, while Microsoft didn’t invent inner source, it may be one of the largest efforts to implement it within a Fortune 500 organization:

Open-source principles such as more open code sharing and editing; the ability to create new code branches for greater code reuse; code testing becoming a part of the programming process; more and better documentation are core to how Inner Source can/should work. Inner Source tools and methods can be used to develop open and/or closed-source projects and products. Unlike the case with open source, these processes are meant to be shared by teams across a single organization, not necessarily by the public.

All of this makes sense, and should help engineering teams collaborate within an organization.

Open, but maybe not 100%

For those too impatient to wait for yet another program to make headway, open source community guru John Mark Walker has offered another hint: Go all the way with open source. As he reasons, “One of the little known secrets is that [open source] allows eng[ineering] teams in the same company to collab[orate] without management getting in the way.”

Of course, if engineers go this route, they need to be careful about exposing sensitive data along the way. There can be, in fact, too much transparency. For example, in an attempt to operate on public GitHub, I’ve seen product teams link to closed documents. While only those with the right credentials can access these files, anyone can see the URL, and that URL may well contain information that really shouldn’t be public.

SEE: How to build a successful developer career (free PDF) (TechRepublic)

Or take another seemingly innocuous practice I’ve seen, with product teams linking to feedback they’ve received (again, on public GitHub). In some cases, that feedback may reveal download numbers, product adoption, or other data a company may prefer to keep private. As one product leader told me, “I see a ton of benefit to having the code in the open, but having the discussions in the open seems like a field of landmines and limits how much my team and I feel like we can contribute to the conversations.”

In short, open source can be a great way to collaborate within an organization and across different organizations, but particularly with projects where a single company dominates, we can become too casual with private information that has no place on public GitHub. By the same token, some inner source-type conversations are also best kept within a single team, though having the code repository open to others (and documented well so that it’s accessible by others) is almost always a good idea.

Microsoft is figuring this out, both in terms of inner source and open source. You’d do well to follow, while making sure you don’t reveal everything that goes into making that product sausage.