I actually don't necessarily think that's true - As someone that has a bit of a background with the codebase of Omnivore I think the thing that killed that wasn't necessarily the business model (let's be real, they didn't even offer a premium tier.)
I think it was the introduction of features that required an unnecessary amount of processing power. Namely, RSS feeds. Their RSS implementation parsed every new webpage - a large percentage of which would never actually be read.
They hosted on Google Cloud using things like Cloud Functions. A good proportion of articles were parsed using Puppeteer, when a cheaper shorter running HTTP Request would have sufficed. The PDF viewer they used cost an arm and a leg.
None of this is to shit on the legacy of Omnivore, because I think with the team they had they built an incredible product. But I think there was a lot that could have been done to reduce monthly costs, and that there could have been more effort to monetise.
I paid for Pocket (without using premium features), and I donated to Omnivore, but the thing is ... I happened across their community whilst doing / building something else. I wouldn't have known donating / subscribing were even an option if I didn't. I'm sure I'm not the only kind of person who subscribes purely based on the fact I get value from the software.
I'd like to believe there's a viable business model around these sort of things. And honestly, a much less ethical version of me says that there absolutely is when it comes to Data. I don't think it'll ever be mega profitable, but sustainable? Sure. The Omnivore team was like 2 devs and open source contributors. I believe you could get to a point where it'd be able to sustain that team.
You are right. The architecture is just creating burdens and frictions to sustain the business if mostly relies on freemium user expansion. This is especially attractive to VC backed companies as they sometimes are judged by their growth when they are pre-revenue. And growth with free users is like a poisonous apple, that looks appealing but only accelerate the burning of your cash pile. To the point that it's afraid of charge money that may impact their main growth metrics.
I do believe apps like ReadWise that charges a subscription will have a more likelihood of surviving. Or Omnivore if it's less aggressive in expanding to compute-heavy features without charging.
My main point is, this is a category that's better served by local-first architecture, on Apple ecosystem, you also have the added benefit of having icloud sync for free.
I loved using Omnivore, and I've found so far in building https://curi.ooo that you can actually do a lot of the legwork in rendering webpages client-side (even on mobile) so that the server-side processing is just used to simplify the HTML. Obviously I'm nowhere near Omnivore's scale but so far costs have been extremely manageable.
I used it to save things, and read it on multiple devices. The readability view was never my chief concern.
There was also a period in the history of Pocket where they had influential people share their stories, and shared the top stories on the Web. It was these things that I loved about Pocket. It was a fairly easy way to get a view on the most interesting stories that other people were talking about.
I have had such a hard time finding replacements for this workflow. I built an RSS Reader into Omnivore (Separate from their implementation) to try to emulate it, but it obviously wasn't the same.
Pocket had a lot of potential, and in an era of fragmented media companies - and the paywalling of everything I really think there was an interesting business model around unifying things or acting as a quasi-publisher.
It could have been so much, and in the end it just died. Mismanaged. It's a sad story.
They'll probably remove it now, and I am devastated about that, because I still use it pretty often with my Self-Hosted Omnivore.
I might see if I can find a way to prevent updates in the future. Or hopefully they just hide the Menu Option and keep the code intact so that I can use KoboMenu to re-enable it.
If anyone from Kobo is reading, please just hide it - don't remove all the code - thanks.
I loved Pocket. I used it nearly daily. I was often in their top n% of users. I paid for it. Then one day they changed the way their rendering worked on iOS. And it destroyed my workflow.
I also bought a Kobo E-Reader specifically to use Pocket with it. In short order I found an open-source alternative - Omnivore - and spent my time hacking away at my Kobo to get it to pull from there instead. https://github.com/Podginator/KoboOmnivoreConverter
I think Pocket was amazing. I think the idea worked amazingly for someone like me, who is an enjoyer of reading, but had a hard time finding a moment to sit down and do it.
I am upset that Pocket is going. I am upset that Omnivore shut down. I am upset that my Kobo will probably remove that integration and thus ruin my Self-Hosted Omnivore's integration with it.
I bought an Amazon Fire tablet exclusively for Pocket use as well.
Something did change maybe about year and a half ago about rendering articles. It felt like less and less of them were rendering in article mode, and I needed wifi access to read articles in the original format. Before that practically everything rendered in article mode, afterwards I would say it was about 50%.
yeahs, the offline caching got terrible. its text that (rarely) changes. I have no idea why the mobile app couldn't just remember what each url was, even if it was 6 weeks stale.
Also, Pocket couldn't create reader views for many websites (like hacker news discussions), which means the TTS was useless.
That's so unfortunate--I've also used Pocket for a decade+. I had the Omnivore app installed on my phone as a replacement for the other infinite feed scrolling apps.
I'm actually working on an open-source alternative at https://curi.ooo if you're interested in checking it out. It's a work in progress, but I'm building it primarily for my own use because I'm frustrated with all these services shutting down.
The Kobo integration you have is interesting too, wonder how I could support that use case...
One personal use case that I'd love to see supported (when you get your mobile apps implemented) is the ability to add articles via the 'share' shortcuts. I get mailing lists with links, and I don't want to stop to read an article while clearing out my inbox. So if a link looks interesting, I use the 'share' feature to add it to Pocket, and then I'll go back to it later -- without opening my browser.
Yes, great suggestion. It's currently implemented in the beta Android app, just need to get registered with the Apple Developer Program and get iOS working.
Because Curio saves client-side, it opens the app and renders the page briefly though. Not sure yet if there's a better way to do it.
That's great!
I've been looking for something for a while. Great features from my point of
view:
- email newsletters, especially with offline mails (no remote images) since theya can go easily through workplace gateyways for those of us who work in secure areas. Didn't see yet if yours were.
- sync and integrate with everything, e-readers, nextcloud, browsers...
I'm in a similar spot: whenever I browse an article that could be better suited for the Kobo (i.e. admiral cloudberg), I send it to pocket. Right now I don't know how to replace it, because AFAIK Kobo don't allow to install anything similar.
As someone who self-hosts and who used the Pocket+Kobo integration _and_ who hacks away at their Kobo, hopefully folks like you and I can help keep the integration alive.
I already try to prevent the Kobo from upgrading due to unwanted changes to my Kobo patch configuration, so I'm crossing my fingers here.
Wallabag looks great, if a little homebrew. I signed up and had to laugh that the default "Welcome to wallabag" article could not be retrieved. Regardless, I decided to give 'em 12 bucks and see how it goes.
Just to add that you can also self-host it, and it supports Kobo as well. I once stumbled upon but didn't investigate further since Pocket just worked so well. I guess now I will have to.
I'm with you, I use Pocket all the time on my Kobo as well - I need to cobble together some self-hosted alternative. Did you find another alternative besides Omnivore?
I still use the self-hosted version of Omnivore - I had built quite a lot around it so when that shut down I just decided to transfer over.
It was hard enough going from Pocket to something else, I didn't want to do that again.
I actually have a Supernote now, and side-loaded the Omnivore App onto it - so I use my Kobo less (though still somewhat at night due to the backlight.)
I never really paid any attention to Pocket and never used it but 100% of the comments I ever saw were about how it was some invasion of privacy tool that was evidence of corruption in Mozilla selling your data to 3rd parties or something.
Now it's dead and ... everyone here is mourning its passing. Guess I was a successful mark for anti-Mozilla FUD tactics.
I don't think anyone was opposed to Pocket-the-product, but its integration into Firefox.
I used it long before Mozilla purchased it and continued to use it for years after, but jumped ship because years went by without any updates to the product. IIRC it hasn't received a single update between approximately 2019 and 2021. It felt abandoned long before today.
I've also used it for several years, but it really was never great compared to anything else in this space and seemingly stopped any feature development years ago.
The biggest problem for me was that they just completely gave up on paywalls, at a time when viable workarounds finally became widely available (e.g. iOS share sheet extensions being able to inject JavaScript into Safari to collect the content, which is what many alternatives do). Completely useless for reading paid news.
My feelings are 30% annoyed (because I still have some data in there), 70% hopeful that a thoroughly mediocre contender is going a way and some more consolidation in this market might finally create critical mass for and focus on some open-source, data-exportable solution in the way Omnivore unfortunately couldn't.
Another long-time Kobo user here. I hadn't even heard of Pocket before I bought an Aura One, but it quickly became my preferred way to copy miscellaneous content from PC to the reader.
I built an rss aggregator with semantic search using embeddings. The main usage was being able to categorise based on any randomly created category. So you could have arbitrary categories
I really enjoy working with embedding. They’re truly fascinating as a representation of meaning - but also a very cheap and effective way to perform very cheap things like categorisation and clustering.
How would you approach using them in a specialized discipline (think technical jargon, acronyms etc) where traning a model from scratch is practically impossible because everyone (customers, solution providers) fiercely guards their data?
A generic embedding model does not have enough specificity to cluster the specialized terms or "code names" of specific entities (these differ across orgs but represent the same sets of concepts within the domain). A more specific model cannot be trained because the data is not available.
The default where? In Windows the default is Edge, in Mac is Safari and in Linux distros usually is Firefox. And somehow people prefer to download Chrome.
I built a little RSS Reader / Aggregator that uses Cohere in order to do some arbitrary classification into different topics. I found it incredibly cheap to work with, and pretty good overall at classifying even with very limited inputs.
I also built this into a version of an OpenSource read it later app.
I just recently started heavily using TickTick, and my first thought on seeing this was that it would be cool to be able to integrate this into it. Very cool to see someone has done it, thank you!
If I might ask, how was your experience working with the TickTick API? I've been waffling on whether my frustration with some of the pain points I have with it (e.g. no way to hide recurring daily tasks that you've already completed today but aren't actionable for tomorrow from cluttering the "tomorrow" heading in every smart list) justify building my own dashboards for it.
I think it was the introduction of features that required an unnecessary amount of processing power. Namely, RSS feeds. Their RSS implementation parsed every new webpage - a large percentage of which would never actually be read.
They hosted on Google Cloud using things like Cloud Functions. A good proportion of articles were parsed using Puppeteer, when a cheaper shorter running HTTP Request would have sufficed. The PDF viewer they used cost an arm and a leg.
None of this is to shit on the legacy of Omnivore, because I think with the team they had they built an incredible product. But I think there was a lot that could have been done to reduce monthly costs, and that there could have been more effort to monetise.
I paid for Pocket (without using premium features), and I donated to Omnivore, but the thing is ... I happened across their community whilst doing / building something else. I wouldn't have known donating / subscribing were even an option if I didn't. I'm sure I'm not the only kind of person who subscribes purely based on the fact I get value from the software.
I'd like to believe there's a viable business model around these sort of things. And honestly, a much less ethical version of me says that there absolutely is when it comes to Data. I don't think it'll ever be mega profitable, but sustainable? Sure. The Omnivore team was like 2 devs and open source contributors. I believe you could get to a point where it'd be able to sustain that team.