Leading open source the right way

All open source thrives on collective inputs and collaboration, there is the need for a centralised channelizing force every now and then to bring out the best in the existing resources. For any organisation that indulges in open source, it is important to remain proactive and constantly reflect upon and retrospect the direction in which their open source investments are heading. 

In any project leadership provides the much-needed vision pathway and blueprint for progressing in a certain direction. Even when something is collaborative, there needs to be a supervisor's perspective to solve problems and meet goals efficiently. 

More often than not, companies have open-source programs with objectives in place that they aim to achieve through the program. Assigning a lead not only improves the overall efficiency of the project but also helps in a number of other ways.

Some of the reasons why organisations care about diving into open source are as follows -

The Seven Laws of Leadership in open source

Leading an open source program varies greatly from the same role in other dimensions in the sense that it is not as straightforward and upfront. And a lot of times people might mistakenly assume that leadership is not required in such a project but they could not be more wrong. Something as vast, spontaneous and continuously evolving needs to be managed and utilised well at every point and in turn needs more supervision than regular platforms.

Let's move ahead and explore some mutually agreed and understood laws of open-source leadership that make a good leader in these platforms.

Competence

Open source leaders are very different from conventional bosses. It can be seen by the personality of Linus Torvalds, founder of Linux or Jim Whitehurst, CEO of Red Hat that their personalities spark liveliness and dialogue. They are highly approachable and remain open to the community base that they are a part of, and can be seen acknowledging and crediting their success to the community regularly. 

It can hence be deduced that rarely does a successful open source leader think just for himself, and it is always the values of togetherness and teamwork that take away the cake when it comes to allocating credit to the platform's success and growth. This is exactly the mentality that is required in an open source leader - somebody who drives their authority not from the designation that they hold but from the millions of people that toil everyday to keep the community thriving.

Being a teamplayer

Conventional leadership is largely surrounded by the aspects of authority charisma and holding onto the crown as long as possible. It is hierarchical and depends on the concept of formal leadership. 

On the contrary, an open-source leader isn't supposed to be perfect and utopian. He is more like the first among equals - he is as good as his team members and is not required to show his complete hands above the others in the team. He is supposed to be on the ground and lead the team by example. An open-source leader, hence, is not an unattainable figure, but he is just one commoner who has the ability to manage and improvise. 

Being spontaneous

For a platform that is as fast moving and evolutionary at every second, a laid-back leader just won't make the cut. You should be someone who is capable of taking spontaneous decisions as the leader here should be someone who can formulate and execute ideas quickly. Swift decision making is the key to succeeding in open source, and it must be the central idea of all plans of action. 

The open-source crowd is not patient enough for leaders who will slowly drop suggestions or complain about an issue or expect their contemporaries to resolve the problem at hand. Spontaneity and team spirit are integral to an open source leader and he is expected to pull up his socks and be the first one to start working.

Autonomy

In open source, autonomy replaces hegemony in the leadership role. The management does not exercise coercive control to get everything done, rather, all the tasks are worked upon and pulled together as a team. The job of the leader here is to lay down the framework of all the initiatives to be taken, within the community and establish related objectives to bring those initiatives into action.

This shows that authority and control are obsolete concepts when it comes to this dimension and creativity and autonomy are the desired qualities of an ideal open source leader instead. He is not only supposed to collaborate and lead but also to empower the team members by facilitating every tool and piece of knowledge that is needed to get the work done. 

Delegating it right

Leadership in open source focuses on the right delegation and decentralization of duties. As stated above, blending in well with the team and keeping everybody on the same same page is essential, hence each team member should be enabled to take the authority and ID fix any minor issues that arise from time to time and not reach out to the leader for every minor inconvenience. 

Never ignore the soft skills

Sure, getting the technicalities right is pretty important, but soft skills are the ones that pay off in the long run. More than anyone else, a leader requires a 'human touch' and needs to be empathetic and engaging with the team to keep each member's spirits high and productivity maximum. A leader should be able to perform, communicate explicitly, be very clear with the expectations along with being result oriented. Humility also accounts for a great soft skill and shines above everything else.

Say no to micromanaging

Needless to say, micromanaging can be detrimental to such a vast project as you might be biting off more than you can chew. It is physically impossible to manage everything that goes on in the ground in an open source platform, and one needs to realise that they cannot manage every project from tip to toe. A safer bet is to teach the skills required to your team members and delegate tasks to them regularly - along with trusting them with what they're doing.

