Virtually all tech companies today increasingly use open-source software to serve business goals. In simple terms, open-source software is software with source code that anyone can inspect, modify, and enhance. Programmers who have access to a computer program's source code can improve that program by adding features or fixing parts that don't always work correctly.
But often, companies don't get all the benefits they could from open source and need to be fully aware of their choices and tradeoffsondering how to make the most use of open-source software in your firm, then here are 5 common mistakes to avoid to maximize the benefits of open-source:
Don't get tempted to skip to the end of the path.
Companies are often tempted to develop software in secret and flip a switch at the end to ship a fully-realized product with a nifty feature. This rarely works. For a whole host of reasons, the resulting project is likely to bring only some of the benefits that open source can bring. The code may be freely licensed,,, and the repository public. Still, even if the product is a hit, broader participation will not magically appear because potential participants will see that no open-source process is in place.A company must go through the long process of building a developer community, inviting collaboration with other stakeholders, and working across corporate and project boundaries — and that process only starts once the code is opened. In short, the company must walk the path.
Don't give up the first-mover advantage.
Companies usually have three worries about releasing code as open source early. The first is that it may harm their development process because it can involve an adjustment of development methodology or habits. The second is that it could give up a potential information advantage: knowing that you're planning to open source something could be a competitive advantage that should not be given up lightly. The third is the embarrassment of needing more time to prepare the code for their programmers.Open source may require some adjustment to development methods, and signaling your plans provides your competitors with some information. There are occasionally circumstances where one or both of these concerns should legitimately govern the timing of when you make a project public. But such cases are rarer than you might think. If your teams need to adjust their working methods anyway, it's usually better to start sooner rather than later.
As for sending signals about business strategy, much of your overall strategy is evident to your competitors anyway, from the nature of your business. Even if competitors change their behavior based on seeing you start an open-source project, this is as likely to work in your favor as against it. To the extent that your initiative matters to them, they have willingly placed you in a leadership role relative to their own planning. Instead of hiding, use open source to take full advantage of that role.
As for embarrassment or a feeling that the code isn't ready for outsiders to see yet: Just Do It, the earlier you open source, the less of a concern this should be because everyone knows that no code base starts out looking perfect.
Middle Management is the Key
Open source usually comes to a company either top-down or bottom-up. Either way, middle management has the most influence over whether the benefits of open source are realized. Either way, middle management has the most influence over whether the benefits of open source are realized. Either way, middle management has the most influence over whether the benefits of open source are realized. The driving energy comes from the leaf nodes — from the engineers, not from some grand strategy.Middle management is the conduit that carries messages about shifting problems and priorities. When those shifts involve a move toward open-source development, the organization can think and act productively only if managers recognize what's happening. Middle managers are where open source is internalized; if they are not on board, the organization will fail to capitalize fully on the benefits of open source.
To give an example- One of the most attractive benefits of open-source activity is that it often improves internal communications at a company. Developers start working with people in other business units with whom they might have yet to collaborate were it not for their joint participation in the same open-source project. These connections are most effective when managers on both sides are aware of and support the collaboration.
Failure to recognize the needs of the non-engineering part
Open source eventually has transformational effects not only in your code but also in your org chart and non-technical policies. Suppose managers and HR teams refuse to let these transformations spread through the company. In that case, they relinquish both the technical benefits of open-source collaboration and its potential improvements to corporate culture.Staff habituated to open-source collaboration will naturally push for similar dynamics in other aspects of their work. The drive to share by default, and to leave doors open wherever possible, becomes ingrained. Hiring and HR also shift as open source ascends in a company. Good open-source candidates provide tangible proof of their value when collaborating outside the company. They go this proof in public places, in front of a community of stakeholders looking for expertise. Open source creates job opportunities for your best hires while exposing your company to a vast new hiring pool. Managing that and other HR changes often requires fresh approaches.
A myth to avoid
Sometimes firms see open source as a way to get cheap development resources. Open-source contributions will provide real value and may even substitute for some of your development work. But they will keep your development investment the same. Your developers work on your priorities and are accountable to you; that value is high, and no company should give that up.When an open-source project succeeds, it becomes more valuable to your company in proportion to how it becomes more valuable to its community as a whole. You might reach the point where core development is shared across multiple companies, but your organization's developer investment will likely stay the same or even increase. A project succeeding at that level should spur more significant investment, not less. A good rule of thumb is that your open-source investment remains proportional to your benefit, whatever the size of the larger community.
Remember that an open-source strategy forgives the occasional misstep as long as you keep walking.
