(Update: Because this post is exceedingly long, I have decided to make it available as a printed book: Momentum of Openness It will remain free to read here.) Insider story behind the cover image: Mozilla's mascot derived from the name of the Mosaic browser and the trademarked name of a large mythical beast from Japanese culture which would rise from the oceans to protect mankind against peril. You may see this mythical creature in Bugzilla, or featured in popular web browsers like Chrome when they are having issues addressing your requests. I like to call it "The Mozilla" because it serves as a protector of all that's good. When I first came to the headquarters of Mozilla, I had to get a picture being bitten by the Mozilla. You'll understand why we feel so affectionately about this symbolic icon as you read the story of my journey to web development below.
Foreword
 |
| Shepard Fairey's Dino |
The Winding Way West
Like many people my age, I followed the emergence of the World Wide Web in the 1990’s with great fascination. My father was an engineer at International Business Machines when the Personal Computer movement was just getting started. His advice to me during college was to focus on the things you don't know or understand rather than the wagon-wheel ruts of the well trodden path. He suggested I study many things, not just the things I felt most comfortable pursuing. He said, "You go to college so that you have interesting things to think about when you're waiting at the bus stop." He never made an effort to steer me in the direction of engineering. In 1989 he bought me a Macintosh personal computer and said, "Pay attention to this hypertext trend. Networked documents is becoming an important new innovation." This was long before the World Wide Web became popular in the societal zeitgeist. His advice was prophetic for me.
After graduation, I moved to Washington, DC to work for a financial news wire that covered international business, US economy, World Trade Organization, G7, US Trade Representative, the Federal Reserve and breaking news that happened in the US capital. This era stoked my interest in business, international trade and economics. During my research (at the time, via a Netscape browser, using AltaVista search engine) I found that I could locate much of what I needed on the web rather than in the paid LexisNexis database, which I also had access to at the National Press Building.
When the Department of Justice initiated its anti-trust investigation into Microsoft, for what was called anti-competitive practices against Netscape, my interest was piqued. Philosophically, I didn’t particularly see what was wrong with Microsoft standing up a competing browser to Netscape. Isn’t it good for the economy for there to be many competing programs for people to use on their PCs? After all, from my perspective, it seemed that Netscape had been the monopoly of the browser space at the time.
It was fascinating to me that there were people acting like Jiminy Cricket, Pinocchio's conscience, overseeing the future openness of this nascent developer environment. Little did I know then that I myself was being drawn into this cause. What I took away from the DOJ/Microsoft consent decree was the concept that our government wants to see our economy remain inefficient in the interest of spurring diversity of competitive economic opportunity. Many companies doing the same thing, which seemed like a waste to me, would spur a plurality of innovations that would improve with each iteration. Then when these iterations compete in the open marketplace, they drive consumer choice and pricing competition which by a natural process would lower prices for the average American consumer. In the view of the US government, monopolies limit this choice, keep consumer prices higher, and stifle entrepreneurial innovation. US fiscal and trade policy was therefore geared toward the concept of creating greater open access to world markets in an effort to increase global quality of life through "spending power" for individuals in participating economies it traded with. Inflation control and cross-border currency stability is another interesting component of this, which I'll save for a future blog post.
As someone who used a dial-up modem to connect to the internet at home (DSL and cable/dish internet were not yet common at the time) I had a hard time seeing how web services could offset a multi-billion dollar asymmetry between US and its trading partners. But at one of Mr. Greenspan’s sessions with Barney Frank (One of the legislators behind the "Dodd-Frank" financial reform bill which passed post-financial crisis) asked Mr. Greenspan to talk about the impact of electronic commerce on the US economy. Mr. Greenspan, always wont to avoid stoking market speculation, dodged the question saying that the Fed couldn’t forecast what the removal of warehousing cost could do in impacting market efficiency, therefore markets at large. This speech stuck with me. At the time they were discussing Amazon, a book seller which could avoid typical overhead of a traditional retailer by eliminating brick and mortar storefronts with their inventory stocking burdens. Bookstores allocated shelving space in retail locations for products consumers might never buy. A small volume of sales by inventory therefore would cover the real estate cost of the bulk of items which would seldom be purchased. Amazon was able to source the books at the moment the consumer decided to purchase, which eliminated the warehousing and shelf-space cost, therefore yielding cost savings in the supply chain.
It was at this time that my company, Jiji Press, decided to transition its service to a web-based news portal as well. I worked with our New York bureau team during the process of our network conversion from the traditional telephony terminals we used to new DSL based networks. Because I'm a naturally-inclined geek, I asked lots of questions about how this worked and why it worked better than our terminal style business (which was similar to a Japanese version of Reuters, Associated Press and Bloomberg terminals)
This era came to be called the "dotcom boom" during which every company in the US started to establish a web presence through the launching of web services with a ".com" top level domain name. A highly speculative stock market surge started around businesses that seemed poised to capitalize on this rush to convert to web-based services. Most companies seeking to conduct initial public offerings in this time listed on the Nasdaq exchange, which seemed to have a highly volatile upward trajectory. In this phase, Mr. Greenspan cautioned against "irrational exuberance" as stock market valuations of internet companies were soaring to dizzying proportions relative to the value of their projected sales. I decided that I wanted to move to Silicon Valley to enter the fray myself. It wasn't just the hype of the digital transformation or the stock valuations that enticed me. I had studied the trade pacts of the United States Trade Representative vis a vis the negotiators of the Japanese government. I had a strong respect for the ways that the two governments negotiated to reduce tariffs between the two countries for the benefit of their citizens. I knew that it was unlikely that I could pursue a career path to become a government negotiator, so I decided that my contribution would be in conducting international market launches and business development for internet companies between the two countries.
After a stint working in web development on websites with a small design agency, I found my opportunity to pitch a Japanese market launch for a leading search engine called LookSmart, which was building distributed search engines to power other portals. Distributed search was an enterprise business model, called business to business (B2B), whereby we provided infrastructure support for other portals that had their own direct audiences.
I recruited a team to build the initial Japanese search engine index. This was a curated search directory, a fixed database of authoritative websites on given topics, which we could query with boolean search parameters and integrate into client websites. After my team completed the first build of the database, we demonstrated it to Microsoft, which in turn licensed our search engine to power their MSN branded portals. On this news we listed our company on the Nasdaq stock market and planned a global expansion. We thereafter formed a joint venture with British Telecommunications, called BT LookSmart, to expand the LookSmart search distribution world-wide. I relocated to Sydney as part of the new JV team to build the hosted-search front end pages for our network partners across Asia Pacific region. (With support of a developer team spanning across Australia, Israel and Norway.)
Upon our first site launch, I moved to Tokyo to incorporate LookSmart Japan, hire a local team, and start building a local presence for the company. I turned my focus from product development to prospecting and contracting with local relying business partners, mainly portals.Recruit's Isize portal was the first to partner followed swiftly by other major ISP portal companies (Japan Telecom's ODN, NTT's OCN, KDDI's DION, NEC's Biglobe and Excite Japan) We complemented our offering with an advertising and paid-search indexing service that allowed marketers to promote their sites within our index. Through our revenue sharing partnerships we would return revenues from this to the portals and ISPs which had partnered with us. Over a years-long process of building customized search portals, and conducting gradual business development expansion of our search content and capabilities, we represented with a broad base of the Japanese internet market. As our back-end servers then processed a significant volume of the total Japanese search query volume, advertisers sought to have their sites indexed in sponsored listings at an ever greater pace. 
Yahoo sent me back to Japan to develop and pitch new enhanced mobile search services that I hadn’t been able to offer from the LookSmart toolkit. (British Telecommunications did have a mobile app/portal in Japan which I supported as part of BT LookSmart, but our index was made up of traditional PC-focused web content that rendered poorly on small screens.) With Yahoo’s Tokyo-based team, we developed a mobile-site search index that excluded PC-focused content. We built a special mobile-centric advertising platform based on Yahoo’s patented auction-placement advertising platform. We then had a search indexing capability to uniquely query content that was specially designed for the three major cell network companies across Japan at the time. (Japan Telecom, KDDI, and NTT Docomo, another Softbank company.) We were announced in the Nikkei Business Publications' annual almanac for that year as one of the internet market's leading innovations.
When I'd go to the prospecting meetings on behalf of Yahoo, I'd hear comments in Japanese in the room, "Hey, isn't that the Looksmart guy?" to which I'd humbly ask their ongoing support and consideration. When people asked me to contrast our technologies against Google's I was able to speak from a great deal of experience with them. After all they'd been a partner of Yahoo's and an industry collaborator, even if they were owned by different shareholders. We all had built our distinct offerings on similar techniques of web crawling and algorithmic filtering. And our products leveraged and were protected by the same patents.
Over the course of the ensuing decade, my team continued to expand our licensing and search infrastructure partnerships more broadly. I conducted the search-infrastructure partnerships in Korea, Taiwan, Hong Kong, India, Brazil and Australia with local Yahoo teams. As part of its global expansion in search technology, Yahoo decided to acquire AltaVista, Inktomi, Overture and Fast Search. Eventually, Microsoft decided to give up outsourcing search services and launched their own search engine, branded as Bing, bringing even more competition into the space formerly dominated by Yahoo and Google. Thereafter dozens of subject-specific search providers sprung up to fill niche opportunities in shopping, food and site-specific indexing.
Meanwhile at Netscape
The
team at Netscape may have been disappointed that their world-pioneering
web browser was being a acquired by a company that had a limited view
of the internet, even if AOL had been
pioneers in connecting the unconnected. It was probably a time of soul
searching for Marc Andreessen's supporters, considering that
the idea of Netscape had been one of decentralization, not corporate
mergers. A group of innovators inside AOL suggested that the
threat of a world dominated by Microsoft's IE browser was a risky future
for the world of open competitive ecosystem of web developers.
A small group of engineers inside the company they
persuaded the AOL executives to set up a skunk-works team inside
AOL to open source the Netscape Communicator product. They achieved this by dividing the product into component
parts that could then be uploaded into a modular hierarchical bug triage
tree, which they referred to as Bugzilla. By doing this, they theorized that people outside of AOL could help fix code problems that were cumbersome for internal AOL teams to solve. By allowing contributing developers to "fork" (meaning create derivative products) from the open source code base, they would further incentivize innovation, as those developers could compete based on features they introduced to their derivative products. Because the concept was created with a sense of generosity, they believed that most of the innovations would be shared back to AOL. Succeeding with a small fork is hard. But introducing software patches to the complete global audience of AOL/Netscape would benefit all other developers and users in turn. Of some surprise to me, they didn't make a requirement that forks thereafter be maintained as open source. So some of the employees of Mozilla would thereafter leave the company and launch their own browsers to compete directly. This reminded me of Yahoo's previous act of licensing out its innovations to competitors in the interest of a healthy competitive developer ecosystem. 
The Mozilla Project grew inside AOL for a long while beside the AOL browser and
Netscape browsers. But at some point the executive team believed that
this needed to be streamlined. Mitchell Baker, an AOL attorney, Brendan Eich, the inventor of JavaScript, and an influential venture capitalist named Mitch Kapoor
came up with a suggestion that the Mozilla Project should be spun out
of AOL. Doing this would allow all of the enterprises who had interest
in working in open source versions of the project to foster the effort
while Netscape/AOL product team could continue to rely on any code
innovations for their own software within the corporation.
A
Mozilla in the wild would need resources if it were to survive. First,
it would need to have all the patents that were in the Netscape portfolio to avoid hostile legal challenges from outside. Second, there
would need to be a cash injection to keep the lights on as Mozilla
tried to come up with the basis for its business operations. Third, it
would need protection from take-over bids that might come from AOL
competitors. To achieve this, they decided Mozilla should be a
non-profit foundation with the patent grants and trademark grants from
AOL. Engineers who wanted to continue to foster AOL/Netscape vision of
an open web browser specifically for the developer ecosystem could
transfer to working for Mozilla. (As they announced in their early blog post/announcement: https://blog.mozilla.org/press/2003/07/mozilla-org-announces-launch-of-the-mozilla-foundation-to-lead-open-source-browser-efforts/)
Netscape had created a crowd-sourced web index (called DMOZ or open directory) which had hard-coded links to most of the top websites of the time, aggregated by subject matter specialists who curated the directory in a fashion similar to Wikipedia of today. DMOZ went on to be the seed for the PageRank
index of Google when Google decided to split away from powering the
Yahoo search engine. It's
interesting to note that AOL played a major role in helping Google
become an independent success as well, which is documented in the
book The Search by John Battelle.
Once
the Mozilla Foundation was established (along with a $2 Million grant
from AOL) they sought donations from other corporations who were to
become active on the Mozilla project. The team split out Netscape
Communicator's email component as the Thunderbird email application as a
stand-alone open source product. The browser, initially called Phoenix, was released to
the public as "Firefox" because of a trademark issue with another US
company over the usage of the term "Phoenix" in association with software.
Google, freshly independent from Yahoo, offered to
pay Mozilla Foundation for search traffic that they could route to their
search engine. Taking revenue share from advertising was
not something that the non-profit foundation was particularly
well set up to do. So they needed to structure a corporation that could
ingest these revenues and re-invest them into a conventional software
business that could operate under the contractual structures of
partnerships with public companies. The Mozilla Corporation could
function much like any typical California company with business
partnerships without requiring its partners to structure their payments
as grants to a non-profit.
When Firefox version 1.0 was launched, it rapidly spread in popularity. They did clever
things to differentiate their browser from what people were used to in
the Internet Explorer experience such as letting their users block
pop-up banners or customize their browser with extensions. The largest turning point for Firefox popularity came at a time when there was a vulnerability discovered
in IE6 that allowed malicious actors to take-over the user's browser for
surveillance or hacking in certain contexts. (The vulnerability involved a component called ActiveX.) The US government urged
companies to stop using IE6 and to update to a more modern browser. It
was at this time I remember our IT department at Yahoo telling all its
employees to switch to Firefox. I remember discussing this with my IT team and engineers who ensured me that Firefox plus a Yahoo toolbar was just like the Yahoo browser itself. With this transition Yahoo could give up the burden of keeping their browser up to date, as Mozilla would do all that work and update all users for free on a regular release cadence.
This word-of-mouth promotion happened across the industry and employees would tell friends and families to switch browsers, or customize their browsers the way they did themselves. You suddenly could get toolbars for any site you wanted that could add bookmarks, design themes and search preferences to the Firefox browser. Mozilla seemed to be doing a lot of work to keep the underlying browser updated. Yet this was a synergistic relationship because all the parties who relied on it would promote Firefox with the might of their own marketing channels and web links that promoted their own browser extensions. It was a perfect symbiotic relationship between otherwise unrelated companies because they were working off of a piece of software that was open source. They could have removed the Firefox brand from the open source browser if they wanted to, and many companies did launch forked browsers replacing the Firefox brand with their own brand. But many liked the brand-trust that Firefox itself had. So they promoted "add to Firefox" instead of trying to replace the user's existing browser entirely.
Because Mozilla was a non-profit, as it grew it had
to reinvest all proceeds from their growing revenues back into web
development and new features. (Non-profits can't "cash out" or pay dividends to their shareholders.) So they began to expand outside the core
focus of JavaScript and browser engines alone. Several Mozillians departed to work on alternative open source browsers. The ecosystem grew suddenly with Apple, Google launching
their own open source alternative browser engines on a similar open source model. As these varied browsers grew, the companies
collaborated on standards that all their software would use to ensure
that web developers didn't have to customize their websites to uniquely
address idiosyncrasies of each browser. To this day browsers collaborate to maintain "Web compatibility" across all the different browsers and the extensions model of each so that developers can bring additional product features to the different browsers without having to be built into the browsers themselves.
When I joined Mozilla, there were three major issues that
were seen as potential threats to the future of the open web ecosystem.
1) The "app-ification" of the web that was coming about in new smart-phones
and how they encapsulated parts of the web, 2) The proliferation of
dynamic web content that was locked in behind fragmented social
publishing environments, 3) The proliferation of identity management
systems using social logins that were cumbersome for web developers to
utilize. Mozilla, like a kind of vigilante super hero, tried to create
innovative tactics to propose solutions to address each one of these.
It reminded me of the verve of the early Netscape pioneers who tried to
organize an industry toward the betterment of the entire
ecosystem. To discuss these different threads, it may
be helpful to look at what had been transforming the web in years
immediately prior.
What the Phone Did to the Web and What the Web Did Back
The
web is generally based on html, CSS and JavaScript. A web developer
would publish a web page once, and those three components would render
the content of the webpage to any device with a web browser. What we
were going into in 2008 was an expansion of content publication
technologies, page rendering capabilities and even devices which were
making new demands of the web. It was obvious to us at Yahoo at the
time that the industry was going through a major phase shift. We were
building our web services on mashups of content sources. The past idea of the web was based on static
webpages that were consistent to all viewers globally. What we were going toward
was a sporadically-assembled web tailored to each user individually. The new style of page assembly was marketed as "web 2.0" was frequently called "mash-up" or
"re-mix" using multi-paned web pages that would assemble several
discreet sources of content at the time of page load.
In the midst of this shift to the spontaneously-assembled dynamic web, Apple launched the iPhone. What ensued immediately thereafter was a kind of developer confusion as Apple marketed the concept that every developer wishing to be shown on its phones needed to customize content offerings as an app tailored to the environment of the phone. Apple didn't remove their Safari browser, but they diverted attention to stand-alone app frameworks discovered through the iTunes App Store. The “tunes” part of the iPhone was because it was a derivative product of the earlier-launched MP3 player by Apple called iPod, so everything on the device including software and "Podcasts" had to be synced with a PC through the music player. This was a staging strategy they replaced once the iPhone became a leading brand for the business. Much of this has changed in Apple's new architecture. Nowadays, the app marketplace, music app and podcasts app are all stand-alone products in their own right and AppleID has been "set free" to have other purposes specific to account management and wallet-specific uses.
It seemed strange that users would no longer view content on Apple devices using URLs but rather by downloading individual snippets of content into each developer's own isolated content browser on the user's iOS device. It wasn't just the developers who were baffled. It was the users too! It took a lot of marketing on Apple's part to get people familiar with an entirely new frame of thinking. They had to get people to stop going to their competitors tools to search the web, but instead to have them think "There's an app for that!" as the Apple advertising slogan went. Apple wasn't just trying to confuse the market with this strategy. There are benefits to sand-boxing (meaning to metaphorically isolate a play area from the clean environment around it) different content sources from each other from a privacy and security standpoint. That's what the different frames of AJAX web pages did also. This just took the sand-boxing to an extreme. Apple engineers knew they were going to have a challenging time safeguarding a good user experience on their new phones if there were risks of conflicting code from different programs accessing the same hardware elements at the same time. So the app construct allowed them to avoid phone crashes and bugs by not letting developers talk to each other inside the architecture. Making the developers learn an entirely new coding language to build these apps was also done with a positive intent. They introduced new context-specific frameworks and utilities that were specific to a user-on-the-go. These common frameworks provided consistency of user interface design that was specific to the Apple brand image. Also developers could save time time and cost if they did not need to create these common utilities and design elements from scratch. Theoretically a designer could build an app without the help of an engineer. An engineer could built an app without the help of a designer. It was an efficiency play to maximize participation by abstracting away the complexity of certain otherwise-mundane product concepts.
Seeing the launch of the iPhone capitalize on the concept of the personalized dynamic web, along with the elements of location based content discovery, I recognized that it was an outright rethinking of the potential of the web at large. I had been working on the AT&T partnership with Yahoo at the time when Apple had nominated AT&T to be the exclusive mobile carrier for the iPhone launch. Yahoo had done its best to bring access to web content on low-end phones feature phones. These devices’ view of the web was incredibly restricted. In some ways they felt like the AOL browser. You could get weather, stocks, sports scores, email, but otherwise you had difficulty navigating to anything that wasn't spoon-fed to you by your phone's carrier.
Collaborating with
Yahoo Japan, we'd stretched the limit of what a feature phone could do with mobile-ready web content. We must tip our hats to all that NTT Docomo “iMode” did with feature phone utilities before the touch-screen graphical user interface became mainstream. Japanese customers were amazingly versatile in adapting to the constraints of mobile phones. Users would write entire novels in episodic chapters for mobile phone consumption by commuters! But even at Yahoo we were falling over ourselves trying to help people re-format their sites to fit the small screen. It wasn't a scalable
approach though it bridged users through the transition as the web caught up.
The
concept behind the iPhone was to present bite sized chunks of web content
to the phone specific to the user need in the moment. Breadth was not an advantage in a small screen space at a time when the user probably had limited time and attention. In theory, every existing webpage should
be able to render to the smaller screen without needing to be coded
uniquely.
I don't know any of the team at Apple who made these choices. But I have the sense that I understand the motives of what they were trying to do. In the developer community we have a term for "hacking" or "shimming" solutions to a code problem. This is generally meant in a positive connotation of making-do with what you have to achieve the outcome to address the user need. It's synonymous in our lingo with "improvising" but is not to be confused with the concept of malicious activity to undermine someone or something. (That is the general cultural adoption of the term.) When a hack or a shim is used to make a project fit the project or product's expected acceptance criteria, there is a general understanding that, once time allows, the shim will be removed for a more exact solution. So in my view, Apple shimmed the iPhone project and layered on the unwieldy scaffolding with the expectation and hope that over time those constructs could be removed from the code and replaced with a more user-friendly solution.
Mozilla engineers shared the concerns that Apple had about user pain points of using the web in a mobile context. (I'll speak generally here because there was no explicit company stance about Apple's approaches on this issue. But there was general sentiment that web developers needed some help on the html5 front.) Mozilla aspired to help the mobile adaptation of the web by conducting outreach on the ideas of "responsive web design" which is at the core of html5's purpose. This may sound esoteric. But what it means is that you should leverage your URL as if it is a conversation with the user. A user's browser transmits what's called a header in their http request to visit your site. Ideally, a webpage should listen to who's calling before it answers. If the call comes from a Safari browser on an iPhone, or a Chrome browser on an Android device, your site should be "responsive" in that it returns a mobile-styled format using CSS to respect the limits or specific elements of your page that are relevant to the user's context.
 |
