Category Archives: Open Source

Whither Help Scout?

Three years ago, when I abandoned FogBugz after having used it for nearly 20 years, I landed on Help Scout, a fantastic support system offered by a company that seems to have a positive spirit and, cherry on top, is based locally to me in Boston.

There are few companies I’ve been as happy to spend money with. As a one-person support team, $22/month ($264 paid annually) gets me a reliable service that ticks all the boxes for my needs.

This simple pricing system was a breath of fresh air compared to many other services, which often require minimum user counts of five or more, have overly-complex user interfaces, or which seem unlikely to remain a going business concern.

Since I switched to Help Scout, I have been convinced that they are the best at what they do, and that I’d be in a real pickle if I were compelled to switch to anything else.

A Real Pickle

Over the past few weeks, many Help Scout customers have received notice that our plans will change to a new pricing model. Customers who haven’t received notice yet probably will soon. The new system is based on a rolling average of customer interactions. As they cleverly frame it: “the number of contacts you help each month.” Once notified, customers are granted six-months notice before the changes take effect.

The problem, for most Help Scout customers, is that the new system increases their monthly costs. A little for some, and a whole lot for others. The closest approximation to my current $22/month plan starts at $50/month and covers an average of 100 customer interactions per month. They’re obviously sensitive to the sticker shock this will produce, so they’re offering a two-year “Loyalty Discount” of about $20/month, reducing my monthly cost to $28.60/month. That’s still a 30% rise, but coming out to $6, it’s something I can live with.

For larger customers, the cost increase could be much worse. Imagine my company employed a three-person support team, handling customer interactions for 500 unique customers per month. Under current Help Scout pricing, I would pay $66/month. Exactly three times the amount I pay today. But under the new pricing structure, the minimum cost is $266/month.

How do you know which pricing tier you’ll fall into? Once you receive notice from Help Scout that your plan is changing, you’ll be able to see a graph of your recent customer interactions on a custom plan migration page within your account. For example, my graph shows that I fall comfortably into the 100 customers per month tier:

For new customers, they suggest for estimation purposes that the likely number of “customers helped” is around two-thirds the total number of emails you receive. So if you receive 150 emails per month, you might fall under the 100 contact tier, but if receive 200 emails per month, you most likely do not.

The Upside

The new pricing will benefit some customers. A brand new “Free” tier is a fantastic option for new customers who assist fewer than 50 customers per month on average. I fall into this range, so I wondered if this option might suit me. I contacted Help Scout and they agreed that I qualified for the plan, with the exception that I was using more than maximum 100 “tags” included in the free tier. I tag some Help Scout issues with GitHub ticket numbers, but if I were willing to delete some tags, I could switch immediately and start paying $22 less per month than I do now. That’s tempting, but the big problem with the free tier is that it removes access to the Help Scout API, and the ability to “Export” your data. Restricting data export is very 2005, and I wonder how it will play out in Europe.

It’s also possible to imagine customers with a large number of agents assisting a relatively small number of customers. For example, if my imaginary three-person support team handled only 100 unique customers per month, the monthly cost would go down with the new pricing, from $66/month to $50/month. Or $30/month if they provide the same loyalty discount, but I suspect for customers positively affected by the price change, there will be no such discount.

Finally, customers who lean heavily on Help Scout’s AI features might see savings. Currently, customers who want to use these features have to pay at least $44/month per user, twice the standard plan. I wouldn’t know and don’t care how much these savings might be, because although I am not opposed to AI in general, I don’t appreciate or employ it in the context of customer support.

What To Do?

For a customer in my particular position, whose monthly price will go up by $6, the easiest way forward is to do nothing. I’ll keep enjoying the same glorious product I have enjoyed for the past three years, at only a slightly elevated price. After another two years, we’ll see how things shake out. I contacted Help Scout about the “loyalty discount” and what happens when it expires, and they assured me that they would “do something” to keep people in my situation from seeing too much of a price hike. They claim to be aware of a problem there, but just aren’t sure how to manage it.