Understanding the Leadership Role
 

Gaining leadership in an open source project can lead an enterprise to great commercial success. This is because

• A lot of products depend on open source software technologies 
• The path to Innovation unfolds much faster in open source
• The software ecosystem is more or less dominated by open source.
• Software can make or break your online business and is one of the biggest differentiating factors in present industries. Therefore, the best one matters now more than ever.

Now that we have covered the basic tenets of open source leadership, let's dive deeper into the model and understand the leadership role better. As widely recognised, this role is said to be the embodiment of an integration of these interrelated characteristics.

• The first trait is to be awake about any intolerance or discrimination experienced by the team. Nothing kills team spirit quicker than bias. With such things to worry about, it would be a big hurdle for any person to look beyond being undervalued or excluded and perform to their full potential. The primary goal is to empower and motivate everybody and take care of all of their insecurities and weaknesses.
• Branching out from the first characteristic is the second one - and it is trustworthiness. To act as the glue amidst the chaos, the first quality that you need to develop is being trustworthy. Honesty of the team members is extremely important to bring out the best in each resource and you need to give them an open slate to chalk out their aspirations, fears and problems. 
• A trait exclusively important to open-source leadership is being agile and quick as the world would not wait for you to formulate an idea and implement it, and will move on at its own pace. If you are left behind there's nothing you could possibly do about it. 
• Lastly, and most importantly, be accessible!  You do not want good ideas to be silenced or issues to not be brought to your notice until the last minute. An open-source leader must acknowledge that authority and responsibility go hand in hand and it is imperative for him to stay proactive and respond to each and every query and argument of his team.

This is how a leadership role in an open source project is outlined. After these essential requirements have been met, the next step would be to break the project down into consecutive steps and work on it one at a time.

Defining the project structure

Most open source projects follow the rule book in having a common repository that defines all the major principles and objectives of the project's governance model, structure, rules and processes. An open source project mein have any one of the three common governance structures - BDLF, meritocracy and liberal contribution.

Allocation of resources

Allocation of resources also includes assignment of roles to different team members. A member might be 

• A contributor - someone who creates or follows up on an issue.
• A committer - someone who has been given the access to write access to the repository.
• A maintainer - someone who sets priorities and directions for a project or a special interest group. 

Mapping out the requirements

This is actually one of the most difficult parts of the process. The requirements in conventional projects are already defined by the company's authorities, but open source requirements come from users and contributors. Working in open source has to be very agile and swift due to this. Needless to say, the pipeline keeps changing and evolving by each passing day.

Defining coding standards

The team must have rules and standards related to both the overall process and coding explicitly mentioned in some documents and shared on a common platform that ensures easy day today communication. A set of directions on how to proceed with the code would avoid unnecessary conflicts and irregularities later on in the projects and save crucial time. 

Mentoring 

While everybody is expected to perform at their individual level, the leader is also expected to go the extra mile and establish a homogenous flow to help everyone on the team. Regular interactions and stand ups might help reinstating the common agendas. A simplistic pathway should be put in place for volunteers to start contributing to the project. Learn more about the perks of contributing to open source here.

How to make the most of open source?

Utilizing and making the most of an open source platform can become significantly easier when you have a strategy in place. 

• Owing to the dynamic nature of open source goals should be set and reset on a regular basis. Once the agenda has been finalized, it needs to be reviewed annually or biannually for projects to sustain themselves and not go obsolete by the time you get them done. Therefore, even the long term plans in open source can only stretch up to a certain extent.
• Needless to say, the planning needs to be proactive and there is absolutely no place for neglect in an open source platform specially from the leaders' end. Even when a project is complete it needs to be maintained in order to adapt to the present software trends for your targeted ecosystem.
• The tech team should remain in sync with every other stakeholder so that the product that they are engineering is always close to the final idea in everyone's mind. To stay updated, after every milestone achieved, try to get appropriate feedback and incorporate it in the execution.

Lastly, one of the most important leadership roles is to foster a culture of psychological safety where the contributors feel free and excited about contributing to a project and not worried about the response that they will get. This is how Michael Cardy, Red Hat's Chief Technology Strategist puts it.

“The culture has to treat failure as an opportunity for learning, and failure is only bad when lessons are not sought and shared with the rest of the organization.”