Tag Archives: business

Project versus Product

With the fuss about the Log4Shell vulnerability finally dying down, it’s time to step back and take a good, long think about what happened and, more importantly, what can be done to stop it from happening again.

Sadly the prognosis is not good. The tl;dr is both simple and obvious: we simultaneously like free stuff and getting paid for our own work.

Most companies treat open source software exactly the same as commercial software but with a much lower purchase cost. When the software goes wrong, we want someone else to fix it for us. Unfortunately, sometimes we don’t even know where the software comes from. In the case of log4j, it’s run by volunteers. There is no 24/7 help desk with eager employees waiting to take your call.

But even if there is a company that backs the project, one that does have engineering, QA and support staff, is it reasonable to expect an immediate fix to a vulnerability?

Whether a company backs it or not, using open source software is more like being part of a community than being a customer. I came across this phrase about free software a few years ago: “If it breaks, then you get to keep both pieces.” It’s very apt here.

My small part in trying to fix this perception is by calling free software projects and commercially supported versions products or services.

The idea here is that the word “project” implies some degree of a work in progress, one that requires effort from all stakeholders.

In my Day Job1, I often see companies expecting to get commercial quality support for free because the software is free. By “commercial quality” I don’t mean “good.” The level of knowledge and support provided by most free projects is phenomenal. Instead, I mean that there are service-level agreements and guarantees of service within a particular time frame.

As it says in “Cloud Without Compromise”:

But there is something to the old adage that “You get what you pay for.” (… there’s a world of difference between building systems for pet projects versus designing for the needs of enterprise.)

Those service level agreements come with a cost. If you want a fix or an enhancement, you’re welcome to ask a project for it, but it might never come or, if it does, maybe not on a timescale that helps you. The rules change when you pay for the help.

My hope is that those companies that only ever take from open source projects and never contribute learned a lesson. By helping keep the project healthy, you don’t even need to be altruistic. Think of it as insurance.

If you use the software, there are many ways you can “pay it forward”: share enhancements and fixes, write documentation, share your knowledge and experience to bring in more users, or help other users with community support. But if there’s a mechanism to pay for it, the simplest way for most users is cold, hard cash.

  1. An open source database, so I have both skin in the game and bias. However, I think I’d be saying the same thing even if I worked for a vendor of closed source software. ↩︎

Radical Candor

Radical Candor” is one of those phrases that I’ve heard and wondered about. Is it another vacuous management phrase? Does it mean anything? I saw it in the library and thought I’d find out. I’m cynical about these things but it doesn’t mean I’m closed minded!

The pitch is “Be a kick-ass boss without losing your humanity” which sounds positive but I don’t manage people at work. Even if it contained genuine insight, would there be anything I could use?

The book starts with a description of what “Radical Candor1” is and finishes with how to apply the theory, an approach that I prefer to “How To Win Friends and Influence People” where the story is scattered throughout the text.

The examples vary in how useful or relatable they are. Some I was nodding with recognition. Others were some way out of my experience.

There’s an example early on where the author says “Um” too much in a meeting and her boss immediately offers a speech coach.

How many people get that experience?

I’ve never been offered a coach, not even when my failings have been much more significant than the occasional “Umm”! Have I been working for the wrong companies or have I been in the wrong jobs?

I guess the idea is that if someone who name-drops half of Silicon Valley can use “Radical Candor,” then so can you.

But much of the rest of the book did work for me. The idea of building trust and then providing rapid, honest feedback seems (self evidently?) like a good thing. I could imagine past conversations where I could apply the advice. I understood some cases where I’d done a good job; others where I’d missed.

I don’t think you need to be in a management position for this book to be useful. Anyone in a job where there’s an element of leadership might get something from it.

Do you need to go on a training course or read the full book to get the gist? Unlikely. But is there some value here? Absolutely.

  1. I’m going to use the American spelling as that’s the name of the book, but I can’t say I’m happy about it. ↩︎

Losing the Signal