For customers who will see a more painful increase in cost, as with the $66 to $266 spike I contemplated above, I have to imagine they will consider other options. While I maintain that Help Scout is the best at what they do, there are, of course, alternatives. I haven’t made a thorough evaluation lately, but my pal Paul Kafasis shared a list of potential options put together by Rogue Amoeba’s Support Manager Chris Barajas. You might stumble upon something you like while perusing these:

That last option, FreeScout, is notable for being open source. Another option that came across my radar is a system called Zammad, which offers full-service hosting with the same refreshingly-simple “per user” pricing I once admired Help Scout for. And like FreeScout, Zammad is also open source. This means that either of these options can be self-hosted on your own server, akin to hosting your own WordPress installation.

I don’t relish the idea of maintaining my own help desk, but with the ever-looming threat of changes in functionality and pricing, for such a critical piece of infrastructure, I am considering it. With the wide-spread adoption of technologies like Docker, which bundle software into self-contained, easily-deployed packages, and services from companies such as Amazon, Microsoft, and Google, which make it easier to host such packages, it has never been easier to maintain a “self-hosted”, yet highly reliable web service.

Takeaway

While I respect Help Scout’s right and responsibility to manage the destiny of their own business, I think they are making a mistake with these changes.

It’s one thing to assert that they are upsetting their current user base. I think they are, but worse, I think they will turn off prospective users as well.

People don’t like fluctuating prices. Businesses especially don’t like fluctuating prices. With Help Scout’s old business model, it was very easy to understand what you were paying for, and what you would receive. The new system requires work simply to determine if pricing is viable, let alone practical. And once you’ve settled into a tier, you run the risk of being “punished” for helping more customers. The idea that I might one day consider whether to help a customer today, at the cost of sending myself into a higher pricing tier, or helping them tomorrow, and saving a bit of cash, makes me both frustrated and a little sick.

I suspect that very-large companies will find these changes the most palatable. Not only because at greater scale the pricing is more predictable, but because larger companies have far more expenses, many of which probably dwarf the cost of their Help Desk software. The smaller the company, the more likely Help Desk software is to be one of the main monthly expenses.

In a private chat, somebody suggested to me that small-time companies like mine are not Help Scout’s target market. That might well be true, but if it is, I think that is also folly. Most companies with 10, 100, or 1000 customer support agents started as companies with 1, 2, or 3 support agents. Help Scout’s new “Free” tier is a nod to the importance of luring in customers when they’re small and have little money to spare. They just seem to drop the ball a bit when it comes to taking care of customers at slightly-more-successful levels.

I am not sure what percentage of customers have been notified so far, but the number seems to be accelerating. I suspect the amount of negative feedback Help Scout receives will also accelerate. Hopefully this will inspire changes that make this transition more palatable for everybody.

Spelunking Apple’s Open Source

Since the earliest days of Mac OS X, Apple has complied with the licenses for the dozens of open source components it includes in the OS by posting (sometimes a little belatedly) updated versions of the source code to its Open Source at Apple web page.

This resource is useful primarily to developers, but may also interest curious technophiles who want to take a peek “behind the curtain” to see how much of the magic just beneath our fingertips is made.

If you visit the page today, you’ll see a new emphasis on Apple’s high-level projects, such as Swift and WebKit. At first glance you might wonder if the extensive list of all the open source projects has been removed from the site.

There’s no need to worry: the whole list, indexed by the pertinent platform and OS release to which they belong, is still available on a separate Releases page. Even better, each of these releases now has a corresponding GitHub repository, hosted in a dedicated organization reserved exclusively for open source distributions.

