One of my first programming jobs involved helping the boss make a twitter sharecropping service. I remember at some point after that project twitter made a big TOS/API change and crippled a wave of startups at the time. I was doing something else by then but it was a good warning to not let myself ever depend too much on sharecropping; over the years I've seen a lot of people learn that lesson the hard way.
I've used the API since then for on-off things, but the one I'm sore about now is a little Python script I've had running in a nightly cronjob for years that I've used to make local copies of images/videos from tweets I starred (now heart'd). It's a simple bit of code to get all my favorites and download any new ones. (If I recall correctly you need to get all of them, because the response doesn't necessarily give them to you in the order you liked them, so if today you like an old tweet from say 2012 you might have to paginate a while to get it in the response.) Looks like the json of all ~9800 liked tweets I build up to parse for new URLs is 1.5 MB gzipped, it's true their API returns a lot of unnecessary extra data. Currently debating with myself whether to cobble together a new script from one of the existing scrapers (gallery-dl might be easiest), or say screw it and write some Lisp code (more stable than Python) to fire up Selenium and waste more of twitter's bandwidth pretending to be a full browser.
Sharecropping is of course when a landowner lets someone else farm their land in exchange for a share of the crops they produce. It has the usual tradeoffs, incentives for each party, and dysfunctions at the extremes (like demanding 99.9% share) that any landlord/renter system has. I think I originally came across the expansion to a digital concept here https://blog.codinghorror.com/are-you-a-digital-sharecropper... (which is really just aggregating a couple other links), it was more focused on the phenomenon of social media users creating most of the value (usually without any monetary compensation) for the social media site owners (who did sometimes succeed in converting that to money, though as we see even in Current Year it's not exactly trivial to turn a profit).
Extending the idea of sharecropping again to digital services is just a way of describing a service or business that existentially depends on some other service (or platform or API) not just for survival (so mere dependence on e.g. legitimate payment processors doesn't make one a cropper) but also for the source of most of the value it hopes to expand upon and capture a part of. If that dependency is broken it wouldn't make sense or be feasible to have the service standalone. Social media integration startups are quintessential examples, the corpses are many. What's the point of some random startup that crawls twitter data to e.g. present rich marketing analytics data to its customers if twitter shuts down, or loses almost all its users except for like 1000 randos, or cripples its APIs among other things to make such mass data ingestion infeasible, or directly goes after the startup with lawsuits, or acquires a competitor and integrates equivalent-or-better analytics natively?
Sharecropping isn't necessarily a bad arrangement for either party (and there are cases it can be bad to be the owner). Some companies (e.g. Salesforce with its AppExchange marketplace) thread the needle a lot better when it comes to having a useful platform/pool of existing value for third parties to make useful extensions to and not scaring off new croppers or killing off many existing ones. And some croppers are more careful in selecting whose land to crop on or making their cropper status less of an immediate danger by being able to crop on multiple owners' land at once.
Sharecropping also has a strong parallel to making apps for somebody else's walled garden.
You do the labour to create the app, you do the labour of finding the right product-market fit, you take all the risks, and the landlord takes 30% or whatever for themselves, in exchange for ostensibly providing you with a platform you could not build and popularize yourself.
Everyone complains heartily about the 30%, but for a lot of sharecroppers, that's just the cost of doing business and they do fine. The bigger problem is when the landlord crunches some numbers and decides that their platform would benefit from commoditizing your app.
When that happens, they do things like buy your competitor, rebrand it as their own app, and give it away preinstalled. For example...
Or they just use all the market data they have thanks to your app to build their own app and use their brand and muscle to squeeze you into irrelevance. Microsoft in its heyday was famous for this. Just ask Lotus about Excel, or ask WordPerfect about Word.
It means that you're farming on someone else's land. Since you don't own the source of your income, the landowner could decide to evict you at any time, taking away your revenue.
I've used the API since then for on-off things, but the one I'm sore about now is a little Python script I've had running in a nightly cronjob for years that I've used to make local copies of images/videos from tweets I starred (now heart'd). It's a simple bit of code to get all my favorites and download any new ones. (If I recall correctly you need to get all of them, because the response doesn't necessarily give them to you in the order you liked them, so if today you like an old tweet from say 2012 you might have to paginate a while to get it in the response.) Looks like the json of all ~9800 liked tweets I build up to parse for new URLs is 1.5 MB gzipped, it's true their API returns a lot of unnecessary extra data. Currently debating with myself whether to cobble together a new script from one of the existing scrapers (gallery-dl might be easiest), or say screw it and write some Lisp code (more stable than Python) to fire up Selenium and waste more of twitter's bandwidth pretending to be a full browser.