I have a confession to make. I had a BlackBerry for a few months and I hated it. To be fair I was late to the party. By the time I used one, the iPhone had launched and and the BlackBerry was not the Cool Thing any more.

Nevertheless, a few years before that I remember seeing them all the time around the City and Canary Wharf. They had an impressive tactile quality, where were people continually touching them, scrolling the side-wheel or the spinning the little trackball on the later models. By the time I started using one, the hardware itself was still great but the software was incredibly dated.

Clearly there was something about the BlackBerry that was interesting. This book, “Losing the Signal,” is about the maker of the BlackBerry.

It’s a history going from the foundation of the company to roughly the resignation of the co-CEOs that had run the company for years. Since we all know how it ended, the simple chronological structure works well. The authors interviewed just about everyone on the record. They managed to get both the good and the bad out of those they talked to, making it neither a hagiography nor uncritical.

In the end, the story is one of hubris. Early on, it was a huge advantage to the company. Everyone else knew that mobile email was at best niche, at worst a waste of time. Everyone, of course, was wrong and RIM was right. But in 2007, when the iPhone launched, that hubris started to work against them.

Unlike rival handset makers, Lazaridis didn’t come to Barcelona armed with 4G prototypes, but with a physics lecture... Now he was going to explain to Verizon why they were wrong about 4G.

I’ve seen this behaviour before – from my own employer at times – the supplier telling the customer that they’re Doing It Wrong. They knew that the next generation of cellular technology wasn’t a big deal – the speed was unnecessary, the power consumption was a problem – knew that customers valued the security of the BlackBerry above the web browser of the iPhone or the App Store of Android. Only this time they were wrong.

I knew some of the story, having seen the devices and read articles, especially post-Android, post-iPhone, but it was good to read the whole history. The access the authors had to the key people is impressive and they made good use of it.

In the end, if you’re interested in the earliest successful smartphones, BlackBerry is the company to follow and this book is well worth reading.

Ops is undervalued

I made the mistake of suggesting that there was a blog to be made from this tweet. This is that post.

People still underestimate the value in (Developer|Operator) Experience when building platforms and honestly it’s kinda shocking to me.

If you want to win mindshare you need to make your tools actually usable. If you don’t want to lose it you need the same.

First: I agree with the sentiment. Maybe not to the same extent as Danielle, but I fight the same battles in my day job. I wanted to say this now because, on reading the rest, you may think the opposite. What follows is an explanation of why this is a common situation. I don’t mean it as a justification.

In summary, making software work for ops teams is not a focus either for software companies or internal development teams because of at least three reasons:

  • It’s not a business driver
  • Ops are not the buyer
  • Engineering is run by developers

Naturally there are exceptions to these rules. Every company is different. These are observations, not rules.

Working at the “coal face” it’s easy to forget, but people don’t buy software. They buy a solution to a business problem1. These days, that solution is often software but you don’t buy a new product because it’s cool2.

A driver might be to get a report generated more quickly, or to provide a new service to paying customers, or to reduce the costs of some infrastructure3.

But, you argue, the ops team are the people who keep the system up and running. How can this new system generate reports or deliver a service if it’s not running reliably or has not been provisioned correctly?

You’d be right. Sadly, organisations are often not structured to recognise that fact. The IT teams tasked with making everything run smoothly are frequently in a completely different reporting hierarchy from “the business.” I put “the business” in quotes as I hear it described that way all the time, but it’s this us-versus-them philosophy that brings many issues, including how ops get sidelined4.

With “the business” and “ops” being in separate reporting structures, one or the other has to sign off on the purchase of new software (unless it goes way up the organisation) and that’s always going to be “the business.”

The buyers normally consult the ops team, but ultimately they’re going to put their own needs first. Objections that the ops team have will end up in the business case, but likely in an appendix that no one will ever read.

This makes no sense because, as we all know, most of the expense of a system occurs after go-live. But monitoring, management and deployment are not things at the top of mind of developers and business users.

But even in the IT organisation, the ops team frequently don’t get the attention they deserve either. Anecdotally, this is because IT leadership come from the development team. Their outlook on IT is therefore skewed towards making things rather than keeping them running. I see the same challenges for testing teams. Or, indeed, the lack of testing teams.