As great as the old list of distributions by release is, it can be tedious to pinpoint exactly where a particular component’s source code might live. Sometimes it’s easy: for example, the source code for the version of the Vim editor that shipped with macOS 13 is conveniently located in a distribution called vim-136. But other tools can be harder to find. If you were curious about the “banner” command, which was historically used to generate ASCII text suitable for printing huge messages at dot matrix printers (!), and which is remarkably still available as a built-in command on every Mac, you’d have to know to go looking for it in the text_cmds-138 release.

Apple’s decision to host these releases on GitHub, under a distinct organization, solves the problem. If you want to find the source code to an arcane tool like “banner”, just type it into a GitHub search of the organization. If there are too many false hits, as is the case for a common word like banner, try searching on something unique like a term from the command’s man page. The banner tool is credited as being authored by Mark Horton, and a search for “org:apple-oss-distributions Mark Horton” brings up more hits than I would have guessed (he also contributed to vim and vi, coincidentally), but a reference to the banner man page is the second search result.

I was inspired to write this blog post by a situation that came up in a programming Slack, where one person asked for “an API that could list the open ports and their owning processes.” Another replied that the command-line tool “lsof” is up to the task, only the person wasn’t looking for a command-line tool. Using the knowledge of Apple’s open source distributions, you could go look for, and find, the pertinent source code, and determine which API it was using.

When questions like these come up, many times the answer comes from a wise old sage who happens to know exactly what you’re looking for. Other times, Apple’s increasingly well-indexed open source distributions might be just the ticket.

Dump FogBugz

Once upon a time, there was a fabulous service called FogBugz. Well, technically it still exists, but over the past many years, since it was sold off by Fog Creek Software, it has both stagnated and diminished in reliability as a substantial number of us long-time users has grudgingly continued to use it.

Several months ago, the whiff of abandonment became too great for me to bear any longer, so I devised a plan to migrate my data out of FogBugz, and into more reliably maintained services. FogBugz effectively served as both a customer-service database, and a bug-tracking system. Most apps don’t strive to achieve this, so I had to plan for two new services to fill the shoes of this app. I settled on HelpScout for customer service, and GitHub Issues for bug-tracking. HelpScout has turned out to be more of a solid home run than GitHub issues, but I’m happy with both.

Whether you’re also looking to transition away from FogBugz, or just want a reliable means of backing up your data, you’ll need to use the FogBugz API to get your data out. Once you have a structured backup of all your case data and attachments, you’ll be in a good position to evaluate how you might migrate that data into a format that is suitable for importing to another service.

I’ve shared a pair of simple Python scripts on GitHub that will help you to automate dumping your FogBugz data. Simply download my dumpbugz files from GitHub, follow the directions in the README, and you should be left with a “Cases” folder that includes all of your data and attachments.

For my transition to HelpScout and GitHub Issues, I wrote additional scripts to interface with the APIs of those services. Those are not ready for sharing at this point, but I may share them in the future. In any case, I hope the scripts make it easier for you to “Dump FogBugz” sooner than later.

Unloved Patches

For a long time I have admired the WordPress project, for developing such a robust blogging platform that is ultimately open, and free, and anybody can contribute improvements to it. I encourage many of my customers to use WordPress with MarsEdit, because it seems like a “safe bet” going forward.

My admiration has diminished a bit in the past 7 months because … I haven’t succeeded in contributing to it.

For a long time, I heard reports from my customers that dates were being set wrong in posts to WordPress. The issue in summary is that if you have a draft post on WordPress, changing its status to “Published” doesn’t update the publish date from the time the draft was originally saved.

I didn’t really get a handle on this problem until it started affecting me. Sometimes I write the show notes for my podcast, Core Intuition, ahead of the time the podcast actually goes public. In these situations, the blog post has a published date corresponding to the time I first starting writing the post, and when we finally go to publish the podcast, the date remains the same.

I did the hard work of not only diagnosing the problem in WordPress’s source code, but also writing a fix, and writing unit tests to confirm the fix. I filed a bug with a patch that will fix the problem for my customers, and any other clients of the WordPress API:

#45322: Editing a draft post with wp.editPost causes its published date to be set

Shortly after filing the bug, I went to the WordPress Slack to see what I could do about having my fixes integrated. I was lucky to have a positive response from a couple members of the WordPress team, and my bug fix seemed slated for integration.

Time passed. I wondered. I didn’t want to nag the hard-working members of the team, but I also didn’t want my hard work to have been for naught. Also, my customers, as well as other clients of the WordPress API, would benefit from this.

It’s been on my TODO list for 7 months now to “check in” with the WordPress team about this. Unfortunately, every time I do, the only thing I’ve noticed is that nobody substantially responds to my inquiries. I’m in the dead zone.

I don’t think the WordPress team is bad, by any means, but I think this reflects a problem in their process. When somebody comes to your project with a well-thought-out, unit-tested fix, and is met by radio silence? The chances are high that they will never come back again. I have submitted WordPress patches in the past, but after this experience I don’t know if I will bother submitting them again. That’s a big change in my perspective on how the WordPress team works, and on how it should work.

This post is about WordPress, but I think there are lessons for every open source project. Obviously, you can’t coddle every contributor. Some submissions will be bogus, some will be contrary to the aims of the project. But mine was a clear fix to a defect that affects multiple clients of the API. If it’s not a clear fix, I’m at least owed an explanation for why it hasn’t been committed after 7 months. In. My. Humble. Opinion.

Saying Goodbye to NetNewsWire 3

In case you haven’t heard the news, Brent Simmons recently regained the rights to NetNewsWire, the groundbreaking Mac news reader, which also happens to be the progenitor of MarsEdit.

I have been a fan of NetNewsWire since before Brent sold it to NewsGator. Since before NewsGator sold MarsEdit to me. Before they sold NetNewsWire to Black Pixel. For a long time.

After Black Pixel took the reins, they put a lot of effort into a massive overhaul of the app, modernizing the look and feel and adding a robust, in-house syncing mechanism. When they released NetNewsWire 4 in 2015, it seemed as though the future for the app was bright.

As nice as NetNewsWire 4 was, it also differed a lot from NetNewsWire 3. They pared back the feature set a lot, in ways that made switching inconvenient to me. So I soldiered on with 3.3.2, thinking that I would update to 4.x eventually.

I never did. For whatever reason, work on NetNewsWire seemed to stall, and I never found the updated version of the app to fit my needs. NetNewsWire 3 worked just fine.

The meaning of “just fine” started to shift as macOS changed underneath the app. Subtle bugs emerged, the app’s lower-resolution graphics started to look fuzzy, and the networking infrastructure of the app is from an older era that is failing to connect to some SSL servers. In short, it’s no longer the great app that it once was. One particular bug with the size of the “Clippings” folder icon has been bugging me for years:

Screenshot of NetNewsWire showing blurry icons and a missized Clippings folder icon.

Over the years I considered other news readers such as Reeder (which is free for a limited time, by the way), but none of them scratched that NetNewsWire 3 itch. I rely upon some arcane features of the app including “scripted feeds,” which allow me for example to run Python scripts on my Mac that connect to Twitter and generate RSS feeds from search results. That’s not possible in most feed readers.

I used to fantasize about getting access to the NetNewsWire 3 source code and sprucing it up. I wondered how things might have turned out differently if, in addition to acquiring MarsEdit from NewsGator, I had acquired both? I can’t say I would have done a better job than Black Pixel, but I would have preserved the features I care about, and that Clippings folder icon would be the right size!

Because Brent and I are still close friends, we have been in conversation about NetNewsWire and the various options for moving it forward into the future. I’ve also been contributing to the NetNewsWire open source project, which is based on an entirely new code base unrelated to NetNewsWire 3.

