LOGGING TOOLS SINCE 1995
Paul Bunyan, 1995 to today
Paul Bunyan first shipped in 1995 as a message logging utility for Windows software. Developers put it in their code, shipped it inside their release builds, and used it to find the component, file and line behind a problem on a machine they could not sit in front of. The WordPress plugin does the same job for the same reason.
FROM WINDOWS TO WORDPRESS
Timeline
| Year | What happened |
|---|---|
| 1995 | The first releases of Paul Bunyan ship between November 1995 and February 1996, published by Levon’s Wake, Inc. |
| 1998 | Version 2.0. |
| 1999 | The Y2K year. Companies everywhere are testing old software against a fixed deadline, and Paul Bunyan is in heavy demand. It supports C and C++, Visual Basic, Assembly, Java and Active Server Pages, at more than 25,000 messages a second, with a client and server design that collects messages from remote machines. |
| 2000 | The company becomes Diamond Sierra. Version 2.3 is released in May. |
| 2000 to 2001 | PB.NET is built for Windows internet applications. |
| Early 2000s | Our own work moves to web development on Unix and Linux. |
| 2005 to 2007 | The last large projects on the original product. |
| 2010 to 2011 | Paul Bunyan 3.0 adds 64-bit Windows and .NET support. It works, but the market for Windows server tools has moved to the web and the cloud. |
| 2012 to 2015 | We build raffle software on WordPress and WooCommerce, and Chance2Win, our raffle fundraising solution, starts in 2013. |
| 2026 | Paul Bunyan returns as a WordPress plugin. |
What the original did
The 1999 product page lists what every log message carried: severity, time, component, context, machine, process, module, file, line, process and thread id, and the message text. It could be shipped in release builds, and the logging code switched itself off if Paul Bunyan was not installed on the machine.
It spread the way developer tools do. One developer used it, the team adopted it, and it went along to the next job.
Why it stopped
Paul Bunyan was a Windows product, and from the early 2000s the work we were hired for was on Linux and the web. Rewriting a Windows server for a world moving to the cloud did not make sense, so we left it alone and built websites and web software for the next twenty years.
Why it is back
Those twenty years were spent on WordPress sites, including our own WooCommerce products. We kept running into the problem the original was built to solve: something is slow or broken, in production, and nobody can say where. The profiling plugin our team relied on for years stopped being maintained. So we built the tool we wanted, and gave it the name it had earned.
Three things carried over unchanged:
- File and line. A finding without a location is not finished.
- Safe to leave on. It runs in production, costs little and measures its own cost.
- Numbered codes. The original manual had an appendix of notifications and errors, each with a number, a meaning and a remedy. PB codes are the same idea.