| First Firefox OS Phone |
The Mozilla team envisioned a phone unbound from the app ecosystem. Mozilla's Chief Technical Officer, Brendan Eich, and his team of engineers decided that they could make a web phone using JavaScript and html5 without using the crutch of app-wrappers. The team took an atomized view of all the elements of a phone and sought to develop a web-interface (called an API for application program interface) to allow each element of the device to speak http web protocols such that a developer could check battery life, status of motion, gesture capture or other important signals relevant to the mobile user that hadn't been utilized in the desktop web environment. And they succeeded! The phones launched in 28 countries around the world.
 |
| Christopher presenting at FISL 13 |
 |
| Fabio Magnoni discussing Firefox OS in Brazil |
Mozilla’s engineers suggested that there shouldn’t be the concept of a “mobile web” that was distinct or limited from the broader web. We should do everything we could to persuade web developers and content publishers to embrace mobile devices as “1st class citizens of the web.” So they hearkened back to the concepts in CSS, and championed the concept of device-aware responsive web design with a moniker of “Progressive Web Apps.” The PWA concept is not a new architecture. It’s the idea that a mobile-enhanced URL should be able to do certain things that a phone-wielding user expects it to do. Even though Mozilla discontinued the phone project eventually, the PWA work is being heavily championed by Google for the Android device ecosystem now.
 |
