This content originally appeared on Level Up Coding - Medium and was authored by Darío Rodríguez
The Benefits of Internal Open Source Philosophy
One of the main responsibilities for tech leads, CTOs, VP Engineering or similar roles is to define a culture that allows business to get the most of technology.
A culture is defined by several aspects but at the end of the day we are working with code and developers. It means that one of your top priorities should be to improve collaboration between developers to deliver as fast as possible.
You can encourage collaboration using several strategies, for example:
- defining a specific stack (MEAN,LAMP) so all developers will use the same tools and can learn about them sharing information
- implementing CI/CD pipelines to automate processes and create and standard way for all developer to deploy code
- defining a career paths so developers can get more responsibility and have more impact within the company over time
- and much more…
These strategies to empower culture are great but sometimes it takes a little bit more to reach the next level.
If you want your team members to find challenges and to keep learning while you increase your delivery rate you should embrace a different approach and the Internal Open Source model is the solution.
Internal Open Source Philosophy
But what do I mean when I say Internal Open Source Philosophy?
It’s easy, it’s about working with your internal code as if it was an open source project.
It means that every developer can access and modify all code within the organization and not only the repositories or code closely related to their team or squad. It means that as a developer I’m able to fix a bug that makes my assigned task get stuck because, for example, the API client from another team is making requests to my team’s API the wrong way.
Ok, but… Do I mean it’s not possible to keep any code secret? Of course not. You can have a private repository if you consider it critical to the company or even because you need to follow some regulations requirements or similar. The idea is the developers need to have access to the majority of code if you want Internal Open Source to work.
As you notice the idea behind this philosophy it’s nothing new, we want to encourage collaboration between teams and to begin with everyone needs to be on the same page.
Open Source projects have been working this way for years and they are a bulletproof method to collaborate, create big ideas and deliver a lot of value in a short period of time.
What should you expect?
Everything we talked about it’s really great but if you liked the idea you are probably wondering what you should expect if your company works following Internal Open Source philosophy. This question it’s a good one and the answer it’s very easy.
By applying this philosophy you will:
- Remove roadblocks
- Spread know-how and best practises
- Encourage T-shape knowledge
- Grow a team that could collaborate in transversal projects
- Foster collaboration and communication
Let’s explain them a little deeper.
Remove roadblocks
Because every developer can take access and modify the code, they can fix any bug related to an issue they are facing.
Sometimes an issue requires fixes in two different systems, so if the developer can fix the bugs in both of them you are removing bureaucracy and delivering a solution faster.
Spread know-how and best practises
As anyone can see the code of each other, they can see how others solve some problem they are facing and they can copy the idea and adapt to their needs.
This way the code itself serves as a mentor to other developers teaching best practices and problem solving skills.
Encourage T-shape knowledge
T-shape knowledge stands for a way of professional growth where you get a lot of expertise in a particular area but you are still learning from surrounding ones. For example, let’s say you work in a project developing the product listing of an ecommerce store, for sure you will be an expert in this area but you will learn how the checkout process works a little because those two parts of the business are closely related.
This philosophy encourages collaboration between teams and the possibility to watch the code of other parts of the system so a developer can learn from squads that work in related areas of the business. So eventually it will happen that the closest interconnected squads will learn something about business logic, code style, etc. from surrounding squads.
Grow a team that could collaborate in transversal projects
Embracing this philosophy you are creating “super developers’’ on the go. Keep in mind that they will have a T-shaped mindset, the knowledge is more accessible to everyone and they know how to debug certain issues in other systems.
These new skills make your team grow and be more able to deliver projects easily and on time, even those that involve changing code in different systems at the same time and coordinating all efforts effectively.
Foster collaboration and communication
This advantage it’s explained inside the others. If your team is working with an open minded mindset and you encourage collaboration and communication on a daily basis, you are speeding up culture adoption and it highlights the best practices.
Implementing Internal Open Source
As far as here we know what Internal Open Source is and what benefits could we expect from it. But… How can we implement Internal Open Source?
Implementing this philosophy it’s really easy and you can do it following these rules.
- All code should be accessible
- All development processes should be public
- All tasks details should be accessible
- Every change should be supervised by other developers expert in the system
1.- All code should be accessible
This rule is easy, if we are talking about open source the basis is all code should the accessible by every developer and they should be able to make changes.
2.- All development processes should be public
Everything that it’s going on with our code should be treated as a public knowledge base: pull/merge requests, commits, deploy pipeline errors, bugfixes, etc.
Let’s say every developer inside the company can comment on changes in a pull request, the author could get more feedback and If needed he could request feedback from a colleague which is an expert on the problem related to this pull request. This way any developer could get high quality code easily.
3.- All tasks details should be accessible for everybody
Tasks definition or user stories are a great source of information when you need to change some behavior in a business logic and you don’t remember or don’t know why it works as is.
The same way could help you to spot problemas and to understand why other teams did that change that breaks the system somehow.
4.- Every change should be supervised by other developers expert in the system
We talked about opening the codebase to all developers but it will end in a chaos of commits out of control here and there. This will make your system unstable.
To mitigate this problem you should establish a policy so every change should be approved by at least one extra developer that has enough expertise in the system that it’s changing.
For example, if you are changing some API endpoint from your system another member of the squad will review your changes. If you are modifying some code that belongs to another squad you will need a developer from the squad responsible of this code to review and approve your changes.
Conclusions
Internal Open Source it’s about open source your company’s code and making it accessible and modificable to all developers within the company.
We are talking here about code in the first place but other processes like deploying pipelines, code review and information about tasks details should be treated as public information to ensure everyone has access to all information needed.
This change in your culture will allow your team to deliver faster because they are capable of removing roadblock and learning faster. Furthermore collaboration will increase so communication will be more effective and things will start to run smoothly.
If your developers are delivering well and you feel your teams are kind of isolated from each other you should definitely try Internal Open Source, your team will reach the next level.
The benefits of Internal Open Source Philosophy was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Darío Rodríguez
Darío Rodríguez | Sciencx (2022-06-23T20:20:54+00:00) The benefits of Internal Open Source Philosophy. Retrieved from https://www.scien.cx/2022/06/23/the-benefits-of-internal-open-source-philosophy/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.