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.

Apple's upcoming challenge

Up to now, Apple's business has been simple: sell hardware. Software such as macOS, GarageBand, and even iTunes was made to sell hardware.

Up to now. Or some time in the recent past.

Apple now has two major lines of business: hardware and services. At some point, conflicts between the two will arise. How will Apple navigate those conflicts?

Here is how this affects consumers and developers -- and Apple.

In the past, developers were reluctant to build certain types of apps. The fear was that Apple could build their own version of an app and include it in iOS or macOS, and that such an inclusion would reduce sales of the independent app to near zero. (Apple includes lots of apps for its phones and for its laptops. macOS includes a word processor, a spreadsheet, an e-mail client, and sound editing software, among other things.)

But now, with income from the sale of apps (or subscriptions to online apps) Apple faces a choice: Do they build an app or let someone else build it?

If Apple builds the app, their hardware/software offering is more complete, which makes it more appealing to customers. On the other hand, Apple must invest in the app and maintain the app over time.

Suppose Apple doesn't build the app. Odds are high that someone else will build the app, and submit it to Apple for inclusion in the Apple App Store.

And charge for it. Either a one-time charge or a subscription fee. Both of which provide income to Apple.

Notice what has happened. The app, when developed by Apple, is an expense. When developed by a third party, it is revenue. But the differences are more than financial.

Removing the financial aspect, the big difference of the two modes is control. When Apple builds the app it has complete control over the appearance, functionality, performance, and reliability. Apple can ensure that data is stored only on Apple devices or Apple-approved cloud servers. When Apple lets third parties build the app, it cedes some control to those third parties.

I can see two trends in the future.

One is that Apple will cease adding apps to its macOS and iOS operating systems. (It will add utilities that control and configure hardware, like the AirPort utility for AirPort devices. But it will add few games or office tools.)

Another is that Apple will increase (or attempt to increase) its control over apps that run on macOS and iOS. Apple will issue stronger and more detailed guidelines for user interfaces, security, privacy, and reliability. In this case, Apple is trying to have its cake (maintain control) and eat it too (farm out development to third parties and gain revenue).

I think this strategy just might work for Apple. They sell lots of hardware, and third-party developers want access to that market. Apple customers are loyal, replacing their old Apple laptops and phones with new Apple laptops and phones.

There are some risks.

Such a strategy will mean a difficult time for third-party developers, who will have to jump through more and more hoops to get their apps published in Apple's App Store. Some developers may give up on the Apple market, and this is the risk that Apple must manage. If too many developers abandon the Apple ecosystem, then Apple loses apps and income, and could lose customers for hardware.

Another risk is that Apple loses its ability to develop apps. If it relies on third parties to create apps for iPhones and Macbooks, will it shift its internal resources from app development to something else? Will it lose the ability to create regular, non-system apps? If it does, then returning to a strategy in which Apple creates apps (user apps, not just system apps) will require the re-development of that development experience.

But if Apple avoids those problems, they can succeed and reap the rewards.

Developers for open source

Infoworld makes the case that open source is constrained not by money but by developers -- people.

This seems a good time to recall some wisdom from the late 1990s. Christine Comaford, a technology pundit of the times, listed four things that techies want:

Lavish, genuine praise
Fun projects to work on and fun tools to work with
Free beer and pizza
Some money
(And look where money is in this list.)

I've taken the liberty of expanding Ms. Comaford's first item with the adjective "genuine".

Open source can learn from this list, and use it to attract and retain developers.

The money is ready. Infoworld admits that funding is available.

Fun projects and fun tools are also available. Open source has plenty of projects. Today's tools are much better than those of 1997.

Keep in mind, in 1997, open source didn't exist like it does today. It was a tiny corner of the IT realm, obscure and unknown to many. The vast majority of development was in corporations or government agencies, with development tied to employment and tools specified by corporate committees.

If open source projects want to attract developers, the two remaining aspects are the place. Free beer and pizza -- substitute soda, juice, fruit, and sandwiches if you want -- and lavish praise.

Praise. Recognition. Credit (as in movie-style credit).

These are mechanisms to entice developers.

Apple and cloud computing

 Apple's tussle with Epic (the creators of Fortnite) shows a deeper problem for Apple. That problem is cloud computing.

Apple has avoided cloud computing, at least from its customers' perspectives. Apple is the last company to use the "run locally" model for its application. Apps for iPhones and iPads run on those devices, applications for Macbooks run on them. (Apple does use servers and possible cloud computing for iCloud storage and Siri, but those are accessories to macOS, not a front-and-center service.)

In contrast, Google's cloud-based Documents and Sheets apps let one build documents and spreadsheets in the cloud, with data stored on Google's servers and available from any device. I can create a document on a Chromebook, then open it on my Android phone, and later update it on a desktop PC with a Chrome browser. This works because the data is stored on Google's servers, and each device pulls the latest version when it is needed.

Microsoft is moving in this direction with its online version of Office tools. Even Oracle is moving to cloud-based computing.

Apple is staying with the old "local data, local execution" model, in which computing and data is on the local device. Bur Apple does let one move from one device to another (such as from an iPad to a Macbook) by synchronizing the data onto Apple's servers.

The difference is the location of processing. In Google's model (and in Microsoft's new model), processing occurs on the server. Apple keeps processing on the local device.

