Tag Archives: business

Does it matter if you anger practitioners and enthusiasts?

Posted on by
Reply

I put this topic on my kanban board in August of 2023. At the time, Hashicorp had just angered a lot of people by switching their popular tools to the Business Source License (BuSL). This was not long after Red Hat angered a lot of people by changing how they made source code for Red Hat Enterprise Linux (RHEL) public. While the anger was numerous and voluminous, my suspicion was that it didn’t matter.

The people who buy enterprise software are, by and large, not the enthusiasts who care about the practical or philosophical importance of open source software. You can anger the nerds (I use that term with endearment, as I am one, too) all you want, because they’re not the ones who sign the checks. This is a cynical take, but Hashicorp’s subsequent (pending) acquisition by IBM would seem to reinforce it. Much of the analysis I read at the time suggested that switching to the BuSL was part of Hashicorp trying to be more appealing to potential buyers and perhaps the reason that IBM made the acquisition offer. I’m not convinced of the latter, since IBM was willing to pay a lot more for Red Hat, who open sourced everything*.

It doesn’t seem to matter

Shortly after the Hashicorp acquisition was announced, SJVN wrote an article in which he noted that IBM’s share price had fallen 8% on the news. This, combined with the fact that Hashicorp stock fell 22% between the announcement of the BuSL switch and the acquisition news, led him to wonder if the acquisition was a “blunder” on IBM’s part. But as of Friday’s close, just over four months since the news was announced, IBM shares are up almost 10% from the pre-announcement price and have reached a one-year high. If the price isn’t quite at an all-time high, it’s within spitting distance of the 2013 peak.

But now we have actual analysis. RedMonk analyst Rachel Stephens published an article last week examining the effect of license changes on Hashicorp, MongoDB, Elastic, and Confluent. You should read the whole article, but the quick summary is that the license changes appear to have no impact on revenue. The changes in valuation and net income are a little messier, but the conclusion holds: “here does not seem to be a clear link between moving from an open source to proprietary license and increasing the company’s value.”

Importantly, though, the analysis does not show a clear link between moving to a proprietary license and decreasing the company’s value. It’s a small sample size, but the best we can tell, changing the license doesn’t matter either way. If your primary business is enterprises, not SMBs or individuals, there’s little evidence that a change that angers practitioners matters, at least in the short term.

What about Elasticsearch?

Elastic dropped a surprise on Thursday. They announced that Elasticsearch is once again open source, this time under the AGPL. Elastic announced a change from the Apache Software License in January 2021, driven in part by issues with Amazon Web Services. Does this mean they finally caved to pressure from the people who were upset about the initial change?

I don’t think so. On the same day Elastic announced the shift to the AGPL, they also released their quarterly earnings. Although the earnings and revenue beat expectations, the company cut their guidance from the coming quarter. The market was displeased, and about a quarter of Elastic’s market value went poof in a single day.

I’m not a market analyst and I don’t have any inside knowledge, so the best I can do is speculate based on what I know about the software industry. But my take is that this license change is less about responding to the pressure from open source fans and more about reducing ambiguity for potential adoptees. The Server Side Public License has some vague terms that could scare away someone trying the free offering, and a better-known license can remove that friction. Is this a win? Maybe, but not a philosophically-driven one.

Elastic’s re-re-license announcement mentions working issues out with AWS. The fact that they switched to the AGPL seems like a defensive move against future perceived shenanigans. If this is the primary motivator, then it seems like the move away from open source was successful and justifies the first license change.

So what do we do?

Anger from practitioners doesn’t seem like a meaningful consequence, so how do we prevent the sort of license changes that have caused such a stir in the last few years? If I had an easy answer, I’d get paid a lot of money as a consultant. (Spoiler: I do not get paid a lot of money as a consultant.)

But it’s clear when making the case for open source at our employers that we should not rely on philosophical arguments (because those only work when money is cheap and times are good). Nor should we rely on a “this will kill us with enthusiasts” because it turns out that might not matter.

The case for open source has to be presented in terms that matter to the business. This doesn’t have to be revenue or profit, which is good since the links are not always direct. But it does need to connect in clear, direct ways to the business’s goals, strategy, or other decision influences.

In defense(ish) of subscriptions

Posted on by
2

It seems like everything is a subscription these days. We’ve replaced our towers of DVDs and CDs with subscriptions to Netflix and Spotify. The books that used to be piled on our shelves are now bits on a Kindle. In some respects, this is super convenient. Want to bring several books on vacation? It takes almost no space in your bag. Want to switch what music you’re listening to while you drive? Talk to your phone instead of flipping through a huge binder of CDs. Convenient and safe!

Of course, there’s a downside, too. When you have a subscription, you don’t truly own what you’re paying for. Amazon might decide to remove a book from your Kindle. Studios frequently pull their content off of Netflix to put them on their own services. If you stop paying Adobe, you can’t keep using Photoshop.

Some people are pushing back. Jose Gilgado’s “The beauty of finished software” is a great example of the thought. ONCE from 37Signals is a practical example. But people still want bug fixes, and those cost money to produce.