| The first Firefox OS powered TV demonstrated in Barcelona |
The Mozilla html phone launch wasn't intended to overtake the major handset distribution. It was intended to make the point that web browsers were capable of doing the same things that an app wrapper would, so long as developers had access to the capabilities of the device over web protocols. This is one of the most admirable things about the philosophy of Mozilla and the open source community that supports it. An idea can
germinate in one mind, be implemented in code, then set free in the
community of open source enthusiasts who iterate and improve on it. There might be no PWA capability on iPhone and Android devices if Mozilla hadn't tried to launch a phone that had only PWAs. While the open sourcing of Netscape wasn’t the start
of the open source movement, it has contributed significantly to the practice. The
people who created the world wide web continue to operate under the
philosophy of extensibility. The founders of Google’s Chromium
project were also keen Mozilla supporters, even though launching a separate open source browser made them competitors. (Remember the Netscape open sourcing had specifically been for the purpose of spurring competitors to action.) The fact that a different company,
with a different code base, created a similarly thriving open source
ecosystem of developers aiming to serve the same user needs as Mozilla’s
is the absolute point of what Mozilla’s founders set out to promote in the spin-off from Netscape. And it echoes those same sentiments I’d heard expressed back
in Washington, DC back in the late 1990s.
One of the things
that I have studied a great deal,
was the concept of the US patent system. Back in the early days of the
US government, Secretary of State Jefferson created the concept of a
legal monopoly. It was established by law for the government first, then
expanded to the broader right of all citizens, and later all people
globally via the US Patent and Trademark Office. When I was in college I had an invention that I wished to patent and produce for the
commercial market. My physics professor suggested that I not wait until I
finish my degree to pursue the project. He introduced me to another
famous inventor from my college and suggested I meet with him. Armed
with great advice I went to the USPTO to research prior art that might
relate to my invention. Upon thorough research, I learned that anyone
in the world can pursue a patent and be given a 17 year monopoly to protect the invention while the merits of the product-market-fit could be
tested. Thereafter, the granted patent would belong as open source, free
of royalties to the global community. “What!?” I thought. "I am to declare the
goods to the USPTO so they can give it away to all humanity shortly
thereafter once I did all the work to bring it to market? This
certainly didn’t seem like a very good deal for inventors in my view.
But it also went back to my learnings about why the government prefers
certain inefficiencies to propagate for the benefit of the greater
common good of society. It may be that Whirlpool invented a great
washing machine. But Whirlpool should only be able to monopolize that
invention for 17 years before the world at large should be able to reap
the benefits of the innovation without royalties due to the inventor.
My
experiences with patents at Yahoo were also very informative. Yahoo
had regularly pursued patents, including for one of the projects I'd
launched in Japan. But their defense of patents had been largely in the
vein of the “right to operate” concept in a space where their products
were similar to those of other companies. I believed
that the behaviors of Yahoo, AOL and Google were particularly generous
and lenient in patent protection. As an inventor myself, I was impressed with how the
innovators of Silicon Valley, for the most part, did not pursue legal
action against each other. It seemed they actually promoted the
iteration upon their past patents. I took away from this that Silicon
Valley is more innovation focused than business focused. When I launched
my own company, I asked a local venture capitalist whether I should
pursue patents for a couple of the products I was working on. The
gentleman, who was a partner at the firm said, “I prefer
action over patents. Execute your business vision and prove the market
value. Execution is more valuable than ideas. I’d rather invest in someone who can execute rather than someone who can just invent.” And from the 20 years I’ve seen here,
it always seems to be the fast follower rather than the inventor who
gets ahead, probably precisely because they focus on jumping directly to
execution rather than spending time scrawling protections and
illustrations with lawyers.
Mozilla has, in the time I’ve worked
with them, focused on implementing first in the open, without thinking
that an idea needed to be protected separately. Open source code exists
to be replicated, shared and improved. When AOL and the Mozilla team open sourced the code for Netscape, it was essentially opening the
patent chest of Netscape intellectual property for the
benefit of all small developers who might wish to launch a browser
without the cumbersome process of watching out for the licenses for the
code base. Bogging down developers with patent encumbered code
would slow those developers from seeking to introduce their own unique
innovations. Watching a global market launch of a new mobile phone based
on entirely open source code was a phenomenal era to witness. And it
showed me that the benevolent community of Silicon Valley’s innovators
had a vision much akin to those of the people I’d witness in Washington,
DC. But this time I’d seen it architected by the intentional acts of
thousands of generous forward-thinking innovators rather than
through the act of legislation or legal prompting of politicians.
The Web Disappears Behind Social Silos
The
web 2.0 era, with its dynamically assembled web pages, was a tremendous
advance for the ability of web developers to streamline user
experiences. A page mashed-up of many different sources could enhance
the user’s ability to navigate across troves of information that would
take a considerable amount of time to click and scroll through. But
something is often lost when something else is gained. One of the boons of the web 1.0 era was the idea that a website was
relatively static set of components that were hosted on a URL on a given
day. So my search engine company Looksmart could have a fairly
authoritative index of the entire internet as it would look to any user
across the world. One fascinating project that continues to this day is a
search engine that retains a static view of what every major URL looked
like on the day it was indexed. So today you can see what Mozilla's
webpage looked like in 1999.
I often wondered what the advent of web 2.0 would do to the Internet
Archive. In 100 years would it seem that history of web archiving
stopped abruptly when users went from static html to dynamic
profile-based page loads? One thing was for certain, it seemed that
there would no longer be a consistent view of the web across the world.
Users in certain countries are now excluded from access to content that
the same user would be able to see if their IP address was determined to
be a local to the site host. In many cases this has nothing to do with
the opinion of the local government. Rather it had to do with whether
the specific site host believes it is important to make content
available to those outside the country or perhaps a deliberate decision
to exclude international users because the site hosting costs were too
great to support them, or because of some content licensing restriction
for content featured on their domain. This is a bit of a sad impact to
the freedom of information access globally, especially to people in
countries where it is hard to get access to content locally. But it is
also a kind of degradation of what the web's pioneers had intended.
Retrospectively, history most likely show a more narrowed web in the
archive as all the dynamic pages will not be saved. What happened there
is robustly logged and tracked in the moment. But it won't be
reassembled for viewing in the future. It is now a much more ephemeral
art.
When Twitter
introduced its micro-blog platform, end users of the web were able to
publicize content they curated from across the web much faster than
having to author full blog posts and web pages about content they sought
to collate and share. Initially, the Twitter founders maintained an
open platform where content could be mashed-up and integrated into other
web pages and applications. Thousands of great new visions and
utilities were built upon the idea of the open publishing backbone it
enabled. My own company and several of my employers also built tools
leveraging this open architecture before the infamous shuttering of what
the industry called “The Twitter Firehose”.
But it portended a phase shift yet again of the very early social web. The Twitter we knew of became a diaspora of
sorts as access to the firehose feed was locked down under identity
protecting logins. This may be a great boon to those seeking anonymity
and small “walled garden” circles of friends. But it was not
particularly good for what may of the innovators of web 2.0 era hoped
for, the greater enfranchisement of web citizenry.
The
early pioneers of the web wanted to foster an ecosystem where all
content linked on the web could be accessible to all, without hurdles on
the path that delayed users or obscured content from being sharable.
Just as the app-ified web of the smartphone era cordoned off chunks of
web content that could be gated by a paywall, the social web went into a
further splitting of factions as the login walls descended around
environments that users had previously been able to easily post, view and share.
The parts of the developer industry that
weren’t mourning the loss of the open-web components of this great
social fragmentation were complaining about psychological problems that
emerged once-removed from the underlying cause. Fears of censorship and
filter-bubbles spread through the news. The idea that web citizens now
had to go out and carefully curate their friends and followers led to
psychologists criticizing the effect of social isolation on one side and
the risks of altering the way we create genuine off-line friendships on
the other.
 |
