Your problem could be solved by providing read-only API for free - you don't need to write access to do academic research (unless you want to influence the discourse).
This is like PE takeovers that sink companies that were previously treading water. It took on a new, ongoing expense that it couldn't afford. The layoffs, the auction, not paying leases, and this, all seem to have some cost cutting angle to them. I don't think it's necessarily because Musk is cheap or sees lots of fat to cut; I think he's desperate to lose less of his original investment.
> Probably shouldn't have landed it with $1bn/year debt payments then, eh.
It's worth remembering the market setting was very different when he made the offer. It's also worth remembering the offer was refused at the time it was made. It was only after the tech market saw a downturn, turning a good offer into an incredible one, was the offer pursued. Around that time, it also looks like he attempted to renegotiate the offer, but that was also refused.
Poor timing of the offer (only knowable in retrospect!) and shareholder obligations more or less forced this situation into existence. Musk made a good offer with a terrible contract; time, shareholders, the board, the legal system, and the stock market turned that terrible contract into a huge payout for shareholders and a signed a death warrant for Twitter.
Musk made a mistake in the way he made the offer for Twitter--but let's not pretend that the legal system isn't equally responsible for forcing the current situation. Even if the previous leadership were open to negotiating a lower buyout (and thus lower debt burden), they would have just opened themselves up to endless shareholder lawsuits had they done so. Their hands were effectively tied once the rest of the tech stock market started going down.
Not that obvious, if I was in the same position I wouldn't cut API access, if I was thinking about profits. Maybe make it heavier cached ("slower" time before new tweets are available, less infrastructure costs) but wouldn't disable it fully. My thinking would be that if there is less API access, there is less people accessing tweets, one way or another, and less links back to Twitter.
If I woke up feeling evil (really money seeking) I might add some clause to the terms and conditions that you need to prominently display "Powered by Twitter" if you use the API and aggressively check all websites using Twitter API, one way or another.
But I guess my perspective would be considered more long term while Musks management of Twitter seems to be heavily focused on short term.
>My thinking would be that if there is less API access, there is less people accessing tweets, one way or another,
the real problem from a business standpoint is less people trying stuff out and figuring hey maybe I could actually build a business on this, time to move up to the paid tier.
Also no devs at companies have played with twitter api because devs not going to spend money to play, so never say in meeting actually we can solve this with Twitter's api, we just have pay for a licence and I can write the solution! So maybe business look for other ways to solve problems.
> Maybe make it heavier cached ("slower" time before new tweets are available, less infrastructure costs) but wouldn't disable it fully.
This. I had a brief flirtation with working with people using the Twitter API for research purposes. A very large majority of them didn't care about having the latest tweets coming off the firehose, but instead getting access to all the old data. At least at the time, the latter was much more difficult to do.
Things like using Twitter for real time sentiment analysis does require realtime data, but those applications are more likely to be for-profit, and thus could afford to pay.
Right, the 30 day search API is still 100 request/mo for the sandbox and 500/mo for the bottom paid tier (which I think is $150/mo). Would love to hear more from you about this experience, whether in blog form or commentary. I use the filtered stream API a lot and the search API a bit.
Oh I’m sure. My point was just that the use cases least likely to be able to afford paying are clustered on historical data. And those clustered on real-time data tend to involve $$ anyways
Twitter can be profitable. It made over billion dollars in both 2018 and 2019 on revenues of $3 billion. 2020 was big loss but can blame the pandemic. 2021 was small loss but would have been profitable except for lawsuit settlement.
Without Musk, Twitter would likely have been profitable in 2022. No extra debt, no fleeing advertisers, no massive cuts. Some layoffs like everyone else is doing would probably have been enough.
Twitter was selling ads to companies slashing their ad budgets, not products to consumers with a lot more screen time and a lot less access to stores or to businesses newly dependent on the internet to coordinate their newly remote workforce.
Doubtful. Ad revenue is wayyyyyy down due to the impersonation/brand safety crisis Elon triggered with his erratic product moves. Letting any jokester with $8 impersonate global brands erased hundreds of millions in revenue per quarter from Twitter's bottom line. The debt situation is just an additional financial mismanagement cherry on top.
Perhaps I wasn't clear, but this was before Elon bought it. Twitter easily could have posted profits that year if they did the firings he had ultimately done. I thought that temporality made it clear we are talking in a hypothetical but I guess I wasn't clear.
Agreed, but I don't think scam and spam bots are using the API anyway - rather puppeteering tools built on Selenium or any of many scraping libraries and toolchains.
Even if they were, who's more likely to pay for an API, the scammer making shit ton of money from tricking twitter users, or the hobby dev making a cool integration with Twitter that brings people to Twitter?
Twitter API had traditionally been configurable between read-only, read-write, read-write + DM. Most apps request either of the latter two, but you always could.
There's no write-only API keys, all keys come with read permission. If you didn't encounter discussion of any of "Key", "Secret", "Token", "CK/CS" while configuring that, and are thinking of apt/yum/brew installable terminal packages and IFTTT and likes, that package or the IFTTT backend are the apps and the maintainers will have to do something about it.
My bots are set up through dev. I wasn't saying my bots don't have read/write access. Just saying that my bots _only_ actually write, and I was hoping I could perhaps still use them for that purpose without having to pay.
Yeah, I'm seeing mass announcements of shutting down. I think some are holding out small hope that something will change in the next few days. I just checked and I have six active bots.