I’ve come to realize that the lack of subscription is sometimes a red flag. A product that charges once for a lifetime of service is a recipe for failure. For example, I bought some toothbrush sensors for my kids. I can look on the app and see how well they brushed. But you buy the hardware and get the app and ongoing service for free. That’s not sustainable. So at any moment, the company might go out of business and suddenly the devices are useless. Of course, one solution is to have a platform that doesn’t require a remote server.

In general, I’m now cautious of buying things that have perpetual service and one-time payment. Subscriptions can be abused, sure, but sometimes it’s the right model or a sustainable business. Of course, I’m also buying movies I love on DVD to put them on my local server.

Twitter blew

Posted on by
1

Last night, Alex Heath reported that Elon Musk wants to raise the price of Twitter Blue and require it for verification. It’s possible that this decision won’t backfire spectacularly, but I have concerns.

Misunderstood feature

At its core, this decision fundamentally misunderstands verification. First, it’s less a benefit for the verified user than it is for the rest of the users. It’s essentially a trust mechanism: this person is who they say they are. Verification means users can more easily determine if something was said by a politician or a clever impersonator.

Of course, misunderstanding verification is not unique to Elon Musk. Twitter has always been a company that doesn’t quite understand its product. Under previous leadership, Twitter has revoked the verified status of users who have repeatedly been bad actors on the platform. This signals that verification is some sort of approval, rather than identification.

No doubt some people will choose to pay the monthly fee in order to retain their blue checkmark. But for a lot of smaller celebrities, local journalists and politicians, and the like, the $20 per month fee doesn’t seem worthwhile. There’s a value mismatch, too: verification is a one-time activity; tying it to a monthly subscription makes no sense. (It will also be interesting to see how large companies handle this. A $20/month fee is rounding error to large companies. Will they see it as worthwhile to set that up in their accounting system or will they require the social media manager to expense it?)

Show me the money

The price increase is another matter. Twitter Blue’s feature set is marginally interesting to me. I’ve given some thought to paying for it in the past at the $5 price point. At $20, it makes absolutely no sense for me. At $20, you’re more expensive than Netflix, Disney+, and several other streaming services. Does Musk think that Twitter Blue offers a Netflix level of value over the free Twitter tier?

Maybe he plans to reach his goal of having half of Twitter’s revenue come from subscriptions by destroying the ad market instead. It’s hard to see this move as anything but “I’m going to stick it to all of those liberal blue check elitists.” Quadrupling the price of a subscription and extorting your most active users is some galaxy brain business shit, I guess.

Who wants to work for this guy?

Heath’s article also says that Musk gave the team until November 7 to deliver this or else they’re fired. There’s nothing like swooping in, making a stupid demand, and tying employment to a tight delivery timeline to chase employees away. Of course, Musk has said he wants to reduce the staff at Twitter, so this might be considered a feature. But the people most likely to leave are the high performers who can easily get a job elsewhere. Seems like those are the folks you’d most want to keep.

There’s also the stories about how Musk brought in Tesla engineers to review code. “Software engineering is software engineering,” supporters say. Bullshit. Talented software engineers can look at unfamiliar code and figure out what it does, yes. But car software and social media sites are not the same. They have different considerations. Any sufficiently old code base has a lot of history that makes seemingly bad choices actually be the best choice, unless you plan on starting over from scratch.

As I was scrolling in the middle of the night because my body is dumb and didn’t want to sleep, I saw a tweet from someone who just got the full self-driving beta for their Tesla. It reminded me of how detached Elon Musk’s timelines are from reality.

Why do I care?

I feel sorry for the people who work at Twitter. Their jobs got a lot more unpleasant on Friday and there’s not much they can do about it. More selfishly, I don’t want Twitter to implode. I’ve been able to make friends over the years with people whose interests barely overlap my own. My network is full of weather, technology, sports, English professors, locals of various pursuits, and other total strangers that I’m lucky to have found. If Twitter collapses, not everyone will run to the same place. Some will move to Mastodon or other Twitter-like services popping up. Others seem to be heading for Instagram. Some will probably just abandon social media all together.

I don’t care if Elon Musk succeeds or not. But I want Twitter to succeed.

Isn’t it better to contribute code than money?

Posted on by
Reply

Recently, I was in a discussion about making contributions to open source projects. One person said it would be nice if their employer gave each employee a budget that could be directed to open source projects at the employee’s discretion. The idea is that it would be a way for employees to support the specific projects that make their jobs or lives better. Another person said “isn’t it better to contribute” code to the project?

No, it is not. Even in software companies, a large percentage of employees lack the skills necessary to make meaningful code contributions to projects. Even when you consider (the very valuable) non-code contributions like documentation, testing, graphic design, et cetera. Money is quicker and easier.

Money gives the project maintainers to put it where they need it. They could buy test hardware, pay for web hosting, hire a contractor, buy themselves a nice cup of coffee. Whatever. This is the same reason charities prefer money over goods for disaster relief donations.

Of course, money isn’t perfect either. Not all projects are equipped to accept financial donations. Even if there’s a way to route money to them, they may not want to deal with tax implications. Loosely-governed projects may not have a good mechanism for deciding how to spend the money. Money can make relationships go south in a hurry.

If you’re a company looking for ways to let employees support the open source projects that they depend on, I advocate the “¿por que no los dos?” approach. Give your employees time to contribute effort in whatever way they’re able. But also give them a pool of money to sprinkle on the projects that provide value to your company.