| Hugh Finnan and Todd Simpson demo browser WebRTC |
 |
| Shared web session in Firefox Hello |
Part of the benefit of WebRTC was that the connection over internet protocol enabled use cases beyond just staring at web camera images. Our users could share content in real time such as webpages they were viewing, pictures and potentially web streaming. But we didn’t have a concept of file storage or transfer. We knew that this was a particular pain point for our users. For instance if they wanted to share pictures, but couldn’t do it over a web viewing session in Firefox Hello, they typically had to be sent via an email host. Most email hosting services only permitted sharing a few pictures, because of message file limits. Even in Thunderbird users could only share as many megabytes in a message as their email host permitted.
The past decade has drastically changed the general concept of what is a social network when it comes to the web. Many people don't think of Mozilla specifically as a social network. But when the AOL team created the Bugzilla platform for open sourcing the code tree of Netscape, they essentially had created a highly-efficient purpose-built social network for collaboration in software. In our community and company we had discussions around codes of conduct to foster and enforce the well-being of our community via our social platforms. We had suffered incidents of trolling, inappropriate political commentary, inappropriate biased language and all the general problems that later arose in other web social platforms. But we dealt with them by engaging and dialoging about them with the community participants. We didn’t algorithmically try to solve something that was a fundamental human decency issue. We faced it directly with discussions about decency and agreements about our shared purpose. We viewed that we were custodians of a collaborative environment where people from all walks of life and all countries could come together and participate without barriers or behaviors that would discourage or intimidate open participation. Some people in the community opined that if Mozilla had continued expanding its social networking initiatives around community tools, communication and services, they might have had some good demonstrable examples of how to address ills that other public social networks face today.
The movement of the web-based social network resulted in a new concept of content indexing and display in an atomized way. A personalized webpage looks radically different to every individual viewing it. Some of these shifts in content discovery were beneficial. But some of the personal data that powered these webpages led to data breaches and loss of trust in the internet community. Mozilla’s engineers thought they could do a great deal to improve this. One of the things the Mozilla team thought it could address was the silo and lock-in problem of web authentication.
The social web services introduced a Babel-like plethora of social logins that may have been a boon for the creation of quick login options for an emerging startup. But it came with a mix of problems for the web at the same time. Website authors had to go through particular effort to integrate multiple 3rd party code tools for these social logins to be used. So Mozilla focused on the developer-side problem. As the social web proliferated, webmasters were putting many bright icons on their websites with prompts to sign in with five or more different social utilities. It could lead to confusion because the site host never knew which social site a user had an identity registered through. So if a user visited once and logged in with Twitter, and another time accidentally logging in with Facebook, their personalized account content might be lost and irretrievable.
This movement was well received initially, but many supporters
called for a more prominent architecture to show the user where their logged
identities were being stored. So Mozilla morphed the concept from
a host-agnostic tool to the idea of a client-agnostic "Firefox Account" tool that could be accessed
across all the different copies of Firefox a user had (on PCs, Phones,
TVs or wherever they browsed the web) and even be used in other browsers or apps outside of Mozilla's direct control. With this cloud service infrastructure users could synchronize their application preferences across all their devices with highly
reliable cryptography to ensure data could never be intercepted between
any two paired devices.
The other great inconvenience of the social web was the number of steps necessary for users to communicate conventional web content on the social web. Users would have to copy and paste URLs between browser windows or tabs if they wished to comment or share web content. There was of course the approach of embedding social hooks into every webpage in the world one might want to share as a work-around. But that would require web developers for every web site to put in a piece of JavaScript that users could click with a button to upvote or forward content. If every developer in fact did that, it would bog down the page loads across the entire internet with lots of extraneous code that had to be loaded from public web servers. Hugely inefficient, as well as being a potential privacy risk. Turning every webpage into a hodge-podge of promotions for the then-popular social network didn’t seem like and elegant solution to Mozilla’s engineers. It seemed to be more of a web plumbing issue that could be abstracted to the browser level.
Fortunately, this was obvious to a large number of the web
development community as well. So the Mozilla team along with Google's Chrome team put their heads together on a solution
that we could standardize across web browsers so that every single
website in the world didn’t have to code in a solution that was unique
to every single social service provider. The importance of this was
also accentuated when the website of the United States government integrated a social engagement platform called AddThis, that was found to be
tracking the visits of people who visited the web page with tiny code
snippets that the government's web developers hadn’t engineered. People
generally like the idea of privacy when visiting web pages. The
idea that a visit to read what the president had to say came along with a
tradeoff that readers were going to be subsequently tracked off of that specific site later appeared particularly risky.
To enable a more privacy-protecting web, yet enable the convenience users sought of engaging with social utilities, Mozilla Labs borrowed a concept from the Progressive Web-App initiative coming out of the Firefox phone work. PWAs utilized the concept of a user “intent.” Just as a thermostat in a house expresses the thermostat’s setting as a “call for heat” from the house’s furnace, there needed to be a means for a user to have an “intent to share” that could be simply expressed at the interface level of the browser to avoid needing anything altered in the page. Phone manufacturers had enabled a similar concept of sharing at the operating system level for the applications that users downloaded, each with its own embedded sharing API, a browser needed to have the same capability.
 |
