Destiny number

Breaking News

Mistakes to avoid when using open source software

open source software

Virtually all tech companies in the market today is increasingly using 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 to it or fixing parts that don't always work correctly.

But often companies don't get all the benefits they could from open source, and are not fully aware of the choices and tradeoffs they are making. If you are pondering 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 then flip a switch at the end to ship a fully-realized product that comes with a nifty feature. This rarely works. For a whole host of reasons, the resulting project is unlikely to bring most of the benefits that open source is capable of bringing. The code may be freely licensed and the repository public, but even if the product is a hit, wider 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 itself be a competitive advantage that should not be given up lightly. The third is embarrassment of not being able to get the code ready on time by their programmers.

Open source may well require some adjustment to development methods, and it's true that 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 circumstances are rarer than you might think. If your teams are going to 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 fairly obvious to your competitors anyway, just 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, in a way, 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. The driving energy comes from the leaf nodes — from the engineers, not from some grand strategy. Either way, middle management has the most influence over whether the benefits of open source are realized.

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 interesting 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 never have collaborated were it not for their common participation in the same open source project. These connections are naturally 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 in your org chart and non-technical policies as well. If managers and HR teams refuse to let these transformations spread through the company, they relinquish both the technical benefits of open source collaboration and its potential improvements to corporate culture.

Staff who are 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 tend to shift as open source ascends in a company. Good open source candidates leave tangible proof of their value when they collaborate outside the company. They leave this proof in public places, in front of a whole community of stakeholders looking for expertise. Open source creates job opportunities for your best hires at the same time that it exposes 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 own development work. But they won't decrease your development investment. Your developers work on your priorities and are accountable to you; the value of that 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 own organization's developer investment will likely stay the same or even increase. A project succeeding at that level should spur greater 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.

In a nutshell, remember that an open source strategy forgives the occasional misstep as long as you keep walking.

Enter your email address:

Delivered by FeedBurner