Seven success factors for partnering in the age of open source

Telecoms.com periodically invites third parties to share their views on the industry’s most pressing issues. In this piece Susan James, Senior Director of Telecommunications Strategy at Red Hat, explores the ideal balance of in-house and outsourced talent in order to make the most of open source opportunities.

The breadth of technology knowledge that service providers now require has increased exponentially, as the number of employees is stable or in decline in most service providers, and the pool of needed specialist digital talent hasn’t been able to keep pace.

With a more diverse and collaborative ecosystem than ever before, choices are available – but what’s the right balance of making the most of your own talent versus looking externally? Here are several considerations when deciding how, when, and with whom to partner.

For most companies, success comes from the core business. You have to closely examine your business and ask what your core business can provide that no one else can.

It’s easy to look at other companies and be tempted to duplicate the way they do things as a template for your own business. However, you need to recognise what’s good about your business, and focus on maximizing those aspects with innovation, rather than trying to replicate what others are doing.

When you know your core business, you can make informed decisions on what to build yourself, where to use external people to solve a problem, and what areas need third party software to do the job.

With a growing shortfall of specialized digital skills, we need to encourage people to enter emerging technology from outside of the expected STEM fields (science, technology, engineering and maths). Hence the A for ‘arts’ in the emerging term STEAM. We must be open to diverse types of skills and perspectives coming into the industry; they can help us understand the diverse customer base we all have.

In a recent internal meeting, I did a quick straw poll of how many people were engineers – less than half had an engineering background. I myself have an economics degree and ended up as a software product manager. You don’t need an engineering degree to use software, and you don’t need one to understand how to build software. I encourage you to look at your business as a whole, and what different perspectives can bring, when developing software. This applies to hiring as well as team building and partnering.

You have your core strategy and your internal teams. What’s your criteria for choosing who to team up with inside and outside your organization? Thought leadership is a priority, surely. But what makes a thought leader?

I would argue that true thought leadership today is not just someone who can solve today’s technology problems; nor is it painting a technical vision of the future. It’s recognizing the need to shape your organization with the capabilities that enable you to seize unknown opportunities that lie ahead. Red Hat’s CEO Jim Whitehurst calls this ‘organizing for innovation’. He argues that in today’s dynamic environment, planning as we know it is dead. Instead, you must build the mindset and the mechanisms that enable you to move faster and change as needed.

Ask yourself what kind of partners you want to be associated with, and how you want to be perceived in the market. Move forward with partners whose core values align with yours. For example, as the world moves increasingly towards open source, do you want to be perceived as a leader in upstream* innovation? Do you want to be an active contributor to open source communities and help influence new features that are developed for real world needs? Or, do you desire to be a leader in technology adoption for bringing new capabilities to market? Look for a partner that displays or complements what you want to see in your business.

*Upstream communities are the projects and people that participate in open source software development and are also known as innovation engines.

Some say the measure of a true friend is someone brave enough to tell you the truth, and this can apply in business as well. Some companies aren’t used to openness and honesty that brings – they are accustomed to being told what they want to hear by partners. So when they do hear the truth, it can come as a shock. They may see it as confrontational or they may look for a second meaning.

But being honest and upfront enables companies to grow together. It provides the opportunity to quickly identify threats and know what you’re dealing with, both good and bad. Working in open source communities makes it easier to be honest about deficiencies because everyone can see them. All code is fully exposed and everyone works on the same information and code base, which allows everyone to more easily unite around common causes and problems.

When evaluating potential partners, determine their participation in open source communities, and be clear about the importance of open, honest communication in all business dealings.

A relationship with a partner can be multifaceted. Collaborating in open source development is a separate engagement from working with that same partner on the business side of things, and likely looks quite different.

Upstream communities are all about rapid iteration, creativity, and innovation. Going to market with a product must be about reliability, security, and making sure the product works in practice.

It’s possible for these two areas to overlap: business needs can influence communities in a certain direction, and upstream collaboration between partners can solidify a business relationship. Or, you might work harmoniously with a company upstream, yet go out and compete with each other fiercely on the sales side.

Therefore, be clear from the outset about your engagement models and what constitutes success in each area.  If you are not able to see a “win” for both parties, then long term success of the partnership is questionable.

The proliferation of open source across industries is allowing new players to enter markets, and existing players to work more closely together. There are different ways to leverage open source technologies, and it’s important to understand how different uses impact your business.

Downloading open source software for free doesn’t mean that it doesn’t cost you anything. If you make customizations to that open source software, you need to be aware of what you’re taking on internally. Ensuring that the software is secure ongoing and understanding how to manage the lifecycle takes resources and competence.  Making changes that are not delivered upstream requires you to manage monitoring, maintenance, support, updates (including upstream changes), and the full software lifecycle yourself.

Choosing the supported software route (enterprise version of open source community software) requires you to pay a subscription fee to a software vendor, but it’s the vendor’s job to stabilize the software, certify it works with an ecosystem of other hardware and software, ensure it is safe to use over its lifetime, and provide guidance on the best way to integrate it with the existing environment for the desired results.

Different vendors differ in their level of open source community participation. Vendors that do not contribute all changes back to upstream projects become out of sync with the community version and can no longer take advantage of community innovation.

It’s also important to note that as software development in an area becomes less cutting-edge, people can be less likely to stick around. And unless you’re recognized as a leader in that particular area, it can be hard to attract people. Such might be the challenge for a communications service provider trying to recruit talent for working on containers and competing with companies recognized for container innovation.

This relates back to your core business – what would you rather have your people working on? Where can your internal innovation and differentiation bring you the most value?

Final word

This isn’t a ‘one and done’ process – it’s cyclical. You should continually evaluate your business objectives and results in the context of what’s happening around you, and adjust your approach as you go. Remember too that it’s ok to make mistakes – it’s the mistakes that help you learn for the future. A company that is strategic in the projects it gets involved in, and one that is not afraid to change and drop the projects that aren’t successful is going to be more agile and adaptable to change.

Be open to diverse skill sets, and be honest within your organization and with your partners about what’s working and what’s not. These are all long term strategies that will best position you for success.

Susan joined Red Hat in May, 2018, after 27 years at Ericsson, where she was head of Product Line NFV infrastructure. While at Ericsson, she worked in Enterprise, Wireline, Network and Cloud organizations. She worked extensively with the IP Multimedia Subsystem (IMS), and was responsible for a number of the network functions in the Ericsson portfolio. A product management veteran, her career has focused on developing products to address technology transitions, and the establishment of new business areas.