This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Where's the beef?
One of the trickiest questions in inner-sourcing is, “what’s the relationship between the organization and the community?” Stormy Peters, recently elected as Executive Director of the GNOME Foundation, points out that there are sometimes three parties to this question: the organization, the community, and the governing body. She’s pleased because she can now contribute to an important open-source community and effort. I’m more pleased because the formation of the GNOME Foundation means that this important open-source community has increasing ability to determine their own direction, independent from any particular corporate agenda.
That independence is crucial to inner-source communities as well.
Wait, wait, wait: what did he say?
“Inner-source” means applying open-source techniques for the good of the organization, right? How can “independence from any corporate agenda” be important for “the good of the organization”?
There’s a lot of stuff about running a company that’s just known, assumed in any conversation, implicit in any plan. It’s not “not talked about” because it’s shameful or secret, but simply because it’s so obvious. Right at the very top of that list is the trivially obvious goal, “to make money.” Every company exists to make money; if that’s not your goal, you organize as a Non Profit Organization … that’s what “non-profit” means. If you’re not an NPO, you’re here to make money. I don’t say exclusively, nor let alone pathologically or brutally or anything like that, but none the less, this is your goal. Nobody bothers to talk about that; it’s obvious, assumed. (And I have no problem with that: capitalism works best, when it works at all, by positioning the profit-making possibilities in places that benefit society.)
The need of the organization to make money naturally devolves (and again, I have no fundamental problem, here) into the need for each sub-organization to show its independent value. It’s the old divide-and-conquer, command-and-control, hierarchical organization idea: my success is judged by adding the successes (and subtracting the failures) of those who report to me. You gotta admit this approach has a lot going for it: it’s the basis of every military, economic, and political empire throughout time, and the unanimous recommendation of all the successful ones (and who cares about the others?).
But when you’re forming an open- or inner-source community, you succeed (or fail) by different rules. It’s not enough to “scratch one developer’s itch,” because then no other developers will ever show up to help out. So also, it’s not enough to scratch one corporate itch, for just the same reason. Always granting the real and fundamental requirement that the organization needs to make money, the “goose that lays the golden eggs” of inner-sourcing requires a different perspective: the progress of the inner-sourced projects needs to serve some other goal: the project itself, its coherence, it’s features, it’s reliability. To create a vibrant inner-source community, you need people with just a little bit of spare time and attention to attend to something other than the immediate needs and goals of their direct manager. It needs to be a community, interested in the success of all, not just a dictatorship on behalf of the gains of the leader.