| Social API implementation demonstration page |
To achieve this in the browser, we used the concept of a “Social API.” An API (application program interface) is a kind of digital socket or “hand-shake” protocol that can mediate between programs when the user starts a push or pull request. As an example, Thunderbird email software can interface effortlessly with an email host account (such as gmail or hotmail) using an API, if the user of the software authenticates for their program to make such requests on their behalf. It is similar to a browser extension, but it could be achieved without pushing software to the user.
Just as Firefox Accounts could sync services on behalf of a user without knowing any of the details of the accounts the user requested to sync, so too should it be able to recognize when a user wants to share something without having the user dance around between browser windows with copy and paste.
So Mozilla explored the concept of browsers supporting “share intents” just like the vendors of phones and PCs did at the time to support the convenience of social utilities. Because many of these services had the concept of notifications, we explored the "publisher side" intents as well. The user convenience introduced by doing this meant that they didn’t have to always be logged into their social media accounts in order to be notified if something required their attention or to receive an inbound message.
At the time, there was a highly-marketed trend in Silicon Valley around the idea of “gamification” in mobile apps. This was a concept that web developers could give you points and rewards to try to drive loyalty and return visits among web users. Notifications were heralded by some as a great way to drive the sense of delight for visitors of your website along with the opportunity to lure them back for more of whatever you offered. We wondered, “Would developers over-notify?” to try to drive traffic to their site at an attention burden cost to the user. There was a potential for over-saturation and distraction of user attention which could be a worse cost to the user’s attention and time than it was a benefit for them.
Fortunately,
we did not see huge notification abuses from the sites that supported
Social API. We did receive widespread interest from the likes of
Facebook, Twitter, Yahoo, Google which were the major messaging service
providers of the day. And so we jointly worked to up-level this to the
web standards body called the World Wide Web Consortium (abbreviated as
the W3C) for promotion outside the
Firefox ecosystem, so that it could be used across all web browsers which supported W3C standards.
Working with this team I learned a great deal from my peers in the engineering organization. First I thought, if this is such a great idea, why doesn’t Firefox try to make this a unique selling point of our software? What’s the rush to standardize this? Jiminy Cricket voices across the organization pointed out that the goal of our implementation of open source code in the browser is precisely to have others adopt the greatest ideas and innovate upon them rather than to hold them dear. The purpose of the standards organizations we worked with was specifically to pass on those innovations so that everyone else could utilize them without having to adopt Firefox-specific code. Good ideas, like the USPTO’s concept of eventual dissemination to the broader global community, are meant to spread to the entire ecosystem so that webmasters avoid the pitfall of coding their website to the functionality of a single piece of software or web browser. Mozilla engineers saw their mission as in part being to champion web-compatibility. (Often shortened to webcompat in our discussions.) Firefox is a massive population of addressable users. But we want web developers to code for all users to have a consistently great experience of the web, not just our audience of users. There is a broad group of engineers across Microsoft, Google, Apple, Samsung, Mozilla and many small software developers who lay down the flags of their respective companies and band together in the standards bodies to dream of a future internet beyond the capability of the software and web we have today. They do this with a sense of commitment to the future we are creating for the next generation of internet, software and hardware developers who are going to follow our footsteps after us. Just as we inherited code, process and standards from our forebears, it is the yoke of our current responsibility to pass on the baton without being hampered by the partisanship of our competing companies. We have to build the web today for future generations which are going to be set up for success in facing new demands of the technology environment we will create for tomorrow.
Over the course of the Social API project, Firefox, Chrome and the new Edge browser of Microsoft would implement different models of addressing the use case of the target issue we were solving for. Over time, we agreed to ways that the tools could be standardized and we then upgraded our software to perform in a consistent way between our products on different operating systems.
During the early craze about social media, there were a lot of critics about the ease of sharing, sometimes potentially private information, for users that were perhaps unfamiliar with the risks of privacy exposure on such platforms. Facebook had been commissioning studies on the psychological benefits and pitfalls of social media use. During one of our company all-hands I posed this issue to one of my mentors, a Mozillian engineer named Shane Caraveo. “Shouldn’t we be championing people to go off these social platforms to build their own web pages instead of facilitating greater usage of the conveniences of social tools?” Shane pointed out that Mozilla does do that through the educational tools on the Mozilla Developer Network, which demonstrates with code examples exactly how to build your own website. Then Shane made a comment that has sat with me for years after. “I don’t care how people create content and share it on the internet. I care that they do.”
The First Acquisition
The standardization of web notifications across browsers one of the big wins of our project. The other, for Mozilla specifically, was the acquisition of the Pocket content aggregation and recommendation engine. When I worked at Yahoo, one of the first acquisitions they had made was the bookmark backup and sharing service del.icio.us. Our Yahoo team had seen the spread of the social web-sharing trend as one of the greatest new potentials for web publishers to disseminate their creations and content. They had built their own social networks called Yahoo360 and Yahoo Answers and had acquired other social sharing platforms including upcoming.org and flickr.com during the same period. These social sharing vectors bolstered the visibility of web content by earning the praise and inspiring the subsequent desire to “re-post” content among circles of friends. Many years later, Yahoo sold the cloud bookmarking business to the founder of YouTube who sought to rekindle the idea, and created a SocialAPI socket for Firefox.
Saving web content may seem like a particularly fringe use case for only the most avid web users. But the Pocket service received considerable demand. With funding from Google’s venture investing arm among others, Nate was able to grow Pocket considerably, and even expand into a destination website where users could browse the recommendations of saved content from other users in a small tight-knit group of avid curator/users. It was perhaps the decentralization of Pocket’s approach that made it work so well. The article saving behaviors of millions of Pocket users produced a list of high quality content that was in no way influenced by the marketing strategies of the news publishing industry. It served as a kind of barometer of popular opinion about what was trending across the web. But not just for what was popular, rather what people wanted to save for their own reference later.
Because Google has already invested in Pocket, I had thought that it was more likely that they would join the Chrome team eventually. But by a stroke of good fortune, the Pocket team had a very good experience with working alongside the Mozilla team and decided that they preferred to join Mozilla to pursue the growth of their web services. This was the first acquisition Mozilla had executed. Because I had seen how acquisition integrations sometimes fared in Silicon Valley, I had some fascination to see how Mozilla would operate another company with its own unique culture.
Mozilla post-acquisition used the Pocket platform as a content sharing and discovery tool within the new tab portion of the browser so that when Firefox users spawned a new page, they could see recommendations from the peer community of Firefox users much in a similar fashion to how the original Netscape browser featured recommended websites in its Open Directory, curated by Netscape users 20 years prior. Mozilla didn’t discontinue Pocket initiatives outside of Firefox after the acquisition and integration. Pocket continues to support all browsers that compete with Firefox still today. The community of Pocket users and contributors continues to stay robust and active even beyond the existing Firefox user base.
Emerging Technologies
 |
