A community of technology community managers, leaders, and builders.

CLS16 "Inner Source Therapy" session notes


#1

Short introduction to Inner Source by Cedric Williams. Inner Source applies the lessons of Open Source within corporations. The goal is to enable corporations to collaborate effectively accrross divisional and organizational boundaries.

  • Barriers: regulatory, organizational but most importantly cultural. Missing ability and incentivize collaboration.
  • Multiple tools because of risk aversion previously existed. Transparency in GitHub enterprise helped uncover that duplication of effort.
  • Challenge: organization encouraging competition btw. groups or left-hand-does-not-know-what-right hand-does syndrome
  • Even at google which seems to be pretty open internally, the geographic distribution caused trust issues and consequently silos, which inhibited collaboration internally.
  • Autodesk was pretty siloed, too. Challenge here: global initiative to move all (> 150) tools “to the cloud”. Inner Source is used to help drive that forward as a collaborative effort.
  • At PayPal, an internal project demonstrated that increased collaboration can speed up time to market.
  • Are there people who are simply not “wired” to collaborate openly?
  • There seems to be no incentive or recognition for contributing code to an organizational unit other than that of the author of the code.
  • Deputy program: good developers are rewarded with more access, acting as liaison btw. projects.
  • Observation at Autodesk: proposal to breaking up product and component teams to foster collaboration was met with a lot of resistance. Interpreted as sign of fack of collaboration.
  • When is it not appropriate to use InnerSource? One example: legal topics (e. g. licenses), where most developers simply don’t have the required expertise and just can’t know how to make contributions. Example: “hey, there’s a comma missing in that document. Here’s my PR to fix this”.
  • At Autodesk, internal collaboration is a part of internal performance measurement and is thus incentivised. Pretty new measure - currently unclear if it will work.
  • Autodesk is planning to roll out Inner Source training for new hires and existing engineers.
  • Amazon uses videos to introduce new hires to open source. Could be used for Inner Source as well.
  • Most friction in organizations regarding Inner Source is usually encountered in middle management and product management. They have no measurement and bonus for doing Inner Source (they are usually measured by delivery of features). Engineers and C-level mgmt. are usually easily on board with Inner Source, though.
  • At Paypal, corporate wide systems (e. g. company website) are made “Pull-Requestable” to introduce whole company to collaboration Inner Source style.
  • Obvious difefrence btw. Open Source and Inner Source: In Open Source, there is no product management.
  • Compared to traditional development, the amount of communication required to successfully do Inner Source increases by a factor of four.
  • Speed could be an argument for Inner Source to convince product managers. Beware though, that there will be a learning curve for starting Inner Source. The expectation wrt. increased speed have to be carefully managed.
  • Transparency is required on all levels - including product management - in order for Inner Source to work properly. It’s not sufficient to just make engineering more transparent.
  • A problem for Inner Source are ignorant mandates from mgnt. to engineering groups.
  • For Inner Source to work, a culture of ownership needs to be established. Contributions from other teams will not be used easily if the author of the contribution will not assume ownership.

Join us on innersourcecommons.org.


Thanks to for being the kind sponsor for this forum!