For the last few years, along with colleagues at Red Hat, I’ve been of the belief that Inner Source (see Wikipedia definition) is a viable alternative when an enterprise organisation doesn’t want to embrace a full Open Source approach (for a variety of reasons). The differences between Open Source and Inner Source are listed below, but the main difference is that former usually involves more that one organisation and the latter is very much internal to one. Open SourceInner SourceNot always a formal organisationMore likely to see some form of top down formal organisation Open flow of information and ideasSome control and ownership around information flowMeritocracy and Benevolent DictatorshipSome management direction of a projectSocial phenomenonInduced social phenomenonNo budget and time constraintsBudget and time allocations neededPotentially infinite number of developersFinite resource and inputConsumable by allLimited audience for consumption and participationVoluntary teamsPartial voluntary, with allocations Self assignment of tasksAllocation of tasks, resourceLow consideration for competing tasksConstant need to consider alternative tasks and activities Inner source is like Irish dancing, you are in a constrained realm. Open Source lets you fling your arms about like a Scotsman.Malcolm Herbert March 2019 There’s no doubt that having the barrier between an organisation, however large it is, and the outside world is a significant barrier to the success of inner sourcing projects. Inner source projects need constant nourishment as they are not getting nutrients from the outside world. Red Hat’s Office of Technology in Europe does a range of consulting work around open source process and methods, helping organisations leverage the model successfully used to produce software over the last 25 years. In the past an Inner Sourcing approach has been adopted for organisations, where either: there is need to keep the activity separate from the outside worldthat the project isn’t primarily software development However, the effort of maintaining and sustaining an Inner Source environment isn’t repaid. Remove funding or support and it dies. All very Darwinian and while these extinction events also happen with Open Source projects they aren’t so dependent on internal or commercial factors. Inner Sourcing approaches always run the greater risk of duplicating the efforts in another organisation (and the same mistakes) if the work is made widely available. So what’s the downside to Open Source and letting your team collaborate outside the corporate structure ? Being Open Source potentially needs a governance structure that cover what people can and can’t do and understanding of how it works in order to draw these guidelines up (it might be why you were looking at Inner Source initially). There are lots of sample Governance structures out there and some good articles. Persuading an organisation to look beyond it’s own boundaries is getting easier as the recognition of the success of open source methods and process is becoming more widely understood. Whilst the consumption of open source (both community and enterprise) is the norm, collaborating and creating with upstream community projects is becoming an option for more organisations, as developers and managers have positive experiences of working as part of open source projects. For an increasing percentage of developers it’s the only way they work. Based on the work Red Hat has done with organisations, the benefits (obvious and otherwise) of going open source include: the usual coding quality benefits (many eyes etc); you have a bigger community externallyfreedom for developers to interact and be creating with other like-minded developersdeveloper visibility (they like their GitHub commit stats and associated kudos)developers hiring and retention is easier with Open Source activity and practice in place; Inner Source is less appealing. This is becoming a key benefit now that Developers are King (see O’Grady et al)that many organisations don’t do all (or any) of there software development in house; using an Open Source approach does lend itself to managing multiple software suppliers (standards, ways of working). And this last point is interesting. Some organisations, that don’t do a significant amount of software development, feel that Inner Source is the only way for them to experience the open source benefits. However, if they started running their software providers as a community then issues over lock-in, poor product etc are less likely. CategoryUncategorised Post navigation Previous PostPrevious A40 Brewing : Brew #2Next PostNext The Promo Box : Part #1 Leave a Reply Cancel replyYour email address will not be published. Required fields are marked *Comment Name * Email * Website Δ This site uses Akismet to reduce spam. Learn how your comment data is processed.