Pulling the Plug on Peakware.com

The idea for Peakware was spawned in 1994 on the summit of Mount Elbert, the highest mountain in Colorado and the second highest in the lower 48 states. This was was my first fourteener (mountains higher than 14,000 feet), and I was hooked. I loved the physical challenge of hiking more than 10 miles and climbing nearly 4,500 vertical feet in increasingly thin air. And the view from the summit was truly awesome. The entire Western United States seemed to be spread out before and below me in all directions.

I stood on the summit, taking in the views and wondering which mountains I would climb next. On this particular trip, I knew that I’d be climbing Mount Massive (Colorado’s second highest) tomorrow, and La Plata Peak (fifth highest) the day after that. But then what? How much higher could I climb with the skills I had? And what were my best options for climbing in say, Mexico? And where could I climb in Winter when most of North America’s high peaks were snowed in and no longer accessible?

In Summer 1994, these were difficult questions to answer. Hundreds of guidebooks had been published covering mountain ranges all over the world, but there was no single reference tool that consolidated all their information and made it easy to search. I had the need for a tool like this, and then and there, on the summit of Mount Elbert, I decided to create this tool.

I returned to my home in Lawrence, Kansas and immediately created a database to house the information I planned to collect. Not long after, I returned to Colorado and spent two weeks in Golden at the American Alpine Club Library, collecting and entering data about the world’s highest peaks. I arrived when they opened each morning, and stayed until they closed each evening. Each evening, I would grab my daypack and go for an evening hike in the surrounding mountains. After collecting the core data, I mailed letters to national parks and tourism bureaus all over the world seeking royalty-free mountain photos, and my requests were met with an overwhelming response. In early 1997, Peakware World Mountain CD was released. It included profiles of the world’s most famous mountains, with maps and photos, and most importantly – a search interface that enabled users to search for peaks that met their climbing or hiking preferences. I ran ads in Backpacker and Summit magazines. And I sold a few copies.

But I had a bigger vision. Spending two weeks in the AAC Library did not make me an expert. The experts were the people around the world who lived near these mountains, or the people who had already climbed them. I needed to tap into that collective community expertise. These were the early days of the World Wide Web, and I had already been building HTML web pages and contributing to conversations that were happening within the World Wide Consortium related to web accessibility. I knew what I had to do. I needed to publish Peakware to the Web, make it freely available to everyone, and invite users to contribute their knowledge and experience.

Peakware.com launched in June 1998. Its primary function, just like on the CD, was search. And this was three months before Larry Page and Sergey Brin launched Google on Stanford University’s web servers (google.stanford.edu). Another key feature of Peakware was the ability for users to contribute content: They could add new peaks, edit data for existing peaks, submit trip reports, and upload photographs. And this was 2.5 years before Wikipedia. I earned revenue through commissions on the sale of guidebooks, initially as an affiliate of Adventurous Traveler Bookstore, and later as an affiliate of a new online bookstore called Amazon.com. I also earned revenue by selling ad space directly to outdoor recreation companies, but this required too much time for too little return. By then Google had moved beyond search into other areas, including advertising, so I signed on early to using Google Ads for most — and eventually all — of Peakware’s advertising.

Once word got out, the community of active users grew rapidly, and by 1999 there were hundreds of users, and new content was being added daily. I spent hours each day reviewing user-submitted content, fixing bugs, adding new features, and communicating by email with users. There were dedicated users throughout North America, Canada, Australia, New Zealand, and the UK, plus other users from around the world. I had particularly memorable exchanges with many users in Europe, a member of the Maasai people in Kenya about mountains in his region, and a scientist stationed in Antarctica about the high peaks there. I loved being part of this global community of people who shared a love for mountains.

But I also had a full time job, was attending graduate school at the University of Kansas, and was a new first-time father. I was so sleep deprived I could take a 5-minute power nap and have vivid dreams before my alarm dragged me back to the waking world. In December 1999, overcommitted and utterly exhausted, I exchanged emails with Marshall Hall, President of Interactive Outdoors Inc. They were a small company of avid outdoor enthusiasts in Aspen, Colorado, who — like me — had been collecting big data about outdoor recreation for their flagship website, Wildernet.com. They were impressed by the dedication of the Peakware user community, and were interested in acquiring my website. The timing was perfect, we negotiated a deal, and I bid farewell to the site I had created.