| Mozilla Hubs VR development platform |
Mozilla's Emerging Technology team evaluates new opportunities that web technology can be applied to next-generation challenges. They do this so that the web remains a preferred option for developing future tools that might otherwise be app based. As an example, as developers begin to build 3D Virtual Reality content experiences, Mozilla’s engineers realized that there needed to be an expanded means for 3D content to be served on the web without needing complex software downloads. So they created a means of using JavaScript to embed 3D graphics inside of web pages or serve 3D content rendered inside the browser itself, through an initiative called aframe.io. They also launched a web development utility called Hubs for first-time developers to become familiar with building 3D spatial and audio landscapes inside a simple drag-and-drop dashboard tool, complete with free hosting for developers who wished to host small events online in the simulated 3D chat rooms. For larger events such as the Augmented World Expo and the Mozilla all-hands meetings, they built out conference-sized deployment capability for the Hubs platform and would host their own developer events in the virtual space as well.
Aside from visual aspects of the expanding internet, the trend of using voice-based robot assistants began to gain momentum as Apple, Google and Amazon each launched their own audio concierge tools. (They were Siri, Hey Google and Alexa respectively.) Mozilla has a large group of engineers who specifically work on tools for content-accessibility for people who have sight or hearing impairments. So expanding the ability for web services to read content to users without a screen, or to listen to user prompts, became an area of central focus for Mozilla Emerging Technology team.
 |
| Andre Natal presents on Voice APIs at Mozilla |
 |
| "Read Page" built into Firefox Reader Mode |
Parallel to listening to voice commands in Mozilla's products, Mozilla was actively working on allowing the Firefox browser and Pocket apps to read narrative text to the user. In Firefox, all the user has to do is click into "Reader Mode" in the toolbar to see the speech prompt at the left of the browser frame. There a user can select from various spoken accents that you wished Firefox to use in the narration.
 |
| Mozilla's Common Voice active-reading donation page |
If a browser can read and listen, what do you do for an encore? Mozilla's answer to this was to make sure that developers could access raw open source audio and speech processing algorithms to make their own speech tools. As Mozilla had a large base of contributors who were excited to donate samples of their accents and speech style to the project, they created a portal where people from around the world could read sample text aloud, then to be validated for accuracy of intelligibility to another contributor of the same language. The Common Voice audio sample set is now one of the largest open source voice sample databases in the world.
 |
