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

Keynote 2016: Culture First, Tools Last: Building Inner Source Communities

Keynoter: Guy Martin, Open Autodesk

Tools have to fit in with the goals and culture.

Who are the main stakeholders?

Executives: expect tools to solve the problems they know about.

IT staff.

Power users: want to make tools do things they couldn’t do.

Business users.

Tool vendors: want to sell their tools, show off what the tools can do.

Executives are concerned about dollars, productivity.

Power users care are adaptability

Business users care about productivity

IT cares about standardization

Vendors care about dollars and productivity.

Look at your existing culture.

Collaboration style: do people take initiative or wait to be told

Transparency. Do you communicate more in private or in the open?

Meritocracy: are decisions driven from the top or from activists within the organization?

How are decisions made in the organization? Top-down or democratic?

What is the governance model? Controlled or meritocratic?

Look at your existing tools. Are people really sharing information, or just putting up documentation to check off a box? Is data reused?

Use metrics to find out what’s working.


IRC great for technically sophisticated people, may be a challenge for others.

Slack was chosen by Autodesk, because community comes first and they needed a many-to-many collaboration platform. People within the company already knew Slack and wanted it. But they had to consolidate multiple instances. Successfully build a community around Slack, including a help channel for new people. Self-help common.

On the other hand, less successful doing version control. Company had used Visual Studio and Perforce, but the management decided to move all code to GitHub. Problem was that many different groups were silo’d and didn’t talk to each other. Processes were not aligned with the tool (GitHub). Guy took the company back to talking about culture, and using an InnerSource model. Lesson: don’t put the tool before the culture.

Audit your culture: how closed or open it is.

Do you have to ask for permission, or beg forgiveness afterward?

Are you silo’d, or are you transparent and collaborative?

Are you driven by engineering or project management (each has advantages).

Many organizations have “shadow IT,” where people sneak in their favorite tools. Find out why: is there too much control?

Speed of deployment can be important: Slack could be put in place quickly.

Build a “pull request” culture. Expand it to non-code things. Share responsibility and control. For instance, people should feel they can participate in fixing things they don’t like in Human Resources. Try to get people to make a suggestion for fixing a problem, if they identify a problem.

Engagement drives collaboration, while reviews prevent anarchy.

Align tools with reality: resist pressure from vendors. Only you understand how your own organization will work.

Allow some experimentation. Find out what’s working and remove tools that don’t.

Follow the community: find critical mass, such as when Autodesk discovered their staff already liked Slack.

Release early, release often. Iterate quickly. Requires customizable tools.

Allow all the stakeholders to drive tools and customization.

Be patient. Your culture won’t change overnight.

1 Like
Thanks to for being the kind sponsor for this forum!