#innersource

What is Zone.js?

Zone.js itself is independent of Angular. However, when developing in Angular, it’s important to know a thing or two about Zone. Zone is in the heart of Angular framework. This old video explains how it works.

What Makes a Great Remote Team

This isn’t a typical technical post, but somewhat related. Google has spent 2 years researching what makes a great remote te…

A underlying theme of the past year has been encouraging the formation of sustainable self-organizing inner and open source projects. This has been particularity interesting at work, with much room for improvement. Based on this experience, I feel like some changes can be made to more rigidly define the balancing of agile ops scrum teams and adhoc organizations.

By the time I first stepped into an Autodesk office a conscious decision had already been made to encourage inner and open source projects. Internal ad-hoc organizations are provided rational guidelines, policy, and process for running their communities. Also provided are tools such as GitHub and Slack for encouraging emergent behavior driven software development. Despite this, and some success with open source projects, it remains difficult for individuals to dedicate time as core contributors on adhoc organized projects. As there are diminishingly few projects which actually do need to be solved on a one-off basis we should be doing everything we can to encourage sustainable shared solutions.

A challenge going forward is managing ad-hoc organizations in a live-operations-centric environment while striving to adhere to aspects of agile development. It's always been difficult balancing meticulously groomed backlogs and scrum teams against the often hard to predict care and feeding of live systems. Mixing in projects which may not be tied to a single scrum team is not easy. The naive approach is to spin up a new scrum team and have people split time but this is far from what most consider agile.

We've started brewing a system of governance which we hope will help us succeed in this transformation. It is vitally important for open and inner source projects to be treated as long-lived entities distinct from business initiatives and priorities that exist in the moment. At the same time, it must be assured that the priorities of an adhoc organization feed off of the overall business needs.

When starting a new project, make sure to include not only core contributors, business stakeholders, but also introduce a community manager for the adhoc organization. This new role is functionally similar to that of product ownership, however more focused on coordinating the efforts of a heterogeneous group of individuals who are not all on a single scrum team. Begin with transparent communication of overall goals, the specific people involved (with explicit roles), and how the work ties back to concrete business needs. It is important that business product owners and project community managers remain synchronized with regards to their separate backlogs. After the project start, periodic checkin meetings should be conducted to ensure that project priorities remain in line with business needs. There may not always be a one to one match between project and business goals in the now, but on a long enough timeline they should be synchronized. It's also strongly suggested that the project hosts regular "office hours" to assure those who are not direct stakeholders can catch the attention of core contributors.

Autodesk is thus far the largest firm at which I have produced shareholder value. It wasn't until I began this chapter in my career that I was introduced to the concept of Inner Source. I've been familiar with Open Source for most of my life, dating back to when I first discovered a world beyond Gopher in tail end of the twentieth century. Growing up with rampant flea market and sketchy computer bodega driven software piracy, seeing copyleft behavior legitimized appealed to me. It provides a great middle ground between the demands society places upon our own manifest value and allowing everyone to collaborate in terms of building our software pyramids.

Open Source is based upon the premise of jointly produced value being disseminated widely with (license depending) little to no strings attached. Successful open source projects tend to be highly collaborative environments, with many people contributing to the overall goal. It is rare to find popular projects maintained by only a single author. Inner Source strives to take aspects of the open source software bazaar movement and apply it to the closed system which large companies represent. While the software may still remain confidential intellectual property, it is still developed with governance model which encourages transparent collaboration.

As with any enterprise company, Autodesk struggles with a cultural imperative to continuously re-implement solutions without considering prior art. It's a super easy trap to fall into, almost cliche in terms of how pervasive it is through software communities. I'm almost certain the root of these habits is based around the assumption it is more difficult to solve a problem for the many, as opposed to the one. On the surface, it is always easier to solve for the specific pain right now, but it's important to not forget the long tail of software lifecycles. The Inner Source concept is rooted in the assumption that solving for many, and encouraging reuse, will allow you to reap more awards as time goes on.

This blog post has been deprecated. For up-to-date information on npm Enterprise, please refer to these resources:

npm Enterprise overview 

npm Enterprise: Delivering More Secure JavaScript Development [blog] 

npm Enterprise docs