| Mozilla WebThings Gateway distributed by OKdo |
With the advent of new internet-ready hardware devices in the home, Mozilla saw a new opportunity to leverage the privacy concepts of web enabled device API from the FirefoxOS era to provide their own in-home router tools. This tool could act as a secure gateway to those devices instead of having each device connect independently over the web to sundry service vendors. The Emerging Technology team borrowed many of the concepts that stemmed from the PWA initiative to allow a person's home computer to serve as the primary interface for the dozens of home appliances a person might have. (WebThings Gateway could control lamps, speakers, TVs, doorbells and webcams.) This avoided the need to have dozens of separate applications to control the many different utilities you might have at home and made sure access to them was “fire-walled" from outside control. The benefit of doing this was that many of these devices were incompatible with each other. So if we were to use a common command language, such as http to communicate between the router and the devices we could enable coordinated behaviors for linked devices even if they were manufactured by different companies or utilized incompatible radio frequencies with the other devices in the room. Mozilla WebThings Gateway was distributed by original equipment manufacturer OKdo as kits that could be launched out of the box and configured in the user’s web browser.
Protection of Anonymity
One of the most fascinating industry-wide efforts I saw at Mozilla was the campaign behind protecting user anonymity requests and initiatives to enable pseudonymity for users. (Using a pseudonym means calling my website “ncubeeight” instead of “Christopher’s Page” for instance. The way Mark Twain authored books under his nom de plume rather than his birth name.) As social networking services proliferated in the Web 2.0 era, there were several mainstream services that sought to force users into a web experience where they could have only one single, externally verified, web identity. The policy was lambasted in the web community as a form of censorship, where internet authors were blocked from using pen-names and aliases.
On
the flip side of the argument, proponents of the real-name policy
theorized that anonymity of web identities led to trolling behaviors in
social media, where people would be publicly criticized by anonymous
voices who could avoid reputational repercussions. This would, in
theory, let those anonymous voices say things about others that were not
constrained by the normal ethical decency pressures of daily society.
Wired
magazine wrote editorial columns against real names policies saying
that users turn to the web to be whomever they want to be and express
anonymously ideas that they couldn't without multiple pen-names. A
person’s web identity (Sometimes referred to as “handles” from the early
CB radio practice of using declared identities in radio transmissions)
would allow them to be more creative than they otherwise would. One
opinion piece suggested that the web is where people go to be a Humpty
Dumpty assortment of diverse identities, not to be corralled together as
a single source of identity. I myself had used multiple handles for my
web pages. I wanted my music hobby websites, photography website and
business websites to all be distinct. In part, I didn’t want business
inquiries to be routed to my music website. And I didn’t want my
avocation to get tangled with my business either.
European
governments jumped in to legislate the preservation of anonymity with
laws referred to as “Right to be forgotten” which would force internet
publishers to take down content if a user requested it. In a world
where content was already fragmented in a means detached from the
initial author, how could any web publisher comply with individual
requests for censorship? It wasn’t part of the web protocol to
disambiguate names across the broader internet. So reputation policing
in a decentralized content publishing ecosystem proved tremendously
complicated for web content hosts.
Mozilla championed investigations, such as the Coral Project,
to address the specific problems of internet trolling when it was
targeted to public commenting platforms on news sites. But as a
relatively small player in the broader market, it would have been
challenging to address a behavioral problem with open source code. A
broader issue was looming as a threat to Mozilla’s guiding principles.
The emergence of behaviorally-targeted advertising that spanned across
websites loomed as a significant threat to internet users’ right to
privacy.
The founders of Mozilla had decided to pen a manifesto
of principles that they established to keep as the guiding framework for
how they would govern projects that they intended to sponsor in the
early days of the non-profit. (The full manifesto can be read here: https://www.mozilla.org/en-US/about/manifesto/)
In general, the developers of web software have the specific interests
of their end users at the forefront of their minds as their guiding light. They woo customers to their
services and compete with other developers and products by introducing new utilities that
contribute to the convenience and delight of their users. But sometimes
companies that make the core services we rely on have to
outsource some of the work they do to bring the services to us. With
advertising, this became a slippery slope of outsourcing. The
advertising ecosystem’s evolution in the face of the Web 2.0 emergence,
and the trade-offs publishers were making with regard to end-user
privacy, became too extreme for Mozilla’s comfort. Many outside Mozilla
also believed the compromises in privacy that were being made were
unacceptable from the standpoint of the assurances they wanted to offer their end-users. They were willing to band together with Mozilla to do something about it.
While this
is a sensitive subject that raises ire for many people, I can
sympathize with the motivations of the various complicit parties that
contributed to the problem. As a web publisher myself, I had to think a
lot about how I wanted to bring my interesting content to my audience.
Web hosting cost increases with the volume of audience you wish to
entertain. The more people who read and streamed my articles, pictures,
music and video content, the more I would have to pay each month to
keep them happy and to keep the web servers running. All free web
hosting services came with compromises. So, eventually I decided to pay
my own server fees and incorporate advertising to offset those fees.
Deciding
to post advertising on your website is a concession to give up
control. If you utilize an ad network with dynamic ad targeting, the
advertising platform makes the decision of what goods or services show
up on your web pages. When I was writing about drum traditions from
around the world, advertisers may think my website was about oil drums,
and it would show ads for steel barrels on my website. As a web
publisher, I winced. Oil barrels aren’t actually relevant to the people
who read about African drums. But it paid the bills, so I tolerated it.
And I thought my site visitors would forgive the inconvenience of seeing
oil barrels next to my drums.
I was working at Yahoo when the
professed boon of behavioral advertising swept through the industry.
Instead of serving semantically derived keyword-matched ads for my drum
web page, suddenly I could allow the last webpage you visited to buy
“re-targeting” ads on my webpage to continue a more personally relevant
experience for you, replacing those oil barrel ads with offers from
sites that had been relevant to you in your personal journey yesterday,
regardless of what my website was about. This did result in the
unsightly side effect that products you purchased on an ecommerce site
would follow you around for months. But, it paid the bills. And it paid
better than the mis-targeted ads. So more webmasters started doing it.
Behaviorally targeted ads seemed like a slight improvement in a generally under-appreciated industry at the start. But because it worked so well, significant investment demand spurred ever more refined targeting platforms in the advertising technology industry. Internet users became increasingly uncomfortable with what they perceived as pervasive intrusions of their privacy. Early on, I remember thinking, “They’re not targeting me, they’re targeting people like me.” Because the ad targeting was approximate, not personal. I wasn’t overly concerned.
One
day at Yahoo, I received a call. It had been escalated though their
customer support channels as a potential product issue. As I was the
responsible director in the product channel, they asked me if I would
talk to the customer. Usually, business directors don’t do customer
support directly. But as nobody was available to field the call, I did.
The customer was actually receiving inappropriate advertising in their
browser. It had nothing to do with a Yahoo hosted page which has
filters for such advertising. But it was caused by a tracking cookie
that the user, or someone who had used the user’s computer, had acquired
in a previous browsing session. I instructed the user how to clear
their cookie store on their browser, which was not a Yahoo browser
either, and the problem resolved. This experience made me take to heart
how deeply seriously people fear the perceived invasions of privacy
from internet platforms. The source of the problem had not been related
to my company. But this person had nobody to turn to to explain how web
pages work. And considering how rapidly the internet emerged, it dawned
on me that many people who’ve experienced the internet’s emergence in
their lifetime likely couldn’t have had a mentor or teacher tell them
about how these technologies worked.
 |
| Mozilla's Manifesto of 10 principles |
Most savvy web users do know what
browser cookies are and where to find them, and how to clear them if
needed. But one of our security engineers pointed out to me that we
don’t want our customers to always be chasing down errant irritating
cookies and flushing their browser history compulsively. This was
friction, noise and inconvenience that the web was creating for the
web’s primary beneficiaries. The web browser, as the user’s delegated
agent, should be able to handle these irritations without wasting time
of their customers, causing them to hunt down pesky plumbing issues in
the preference settings of the software. The major browser makers
banded with Mozilla to try to eradicate this ill.
At first it
started with a very simple tactic. The browser cookie had been invented
as a convenience for navigation purposes. If you visited a page and
wanted to navigate back to it, there should be a “back button” that lets
you find it without having to conduct another search. This was the
need the cookie solved. Every web page you visit sets a cookie if they
need to offer you some form of customization. Subsequently, advertisers
viewed a visit to their webpage as a kind of consent to be cookied,
even if the visit happened inside a browser frame, called an inline
frame (iframe). You visited Amazon previously, surely you’d want to come
back, they assumed. There should be a kind of explicit statement of
trust which had been described as an "opt-in" even though a visit to a
web destination was in no way a contract between a user and a host.
Session history seemed like a good implied vector to define trust.
Except that not all elements of a web page are served from a single
source. Single origin was a very Web 1.0 concept. Dynamically
aggregated web pages pulled content, code and cookies from dozens of
sources in a single page load in the modern web environment.
The environment of trust was deemed to be the 1st-party relationship between a site a user visits in their web browser and the browser “cookie cache.” This cache served as a temporary passive client-side history notation that could be used in short time frames for the browser to have a kind of bread crumb trail of sequential visits. (In case you want to go back to a previously visited URL that you hadn’t saved to bookmarks for instance.) Cookies and other history tracking elements could be served in iframe windows of the webpage. the portion of the web page that web designers “outsource” to external content calls. When cookies were sent to a browser cache in the passive iframe window, that wasn’t controlled by the site host, Firefox stored those with a notation attribute that they came from outside the 1st-party context of the site the user explicitly navigated to.
In the browser industry, Firefox and Safari teams wanted to quarantine and forcibly limit what cookies in this “3rd party context” could do. So we created policies that would limit the time such cookies could stay active after their first setting. We also introduced a feature in the browser that users could turn off the ability for certain sites to set 3rd party cookies at all. While this was controversial at first, Mozilla engaged with the developer and advertising technology companies to come up with alternative means to customize advertising that did not involve excessive dependencies on dropping cookies that could annoy the user.
Browser makers tended to standardize the code handling of web content across their separate platforms by the W3C or other working groups. And in order to create a standard, there had to be a reference architecture that multiple companies could implement and test. The first attempt at this was called “Do not track” or DNT for short. The DNT preference in Firefox, or any other browser, would be sent to each website when the first load happens. This seemed innocuous enough. It allowed the page host to remember the session as long as necessary to complete the session. Most viewed that the DNT setting in a browser was a simple enough statement of the trust environment between a web publisher and a visitor for the purpose of daily browser usage.
 |
| Harvey Anderson testifies on DNT support across browsers in US Senate |
 |
| Mozilla Lightbeam browser cookie affiliation tracker |
Now the broader consumer industry is keenly aware of the privacy risks that can surface on the web. Open source web browsers are proving to be one of the best ways to protect users against risks they might encounter, through the sharing of best-practices and open policy and governance that is transparent across the ecosystem. Now dozens of browsers leverage the core rendering engines of WebKit, Chromium and Gecko as part of their underlying code. So should any new vulnerability be discovered, in any of them, all of the contributors to the various rendering engines can patch the vulnerability and pass the improved code down through heirs downstream.
How They Do It
You may be asking yourself how companies like Google, Apple and Mozilla develop their browsers in such a way that anyone can help fix them. The important part is openness. Just like the US Patent and Trademark office, there is a built in mechanism that the innovations of today get passed on to the developers who will iterate them tomorrow. That which doesn't change, doesn't grow. So if we have thousands of people contributing code to fix our products, they will get better based on the broad base of support.
Working in the open was part of the original strategy AOL had when they open sourced Netscape. If they could get other companies to build together with them, the collaborative work of contributors outside the AOL payroll could contribute to the direct benefit of the browser team inside AOL. Bugzilla was structured as a hierarchy of nodes, where a node owner could prioritize external contributions to the code base and commit them to be included in the derivative build which would be scheduled to be released as a new update package every few months.
Module Owners, as they were called, would evaluate candidate fixes or new features against their
own list of items to triage in terms of product feature requests or complaints from their own
team. The main team that shipped each version was called Release Engineering. They cared less
about the individual features being worked on than the overall function of the broader software
package. So they would bundle up a version of the then-current software that they would call a
Nightly build, as there were builds being assembled each day as new bugs were up-leveled and
committed to the software tree. Release engineering would watch for conflicts between software
patches and annotate them in Bugzilla so that the various module owners could look for conflicts
that their code commits were causing in other portions of the code base.
 |
| Christopher presenting on launch of Social API in public Air Mozilla |
Over the years Mozilla has evolved the ways that people of all backgrounds and in all locations can contribute. The simplest way to contribute is to be a user of the software and to make comments on Support.mozilla.org if you ever have a problem, the user forums for Q&A about the products. For those who are willing to roll up their sleeves and dive into some specifics of product issues and their function, there is bugzilla.mozilla.org where we actually comment on issues in the software and allocate resources to resolve them. The various internet policy and advocacy issues are detailed on mozilla.org along with multiple ways people can get involved in the mission. But even passive use of the products contributes to their refinement as the Mozilla software has automatic program health utilities that can report system issues that are encountered by many users, entirely anonymously. So just by surfing the web and reporting any crashes through the automated reporting helps Safari, Chrome and Firefox get better.
How Partners Help
After Mozilla had acquired Pocket, they asked me to relocate to Germany to prospect for new partnerships across Europe. Germany has been the largest geographical distribution of Mozilla software outside of North America. Having studied German extensively in high school and college, I was excited to face this challenge. My wife and I relocated to Berlin, where we decided to live in the heart of the former East Berlin. We found an apartment close to the Fernsehturm (literally Far-seeing Tower, mundanely called TV tower in English) that rises triumphantly above the small isle where Berlin was founded over 800 years ago.
In Germany, more people download Firefox than all the people who use the browser included as the default on their personal computers. Why should this be? I was very enthusiastic to find out. Over months I interviewed people about their preferences, world view and fascinations. Put simplistically, many people told me that Germans really like choice and that they are skeptical of anything that is handed to them with the implication of convenience. So they may really like their Windows PC. But they want to get their software from somewhere else, not the company that powers their PC. This attitude isn’t an anti-authoritarian phobia that Microsoft has aspirations to consolidate their user data. It was rather an idea that where a choice is given, Germans relish that choice.
Beyond the stated preferences for self-determined future, I heard common references to the idea that our German customers liked the fact that Mozilla was non-profit and that the software was open-source and therefore entirely subject to peer-review for any additions or subtractions Mozilla decided to make to the software at a later date.
There are other factors beyond the casual commentary I’d heard that likely influenced the perspectives of the people I’d talked to. The percentage of the German population who subscribe to newspapers and journalistic magazines is higher than many countries in Europe and far higher than North America. I suspect that media coverage of internet-based malware vulnerabilities is heightened in Germany to the extent that many of the web participants there take special care about their digital hygiene. Specifically the German ministry for security in information technology (Abbreviated as “BSI” as abbreviation for Bundesamt für Sicherheit in der Informationstechnik more at https://www.bsi.bund.de) has been very articulate in publicizing its insights about malware/phishing risks, which are then amplified by the German press. This is not to say that any web browser these days is particularly better or worse than another. (Edge and Chrome are based on Blink/Chromium, Telekom Browser and Firefox is based on Gecko, Safari and dozens of mobile apps are based on Webkit. All are modern browsers with active bug fixing, zero-day response teams and are open source.) But in a marketplace where there is heightened attention on all aspects of the industry from shareholders to business models, we can expect a tremendous diversity of user choice to be expressed. The result of user choice in such an arena isn’t something that is swayed by a majority view, nor the company with the best marketing, nor the company with the best operating system bundling. Absolutely everything is put to a vote every day.
As an American, I would say that I’m open to promotions. I’d be inclined to take offers on face value. I may even be more fickle and transitory in my decisions as a consumer on the internet. But from what I have heard from my discussions with my customers, partners and end users in Germany, I’d say they are the opposite. Generalizing a bit too far perhaps, I believe that the German audience is discerning, reluctant to shift behaviors, wary of any offer or promotion and more likely to go by word-of-mouth or journalistic recommendations than the typical American user.
Mozilla had tremendous momentum in Germany prior to my arrival of course. Looking back across the decades, word of mouth around the emergence of Mozilla from Netscape may have played a partial role, along with endorsements from the BSI for their open-source and privacy reputation. But thereafter, leading internet service providers, Deutsche Telekom, 1&1 and leading portal web.de started recommending Gecko/Firefox as an alternative to IE and Safari. This somewhat underscores the value of partnerships in Germany. I wouldn’t say that these companies needed to be particularly rewarded in order to offer choices to their own customers. If they had said that their services were only available in IE and Safari, many of their customers might have been skeptical and might have switched away. But the fact that they offered to support their users in IE and Firefox, led to a lot of people going with the “underdog” non-profit instead of the browser that had been served to them as a bundled part of their operating system.
Deutsche Telekom’s version of the Gecko browser didn’t even leverage the Netscape, nor Firefox brand. For them, a skinned version of Gecko, combined with certain features they added onto the open source browser was enough to get the user to want to download the customized alternative.
Partnerships are great for brand-halo if they confer trust where there is otherwise no established relationship. But even when there is no inherent brand value, trust can still be earned. When I moved to Berlin, there were a couple of websites experimenting with Mozilla’s “Save to Pocket” button. By the time I left Berlin, there were 16 major publishers which integrated our tools to recommend content to Firefox users. My tactics in promoting the tools was never incentivized with commercial relationship. Rather it was by open and transparent communication of the benefits of the product. It was not by my efficacy as a salesman that Pocket earned its reputation in Germany. I knew from my lessons in the culture that excessive sales approach wouldn’t have worked anyway. But through transparency and by proving tremendous reliability, over time, I and my team could win trust. Trust and transparency is the basis of everything in the internet. As I found in Japan and Germany, diligent effort on behalf of the user via their service providers can win the day for a middleware company, be it a search engine or a browser.
As a business developer, it has been very easy for me to talk about Mozilla’s software. The parties on the other side of the table could always take the software I was pitching and run with it using their own brand if they’d wanted to. It was nice to have a pitch that ended with a punch line of “succeed with us and help us enhance the product jointly, or do it yourself on our code and succeed without us.” There has never been a need for Mozilla to be defensive with its innovations because it was set up for generosity.
As many companies have benefited by forking Mozilla code as have sought partnerships directly. Beyond business interest that is tied into brands, budgets and marketing strategies, Mozilla does a far greater good beyond its own scope of interest. Open source developers and their sponsors are achieving a broader good that is beyond the interests of any of them individually. By giving open source and maintaining an active dialog in the open about its future, we are giving the inspiration to developers and web-creators across the world to make the next generation of web stronger and more adaptive to the needs of the market in a way that is beyond vested interests and shareholder benefit. We are collaboratively building a platform that is mutable and extensible, to be continued through the visions and inspirations of the community we inspire.
Passing the baton
It has been amazing to watch Netscape morph from my favorite browser when I started my journey with the internet 25 years ago to becoming a platform that inspires hundreds of millions of people today. And just as the internet is a system of discreet nodes that can stay resilient and independent from other nodes, so the open source ecosystem itself is now a plurality of collaborative (though competitive) entities who jointly defend the network against vulnerabilities never needing to rely solely on one entity. As it was envisioned for Netscape’s future two decades ago, so it is now across a broad pool of international developers who are focusing on the future of the utility and flexibility of the web.
Some might wonder, “Wouldn’t it be great if everyone just used the same software?” It might seem that that would address a lot of the site compatibility problems web developers run into. But think back to the concept of the competitive ecosystem the governments are so keen on. Competition is cumbersome and inefficient to a great extent. But the more people who are picking up the code and trying something new and innovative with it, the better ultimately the result for the broader consumer base.
Mozilla was spawned out of the desire to create exactly that open and competitive ecosystem that would sustain the open internet beyond the influence of any single player or contributor. (Beyond even themselves.) Now that there are several competing open source initiatives, we have less to worry about any single one of them. As the internet itself was designed as a series of independent nodes that could function with or without others in the network, so is it with the competitive ecosystem of software developers fostering what we now have of this amazing internet. Mozilla has seemed to be somewhat of a diaspora. It’s former contributors are now spread across almost all technology firms around the world.
Looking back over the decades of my career, it has been awe inspiring to see what lasts and what doesn’t. Some of the deals I’ve worked on have spanned a decade. But that’s somewhat rare in this industry. The best we can aspire to is to contribute some small part that makes the broader tools and market better for the furtherance of a competitive and open ecosystem that allows new entrants to contribute what they may to advance the work of the previous generation.
 |
| The Firefox Monument on Embaracadero |
2020 brings a global viral pandemic that has taken millions of lives. As governments shut down their local economies to stem the spread of the pandemic, all communities are being impacted in sundry ways. No part of our world is untouched by this. Mozilla, along with thousands of other businesses, is feeling the impact and has had to reduce its staff in order to ensure that it can persist into the future to stay true to the values we all support.
It is always compelling and rewarding to see your efforts reflected in the success of others. It’s my time now to pass on the baton with pride, knowing the race will go on. The wonderful thing about open source is that it can live on beyond just what one company or a team of individuals can contribute to it. I’ve seen time and time again how companies unrelated to Mozilla can pick up the code and run with it, saving their developers time and effort that would otherwise have to be spent building from scratch. AOL had cast 1000 seeds when they gave up Netscape to the community. It has spawned an industry of amazing competitive collaboration without needing to be dreamed up by legislation of governments.
There is a parable in Japan about the knife that gets sharper with use rather than dulling. Open source is the closest to that allegory that I’ve seen. It’s been fascinating to be a part of it! Open source is a tool that is honed by the earnest endeavor of thousands of people sharing their creativity toward a common goal. And because of its transparency, it cannot be maliciously encumbered without the community being able to see and react.
Thank you to the teams of Mozillians who’ve inspired me from the beginning!
No comments:
Post a Comment