This lack of buy-in from the ops team is endemic. I see it in companies buying and using software. I see it in companies that make and sell software5.

At this point, what I would like to be able to do is say, “And the solution to this terrible problem is…” Sadly there is no easy answer. Saying “You should listen to your ops team” is both obvious and unhelpful. Making tools useful for the ops team to get mindshare is a good way to get your software on a shortlist but maybe not enough to clinch that sale.

  1. I’m talking here about software used in a business of course, but the difference between this and personal use isn’t as great as you might initially imagine. You buy a game to solve the “problem” of boredom. Very few people buy software because it’s software. ↩︎
  2. You might buy it because this, specific solution is cooler than the other options. ↩︎
  3. That is, even in the case where it’s the infrastructure that is being improved, the business case is not “make the ops team more efficient” but “make the cost of operations lower.” ↩︎
  4. There’s another blog in how toxic “the business” as a concept is. This isn’t that blog. ↩︎
  5. This is a chicken and egg problem. Do software companies fall into this trap because they’re run by developers? Or is it because they’re selling to companies who have already fallen into the trap? ↩︎

App Store pricing

Like Spotify’s complaint before it, yesterday’s “App Store Principles and Practices” document from Apple got me thinking.

Apple talks a lot about free apps not paying anything (which isn’t entirely true of course), and it’s always pitched as a feature.

But the more I think about it, the more I think it might be a bug.

This effectively means that all paid apps have to subsidise all free apps. Is this what’s preventing Apple from reducing the 30% fee?

Why should free apps get a free ride? How much value is Facebook getting from Apple? My apps don’t take your personal data and use it for advertising purposes — something that Apple seems to be in favour of — yet I have to pay 30% and Facebook pay nothing.

Of course, we have to consider unintended consequences. It would be fair for Google and Facebook to pay, but what about a game I wrote in my spare time? Or that useful utility I wrote for myself that I’m altruistically sharing?

I don’t know is the short version. Should they charge for each download? Or each App Review? They’d probably need exceptions for certain categories, but also to be very careful that the system doesn’t get gamed.

The other thing Apple doesn’t directly address is Spotify’s most compelling argument: the fact that Apple charges 30% commission for apps that provide digital services, such as streaming music or books, means that no one other than Apple can actually allow in-app purchases in those categories. Apple only allow in-app purchases with the fee yet many of these services just don’t have 30% “spare” that they can give Apple. Apple Music and Apple Books don’t have to play by the App Store rules and they don’t have to pay the 30% fee.

If anything, this is harder than than the free freeloaders problem. It doesn’t seem right that Apple couldn’t compete in these categories, yet the platform owner clearly has a huge advantage here.

Anyway, at least two issues here and no firm conclusions. They always say “bring me solutions, not problems.” Sorry, I failed.


The gist of “ReWork” is that anyone can be an entrepreneur but you don’t have to follow the Silicon Valley tradition of seeking venture funding and providing foosball tables. If you do things right — different — you can make a sustainable business in a more traditional, bootstrapped way, and you don’t have to continually grow to be considered a success.

Many of the “lessons,” however, apply to almost any knowledge work. They subscribe to a less-is-more philosophy, and the book follows that example by being a quick read. Like the less-is-more outlook, that doesn’t make it bad, only very targeted.

If you’re looking for a complete framework for running your business, this isn’t it. (But then you’re probably not the kind of person who is likely to start a business I guess.) Instead, it’s a collection of related vignettes touching on varied aspects, from funding to focus to culture.

Much of the advice is so obvious that you wonder why more people don’t do it. But the fact that people don’t is exactly why their business (was 37signals, now Basecamp) has been a success and that writing about how it works doesn’t give away any “secret sauce.” It’s not that people don’t know the “secrets.” It’s more that people don’t have the discipline to stick to the programme.

Overall, there’s a lot of good material in here. If you own or work for a small company where you can potentially put the advice into practice, it’s probably worth a read.