For the next 20 years, Interactive Outdoors continued to own and control Peakware.com. We stayed in touch, and they hired me as an independent contractor to do most of the design and development work. Peakware continued to be a leading online resource for information about the world’s mountains. Over the years, 10,000 users contributed content, including over 4,000 peaks, 8,000 photos, and 16,000 trip reports. Peakware became such a reputable source for mountain data that a “Peakware ID” field was added to mountain records in Wikidata, the data engine that drives Wikipedia.

But Peakware wasn’t alone. Another site, Peakbagger.com, had been around about as long as Peakware had, and in fact shared a similar history to Peakware’s. Both of these sites faced stiff competition from SummitPost throughout the 2000s, then from Peakery in the 2010s. Climbers were also turning to local and regional sites such as the ones I’m most familiar with in the Pacific Northwest: Cascade Climbers, The Mountaineers, and Washington Trails Association. And more recently, users have turned to dedicated mountaineering and climbing groups on Facebook and other social networking platforms.

Maintaining a popular website and keeping it relevant amid such competition is no small task. Traffic gradually decreased over the years, and advertising revenue decreased in proportion. In January 2019, Interactive Outdoors dissolved and Marshall returned Peakware to me. I kept it afloat for over a year, fixing bugs and adding features. Most notably, I did a massive data sync with Wikidata, bringing Peakware’s database to 16,893 peaks, which I believe to be nearly every mountain in the world.

However, the bulk of my time in later years was consumed in seemingly endless battles with spammers. And with Google.

One guy vs The Spammers

To create an account on Peakware, users needed to have valid email addresses. There was a day when that was all the security we needed on the Web, or maybe I was just being naive. In any case, Peakware became a target. Thousands of users began creating bogus accounts with profiles that included sexy photos and ad-filled bios. The frequency of new accounts made clear that these were bots, not humans, although they apparently were using valid email addresses.

I removed the “New members” feature so spammers were just wasting their time, creating profiles that nobody would ever see. That was an unfortunate loss though, as it had been a nice way to welcome newcomers and create a sense of community. I also began requiring manual approval of users’ first three content submissions. Once users had met that threshold, their submissions were automatically approved, although I kept a close watch on all new content. If spammers were smart, they would figure out that they needed to contribute a small quantity of actual mountain-related content, then they would have a green light to add new spam peaks, submit spam trip reports, and upload spam photos.

Fortunately none of them were smart enough, or perhaps they simply didn’t want to work that hard. Although they weren’t doing any major harm, I didn’t want them around at all, and I had to remain constantly vigilant of their behaviors.

In further efforts to keep them out, I added a honeypot to the signup form. A honeypot is a visibly hidden field that bots don’t realize is hidden; so if they submit the form with data in the fake field they’re assumed to be a bot and their submission is rejected. This worked for a while, but soon the spammers had figured that out and were blitzing the site again.

I added Google ReCaptcha v2 (the CAPTCHA that offers — for most users — a single checkbox with the label “I’m not a robot”). See my blog post reCAPTCHA Accessibility reVISTED for an accessibility review. This too worked for a while to keep spammers out, but eventually they cracked that too, and even thumbed their noses at me by submitting forms with user names like “ReCAPTCHA Sucks”.

I scrutinized the accounts they were creating, and noticed some consistent patterns. I developed my own spam catcher algorithm to check new account submissions for these patterns. Each pattern was weighted based on correlations between the data submitted by new users and that submitted by known spammer accounts. The sum of the weighted score, i.e., the “spammer score”, was used to block users from creating accounts if it reached a certain threshold. The patterns I observed in my spammers included:

1. Many spammers had emails ending in .pl, .ru, and .eu. I hated to flag all new accounts from these countries/regions, but the data required me to profile users in this way.
2. Their user names tended to be comprised of a random string of three or more letters, followed by a random string of two or more numbers (e.g., “uwpyg88”, “pmxb7247”).
3. Many spammers selected “United States” as their home country, despite having a non-U.S. email address.
4. If spammers selected “United States” as their home country, they were prompted for city and state, and these often were major American cities, but with incorrectly matched states (e.g., “Chicago, Florida”; “New Orleans, California”).

