The future of Firefox

Use of Mozilla's Firefox browser is declining (at least as a percentage of market share), and people are concerned.

Some are concerned that we will lose an option in the browser market. Others are concerned that the demise of Firefox signals a forthcoming decline of open-source software. Mozilla, of course, is concerned about its business.

I'm not sure what Mozilla should do in this situation. I do have some observations:

First, people select browsers (and other things) for one of two reasons.

1) They want to use the specific product (in this case, the Firefox browser)

2) They don't want to use the alternatives (in this case, Internet Explorer, Edge, Chrome, Safari, etc.)

To improve its market share, Mozilla will have to either provide a product or service that people want to use, or be an alternative to a product that people don't want to use. Mozilla must either make a better browser, one that people look at and think to themselves "yeah!", or wait for people to dislike the other browsers on the market.

When Chrome appeared on the market, people used it, I think, for the latter reason. At the time, Internet Explorer (IE) was the most commonly used browser (sometimes by corporate dictat) and people did not like it. Chrome was not Internet Explorer, and by using Chrome, one could "poke Microsoft in the eye".

But that was then. Now, people use Chrome because they want to. People might have chosen Chrome after using Gmail, and may have had favorable opinions of Google due to the 1GB space for mailboxes, which was quite large at the time. And Gmail was free!

Whatever the reasons, people like Chrome. Mozilla does not have the tailwind of people disliking their current browser.

Waiting for potential customers to dislike their current product is not a viable strategy. People may be unhappy with some of Google's practices, and that may drive some away from Chrome (and some of those to Firefox) and Mozilla has been advertising along those lines.

But dislike of Google is probably not enough. Mozilla needs "a better mousetrap".

And I'm not sure how they can build one.

Technical debt is similar to new features

If we accept the premise that technical debt is the difference between what we want the code to be and what the code actually is, we can treat technical debt like new requirements.

Most development shops have a process for new requirements. That process usually involves describing the new feature, estimating the benefits (additional revenue, reduced expenses), estimating the effort, scheduling the work, testing, and deploying the new requirements in a new version.

An organization can use a similar process for technical debt. Technical debt must be described ("module X fails to meet code style rules 12, 14, and 17" or "library Y is obsolete"), estimated for benefits, estimated for effort, scheduled, tested, and deployed.

Technical debt does vary from new requirements in two ways. First, new features are often about revenue or cost reduction, and technical debt is about the reduction of risk. This difference often makes new requirements more desirable; revenue is often better than less risk, especially for a working system.

The second difference is the sponsors for changes. New features often have organizational sponsors. They may have titles such as "product owner", "VP of marketing", or "user representative". These sponsors make the case for the new feature, presenting the benefits to the managers who control the project budget.

In contrast, the sponsors for technical debt are (almost always) developers. It is the developers who see the problems in the code, the developers who want to improve things.

But "improving the code" is not a goal that makes sense for the business. Managers are concerned with four general topics: money, time, risk, and politics. "Improving the code" is not one of them. To get managers to "buy in" to the effort to reduce technical debt, developers must make the case in management terms. They have to convert "improvement to the code" into one of money, time, risk, and politics.

A change to eliminate technical debt may, on occasion, offer a reduction in cost, but usually the benefit is a reduction in risk. To get time and resources to reduce technical debt, developers must present a clear case about the risk caused by the current code, and possible costs (money, time, delayed releases) in the future.

If developers can make their case, then the process for technical debt is quite similar to the process for a new feature. Changes for technical debt can be identified, described, tracked, prioritized, estimated, scheduled, implemented, and deployed.

Technical debt is not a mysterious aspect of software development. It can be described and measured, and the effort to reduce it can be estimated, prioritized, scheduled, and implemented -- just like the efforts for  new features. The big difference between technical debt and new features is that technical debt is about risk, and new features are about money. Any organization must balance the needs of money, time, risk, and politics -- that's management.

Technical debt is what we want it to be

We like to think that technical debt is an attribute of software.

Wikipedia provides a definition: A concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.

I believe that technical debt is not derived from software, but is instead derived from our expectation of the software.

Or more specifically, technical debt is code that violates a coding style or architectural guideline.

If we accept this definition of technical debt, something interesting happens.

Technical debt becomes not an aspect of software, but an aspect of our desire for the software.

Moreover, it can change over time.

Consider a hypothetical project with code written in Python. There is a substantial code base, and there are no rules for code style. The development team is unaware of the generally accepted rules for Python code, nor do they use pycodestyle.

The code performs as expected with no defects. (I did say that this was a hypothetical project.)

Yet the code itself is a jumbled mess of classes and functions, with poor names for variables and lines that exceed Python's recommend 80 characters. The development team is okay with the state of the code. (After all the code does run and it does produce the correct results.)

The code in the project has no technical debt. There is nothing in the code that developers or managers want to change.

Now we change the scene: The team becomes aware of code style rules and the pycodestyle package. They discuss the idea of code standards and agree to use the pycodestyle package to review their code.

Now the code has technical debt.

We did not change the code. The code is exactly the same as before the introduction of code style rules.

Yet now it has technical debt.

Not because the code changed. Because the expectations of the developers changed. Simply changing the rules made technical debt appear.

Technical debt does not follow the rules of accounting. One does not use double-entry bookkeeping to track it. There is no "law of conservation of technical debt".

Technical debt is what we say it is. Or more precisely, technical debt is what we want the code to be that it is not. The key phrase is "what we want".

Technical debt is not an absolute attribute of the code. It depends on the expectation of the developers.