For simple tasks such as word processing and spreadsheets, the difference is negligible. One might even claim that local processing is better as it offers more options for documents and spreadsheets. (More fonts, more chart options, more functions in spreadsheets.) The counter-argument is that the simpler cloud-based apps are better because they are simpler and easier to use.

Regardless of your preference for simple or complex word processors, cloud computing is also used by games, and games are a significant market. More and more games are shifting from a model of "local processing with come communication to other users" to a model of "some local processing to communications with servers for more processing". In other words, games are using a hybrid model of local processing and cloud processing.

This shift is a problem for Apple, because it breaks from the "all processing is local" model that Apple uses.

What is Apple to do? They have two choices. They can stay with the "all processing is local" model (and ignore cloud computing) or they can adopt cloud computing (most likely as a hybrid form, with some processing in the cloud and some processing remaining on the local computer).

Ignoring cloud computing seems risky. Everyone is moving to cloud computing, and Apple would be left out of a lot of innovations (and markets). So let's assume that Apple adopts some form of cloud computing, and enables developers of applications for Apple devices to run some functions in the cloud.

How will Apple host their cloud platform? Here again there are two choices. Apple can build their own cloud platform, or they can use someone else's.

Building their own cloud infrastructure is not easy. Apple comes late to cloud computing, and will have a lot of work to build their infrastructure. Apple probably has the time to do it, and most definitely has the cash to build data centers and hire the engineers and system administrators.

But the alternative -- using someone else's cloud -- is also not easy. Apple is not friends with the major cloud providers (Amazon.com, Microsoft, Google) but it may form alliances with one of the smaller providers (Oracle, Dell, IBM) or it might purchase a small cloud provider (Linode, Digital Ocean, OVH). Apple has the cash to make such a purchase. While possible, a purchase may not be what Apple wants.

My guess is that Apple will build their own cloud platform, and will make it different from the existing cloud platforms. Apple will need some way to distinguish their cloud platform and make it appealing to app developers.

Perhaps Apple will focus on security, and build a self-contained cloud platform, one that offers services to Apple devices but not others, and one that is isolated from other cloud platforms and services. An "Apple only" cloud platform with no connection to the outside world would allow Apple to ensure the security of customer data -- with no connection to the outside world, data would have no way to escape or be extracted.

Apple may go so far as to mandate the use of their cloud platform, prohibiting apps from communicating with other cloud platforms. iPhone apps and Macbook applications could use Apple's cloud, but not AWS or Azure. This would be a significant restriction, but would guarantee revenue to Apple.

(Assuming that Apple charges for cloud services, which seems a reasonable assumption. Exactly how to charge for cloud services is a challenge, and may be the only thing preventing Apple from offering cloud services today.)

The outcome of the dispute between Apple and Epic may foreshadow such a strategy. If Apple prevails, they may go on to create a locked cloud platform, one that does not allow competition but does ensure security of data. (Or perhaps a milder strategy of offering the Apple cloud, but only on the condition that the Apple cloud is the only cloud used by an app. Classic apps that use other clouds may continue to run, but they could use Apple cloud. Moving any services to the Apple cloud would mean moving all services to the Apple cloud.)

I don't know how things will play out. I don't know what discussions are being held in Apple's headquarters. These ideas seem reasonable to me, so they may come to pass. Of course, Apple has surprised us in the past, and they may surprise us again!

Apple and Fortnite

Events in the Apple vs. Fortnite dispute are unfolding rapidly. In less than a week, Fortnite modified their web page to allow payments outside of Apple's payments API (which meant that Apple could not extract a 30% toll), Apple removed Fortnite's app from the Apple App Store (which meant that customers can no longer install it on Apple devices), and Fortnite ran an advertisement video that parodies Apple's "1984" ad for the original Macintosh computer. Fortnite has also filed a lawsuit against Apple.

A few thoughts on this dispute:

First, Apple will probably win the lawsuit. It seems to be a contract dispute, and I think Apple's terms and conditions are strong enough to defend its actions. (Although I am not a lawyer and I am not offering legal advice.)

Second, Apple is probably surprised at the tactics used by Fortnite. I'm sure Apple is frequently involved in lawsuits, ranging from patent disputes to wrongful termination by employees. Most of these are handled quietly. Fortnite is running a very public campaign, and wants to make as much noise as possible. I'm not sure that Apple is prepared for a public dispute.

Third, Fortnite is prepared for this fight. The parody of Apple's "1984" advertisement shows that -- such a parody was not assembled in an afternoon hack session.

Fourth, Apple is the larger of the companies, and is therefore "punching down" against the smaller Fortnite. Apple faces the risk of looking bad, and must tread carefully. Carelessly worded statements by Apple will be received poorly.

Fifth, it seems that Fortnite is ready to walk away from the Apple platform. A public spat such as this one leaves little room for reconciliation.

Sixth, Apple is most likely ready for Fortnite to walk away. Apple recognizes that the revenue from Fortnite is a small portion of its overall income. Apple probably assumes that it can get other companies to provide games for Apple devices.

Finally, while Fortnite will probably lose in a court of law, they may win in the court of public opinion. This may be damaging to Apple. Apple has fans and followers, but I don't know that Apple has many friends. The fans and followers will stay with Apple, but partners and suppliers may become more cautious in their dealings with Apple. Small developers may delay releases for Apple devices, or may defer them indefinitely. For Apple to win, it needs more than lawyers -- it needs a good public relations campaign.