These consistent patterns made me wonder if I was dealing with a single spammer, or multiple spammers who were all using the same crappy spammer software that wasn’t smart enough to select the correct U.S. state based on the U.S. city it had already randomly selected. If this was a single spammer, I wondered how they could have so many valid email accounts at their disposal.

My spam catcher algorithm was successful for a while, but eventually spammers began to slip through by using email addresses at .info or .biz domains, as well as Gmail accounts, thereby lowering their “spammer score”.

Several weeks ago I upgraded Google ReCaptcha from v2 to v3, and all spam stopped. ReCaptcha v3 works mysteriously, behind the scenes, to determine whether you’re a spammer. You don’t have to solve any cryptic, inaccessible puzzles, or even check a box declaring that you’re a human. It simply watches you, and if you’re a spammer, it knows. Perhaps this is partly made possible because Google knows everyone, including you. It knows who you are, and everything about you. It knows if you’ve been naughty or nice. And if you’ve been naughty, it tells me this, and I block you from creating a Peakware account. This has been 100% successful at blocking spam, but there’s some concern that it might be blocking legitimate users as well. If Google thinks you’ve been naughty, but you’ve actually been nice, you have no opportunity to defend yourself. Google has the power.

That brings me to my next ongoing battle.

One guy vs Google

I’ve already mentioned Google several times in this story. Peakware and Google both launched in 1998. Peakware was Google’s older sibling by three months, and we grew up together. Google started with search, but it ventured into many other areas, and created really cool tools, services and applications that web designers and developers like me could use for free on our own websites.

I’ve already mentioned Google Ads – that ultimately became Peakware’s sole source of revenue.

I’ve also mentioned Google ReCaptcha, an essential tool in my battle against spammers, and ultimately, with the deployment of ReCatpcha v3, the nuclear weapon that obliterated all of Peakware’s spammer activity.

I also used lots of Google’s other tools.

Google Maps

Google Maps was a central part of the Peakware experience . The home page featured a Google relief map, zoomed out to include all of Earth, with icons marking the location of each of the seven summits (the highest points on each of the seven continents). Users could zoom in and pan left or right, and as they did so, new icons would appear, marking the highest peaks of the region shown. The more they zoomed, the more markers would appear. They could click on any marker to jump to the page dedicated to that peak. On each peak page, they were presented in with a Google relief map zoomed in and centered on that mountain. This was a fantastic way to explore the world’s mountains!

Google Earth

From any Google Map within Peakware, users could download a KML file that contained the raw data for all the peaks in that particular mountain range or sub-range, or a continent, or the entire planet, in order to explore Peakware’s mountain data using Google Earth. With Peakware’s entire data set loaded into Google Earth, users could identify nearly all of the world’s mountains and get extensive data about each peak.

YouTube

Most mountaineering videos on YouTube are homemade, and the quality varies widely. On your own, you can waste a lot of time browsing through the videos trying to find the two or three that are truly helpful and informative. On Peakware, I used Google’s YouTube Data API to search for and display videos related to particular peaks, and I created an interface whereby Peakware users could up-vote or down-vote videos based on quality and relevance. Then on subsequent visits, the most frequently up-voted videos would rise to the top and the down-voted videos would not be shown. This proved to be a great way to crowdsource the task of searching for the best videos about particular peaks.

I created this about the same I was creating YouTube Caption Auditor (YTCA), a free open source tool that can be used for collecting data about each video within any given YouTube channel (e.g., number of views, publication date, and whether or not the video has captions). The data can be sorted and filtered, which can be very useful for channel owners to prioritize their captioning efforts. That’s unrelated to Peakware but it plays an important role in my ultimate decision to pull the plug on Peakware. More on that later.

Google Analytics

I relied extensively on Google Analytics. I kept it handy in a tab in my web browser (Google Chrome) so I could check in frequently to monitor user behavior. Peakware was active 24/7 and had been for many years. It was fun to check in at various times of day or night to see where users were coming from, and what pages they were looking at. Statistically, most users were from English-speaking countries, but there were significant numbers of users from other countries, most notably China, Japan, Germany, Italy, Poland, Spain, Romania, France, Netherlands, and Switzerland.

Google Translate