Since I’m not the only stalwart NetNewsWire 3 user, one of the things Brent was curious about was whether he could give that version “one last hurrah,” so to speak. Fix a few of the most glaring bugs, build against a modern SDK, and not only create an artifact for history to more accurately judge the app’s virtues, but to give long-standing users something to tide them over while development continues on NetNewsWire 5.

I was honored when Brent handed me the keys to the castle, so to speak, by sending me a copy of NetNewsWire 3’s source code. To heavily paraphrase what he said, it was basically “let me know if it’s worth saving.”

I got the app building with Xcode 10 on macOS Mojave beta 9. There were some major glitches. The sidebar was pure black, fonts were rendering wrong. Probably whole subsets of functionality were not working, or working unreliably. I sent the source base back to him with a report that it builds and runs, but would probably take some work to get into shippable shape.

Brent made the pragmatic choice not to release an updated NetNewsWire 3. Putting the bugs aside, he recognized that any time invested in that old version is an investment in older technology that does not have a viable future. It’s a distraction from the New World NetNewsWire.

To be honest, the decision doesn’t sting at all. I’ve switched most of my news reading to development releases of NetNewsWire 5, and only use NetNewsWire 3 for a handful of those geeky script-based RSS feeds I am still relying on.

I was grateful to have the opportunity after all these years to take a peek at the source code to the app, and to get a feel for what it would take to salvage what’s left. I couldn’t resist fixing at least one bug before I passed it along though:

Screenshot of the NetNewsWire window with Clippings folder icon restored to normal size

If you’re curious: the Clippings icon is obtained from the Mac operating system. At one point in history it must have come from the system at just the perfect size to fit the source list in the app, but as Apple modernized and adapted to higher resolution Macs, they must have updated the icon to support drawing at much larger sizes. NetNewsWire 3.3.2 doesn’t manually set the size to the expected 16x16pt size, but 3.3.3j (for Jalkut!) does.

Goodbye, NetNewsWire 3. You were a great app, but your time has passed. Long live NetNewsWire 5.

The Price Of GPL

Matt Mullenweg, the founder of Automattic, downloaded his competitor Wix’s iOS app. It looked eerily familiar, and he confirmed it contains source code stolen from WordPress. He called them out on his blog, getting right to the point in addressing the problem:

Your app’s editor is built with stolen code, so your whole app is now in violation of the license.

Wix’s CEO, Avishai Abrahami, responded with a round of non-sequiturs that carefully evade the point that his product is built from source code for which they have not paid. One of his engineers equally misses the point, focusing on the circumstances surrounding the violation, rather than taking responsibility for the theft.

Some will take issue with the use of strong words like “stolen code,” and “theft,” with respect to a GPL violation. But that’s exactly what it is: software has been taken and deployed in Wix’s product, but the price for doing so has not been paid.

Many developers (and CEOs) seem to prefer remaining willfully oblivious to the consequences of using GPL code. They loosely interpret the terms of GPL to suit their own wishes for what they implied:

  • “It’s OK for us to use GPL code anywhere, as long as we contribute back changes.”
  • “It’s only a small amount of GPL code, so the license doesn’t apply.”
  • “We contributed to this GPL code, so we have special rights to use it.”
  • “We give back to the community in other ways, so it balances out.”

All false, yet all common interpretations of GPL, and echoes of the poor arguments presented by Wix’s CEO and engineer.

The price of GPL is fairly obvious and easy to understand, even if there is some bickering about what constitutes “linked code.” You don’t have to be a legal expert to get the gist of it: if you want to link your software with GPL code, you must also make your software’s source code available. Specifically, you must make your software’s source code available to customers who install your software, under a GPL-compatible license. You have to give your code away. That’s the price of GPL.

Many developers understand, and view the price of GPL as perfectly justified, while others (myself included) find it unacceptable. So what am I supposed to do? Not use any GPL source code at all in any of my proprietary products? Exactly. Because the price of GPL is too much for me, and I don’t steal source code.