Skip to main content

Daguva

Inner Source is NOT a lie!

Regardless of what you might have heard on the internet (possibly from a tech influencer with a mustache who dislikes ReactJS), inner source is real and it’s a fantastic way to foster collaboration and innovation within your organization, much like open source does in the wider community.

inner-source

# What is Inner Source?

Inner source brings the open-source model into a company, allowing teams to collaborate on internal projects. It promotes transparency and shared development, helping teams improve systems together and avoid duplicated work.

# Why the Skepticism?

While “hate” might be too strong a word, there are certainly many who are skeptical about the benefits of inner source. The main issue is that many people use it as a justification for their choice of tech stack. Critics argue that inner source is not worth the effort because they believe no one will contribute to their projects. In an organization, everyone has their own tasks and priorities, and they may be reluctant to spend time on something that doesn’t directly benefit their immediate goals. The Real Benefits of Inner Source

But here’s the thing: the reality is often quite different. Inner source can bring about some amazing benefits—if you know where to apply it. Have you ever considered which areas in your organization could truly benefit from this approach?

While it’s true that everyone has their own tasks and priorities, inner source can help align these with the organization’s overall goals.

This is particularly evident in companies with development teams divided into different departments, especially when the main product is not software.

In these cases, inner source can help align the various departments, allowing the development team to operate as a single unit instead of each department creating its own solution to the same problem.

You can’t develop software anymore these days without doing open source.

– Wolfgang Gehring, FOSS Ambassador at Mercedez-Benz

## Hypothetical Scenario

Imagine you have a company with multiple locations around the world and one coporate trying to guide them all, some locations with it’s own development team but separated by departments.

All locations have to predict shortages on their products and they all have to create a solution to predict these shortages:

  • Location A: More developers; creates 3 solutions in Angular + C#.
  • Location B: Decent team; develops a solution in React + Python while focused on other projects.
  • Location C: One developer; builds a solution in Vue + NodeJS.
  • Location D: No developers; creates a solution in Excel.

Now, when someone wants to improve shortage predictions, they have to choose from five different solutions and talk to other locations to decide if a new one is better. Users resist because they have to learn a new system every time, while their local solution fits their needs better.

This scenario is common in companies that lack a strong software development culture. You might think such situations are unrealistic, or perhaps you feel like I’m describing your own workplace.

In this case, inner source can help align different departments, enabling the development team to work as a single unit rather than having each department create its own solution to the same problem.

## A Solution

Corporate decides that all plants should use a unified system. They create a repository with a base version that includes all the current features, allowing different locations to contribute. The system is built in a language familiar to all teams and designed to be extended by each location as needed. With open-source access, anyone can identify issues or understand how the system works.

This not only helps to align the different locations but also helps to create a culture of collaboration between the different locations. The different locations can now share their knowledge and create a solution that is better than the one they had before. Now it also creates a standard on language and quality of code that is expected in the company.

# Implementing Inner Source

The first thing is to identify the areas that need inner source the most. This could be a project that is struggling to meet its goals, a team that is having trouble collaborating, or a department that is not aligned with the organization’s overall goals.

Then you need to foster a culture of collaboration. Get rid of the ego thinking your solution is better than any other team solution. You need to create a culture where everyone feels comfortable sharing their ideas and working together to achieve a common goal.

Create a structure that allows everyone to contribute. This could be a centralized repository where everyone can submit their code, or a system that allows for code reviews and feedback.

Finally, recognize and reward contributions. This could be as simple as giving credit to the person who contributed the most, or as complex as creating a system of rewards and incentives for those who contribute the most.

# Conclusion

Inner source isn’t just a buzzword; it’s a transformative approach that can align teams and enhance collaboration.

So, the next time you hear someone dismissing inner source, remember that with the right implementation and circumstances, it can be a game-changer for your organization.

Take a moment to evaluate your organization’s collaboration practices. What steps can you take today to start leveraging the power of inner source?