The knowledge gained from Google Analytics about users’ countries led me to consider localizing Peakware into non-English languages. I could hire a translation service to translate all the menus, prompts, and other built-in text, but all users worldwide could contribute content in their own languages. I was imagining this being like mountains in the real world. When hiking or climbing in the mountains, it’s common to hear a wide variety of languages spoken among the people around you, which is a beautiful thing. On Peakware International, users would be able to contribute content in their own language, and other users could translate that content on the fly as needed. This could easily be done with the Google Translate API.

Google’s New Cost Model

Peakware may never have happened without Google. Maps in particular was a key feature that enabled users to visualize the mountains they were interested in, and freely explore. And best of all, Google offered all of the above tools for free. I should have been leery of “free”. Thousands of site owners like myself had built sites using Google’s free APIs, then, once we were fully dependent on Google, they starting charging us to use their once-free services.

Currently, Google Maps JavaScript API costs $7.00 USD per 1000 map loads. Assuming Peakware gets 10,000 page views per day, and nearly all pages have one map, that’s $70 per day. Google Ads has never generated enough revenue to support that cost.

Also, given my Peakware International vision, I would need to use the Google Translate API to translate any user-submitted content that isn’t in the user’s preferred language. That currently costs $20 per million characters, which quickly adds up. The descriptions of peaks on Peakware’s pages contain an average of 586 characters, and the user-submitted trip reports are slightly less than that. Assuming 10,000 page views per day, with roughly 500 characters per page that might require translation (5 million characters per day), that has the potential to cost $100 per day. Granted, not all users would need to translate all pages, but this could still be an expensive service.

Also, in 2019, Google began enforcing quotas of 10,000 queries per day on their YouTube Data API v3. On Peakware, 10,000 queries was a fraction of what was needed to provide a list of videos for each peak, with a description and other data about each video. So each day – often early in the morning – Peakware’s video pages would simply stop working, which forced me to disable this very cool feature.

Google provides a form by which site owners can request a quota increase, but they aren’t forthcoming about the monetary price of additional quota. This brings me to YTCA, the free, open source tool I mentioned earlier, which I had created to help YouTube channel owners with their video captioning workflows. I was using this at this at the University of Washington to generate quarterly summary reports to track the captioning efforts of all our UW channels.

When the 10,000 queries per day quota was implemented, I was no longer able to generate my summary report. So I submitted the form to request an increase in quota, and what happened next was outrageous.

In my request, I had explained in painstaking detail how I was using the YouTube Data API to generate the captioning summary reports. I even listed the specific queries that were being submitted to the API. Weeks passed with no reply, then when they finally replied they asked me to produce a video demonstrating YTCA in action. This seemed unreasonable, but I did it anyway and shared the video with them, then waiting more weeks for a reply. This time when they replied, they pulled a Trump and presented me with a quid pro quo. They said “We’ll consider your quota increase request, but do us a favor first.”

The favor they wanted concerned the footer in the UW web theme: It was using the wrong YouTube logo. “If you can get that fixed,” they said, “we’ll consider your request.”

I replied and explained that I have no control over the UW web theme; I’m not even in that department. Further, their request had absolutely nothing to do with YTCA, the application for which I was seeking a quota increase.

The next time they replied, they didn’t even acknowledge my explanation. They simply asked “Have you done what we asked yet?” So, resigned to the reality that Google had the power in this relationship and there was no way I could get what I needed unless I met their demands, I contacted University Marketing and Communications, explained my situation, and persuaded them to fix the YouTube logo in the footer. After they had done this, I notified Google that the deed was done. More time passed, and they finally replied with a very modest quota increase, not the amount I had requested, and still nowhere near enough to complete a single YTCA summary report.

So, when faced with the prospect of contacting Google to request a quota increase for Peakware, I simply couldn’t bring myself to do it.

Gone climbing.

On Memorial Day weekend 2020, I decided to unplug. I launched this project because I love the mountains and I enjoy creating things. Maintaining Peakware had become less about those things, and was no longer enjoyable.

I had been working on this project for 26 years, and it was time to do something else. From now on, more of my weekends, especially holiday weekends, will be spent in the mountains.

Sadly, nothing lasts forever.

I’m keeping the peakware.com domain for a while. All URLs now resolve to the home page, which simply says “Gone climbing.”