There are a couple of reasons but I can cite a few, I tried to push for PaaS and failed the hard way:
1. No widespread practice of environment provisioning automation. Today Docker and k8s are ubiquitous. Having a list of requirements your application needs well kept were hard to find - which Heroku needs.
2. In the same sense as above, automated deployment was not a common thing.
3. Barriers to cloud adoption. Development tools were not widespread. Paying for software development and deployment is common now, it wasn't.
I agree. If we can start a culture of relying on SQLite instead of PostgreSQL/MySQL, a whole server-side application can be a simple standalone binary.
Also, having a binary makes it easy to bundle in an Electron app.
Laravel is defaulting to SQLite now (mainly for ease of development). Also FrankenPHP has SQLite included by default. Going that route is less scalable though, obviously, unless you use one of those third party SQLite cluster solutions.
They do something which is "common" in Apple-land (Dash for MacOS does this, a Twitter client did this as well, over and over): They get the same app, add some features, call it v2, launch as a new app and remove v1 from the store.
They don't "give" you the new version. They take away the app you paid "once", and provide you with a version with an expire date. So you have no choice. You either pay them, again, or lose access to the v2 (subscription based) app.
I don't mind paying for good software, I even think Hallide is worth $60. But I won't make the same mistake again. So best of luck Lux! I really wish you all the success. If you treat your customers right this time.
That is "forever updates" = no but "take away what you had" also = no. It was a period of updates with a dropoff date of where you left off. This lines up with my expectations of a one time purchase in that I'm not expecting 50 years of feature updates when buying software just because they haven't went out of business yet I'm just expecting I keep the feature access I have at the end, which is what these posts from many different folks are all claiming.
I’ve been a Halide customer since the first week it was released. I’ve gotten numerous updates since and not been locked out of anything available when I purchased (and including many new things since too) without having to pay another dime. In fact, the app has never even mentioned the option to subscribe, I only learned of that option via this thread and found it buried deep in settings. I value their work, so I’ll now pay as I heavily use the app (among other of their products), but to say I’ve been forced to and/or “locked out” is dare I say grossly inaccurate at best.
Halide is 2.99 a month, or 12.49 a year, and has been a subscription model since 2020. Sure, you have a one-time purchase option, but it is $70. I believe people who bought before the subscription got one year free, but things like widgets aren't supported. So unfortunately, that is likely the same fate for Kino.
I'm fine if I can get a reasonable number of years out of it. I'm not expecting infinite updates forever for $9.99. 1-2y for this would be disappointing but not even a bad deal. On Halide it seems the problem is more "pricing in general" - a 1 year subscription costs more than the one time purchase in this app so naturally expecting get and keep the app plus years of updates is a bit eyewatering for a camera app (but not necessarily because of the pricing model/that it switches major versions in long cycles).
Speaking of infinite updates forever, I am frustrated that software publishers and users have come to expect that all software should either be free, subscription-based, or a one-time purchase with permanently free updates. Each of these models can make sense for different kinds of software-based products and services, but they are problematic in the case of standalone tools (such as cameras, multimedia editors, productivity software, etc.) Some of the problems:
a) Free: Due to lack of revenue, the company that makes your favorite tool may stop developing new features, add intrusive ads, sell your personal data, and/or sell itself to a nasty buyer that will end up killing your tool’s future in one of various ways.
b) Subscription-based: Many software tools are naturally products, not services, yet this model can artificially and unnecessarily turn them into services. Users may end up paying too much over the long run, the software publisher is not necessarily motivated to keep improving the tool, and if the company or a future owner decides to kill off the product, you won’t be able to keep using it (regardless of how much more you’d be willing to pay to do so.)
c) One-time purchase with permanently free updates: Though it provides the software publisher with revenue and users may appreciate the ability to keep using the tool they bought forever, the product may experience market saturation at some point, and the publisher may stop receiving revenue from new users. The publisher will not be motivated and/or financially able to improve the program and may be tempted to switch to the subscription-based model.
I really wish more companies would go back to the old-style model where users can buy the current version of a software tool but would need to pay a discounted price to upgrade to a newer version of that tool (a major-version upgrade.) Along with this, customers would get free upgrades for a limited time (such as year) or all minor upgrades during the current major version. I believe this model creates a healthy incentive for a software publisher to keep improving its products while receiving revenue from both new and existing customers (reducing the market-saturation problem.) Unfortunately, both publishers and especially users may have grown unaccustomed to this model and may not appreciate its benefits.
> I really wish more companies would go back to the old-style model where users can buy the current version of a software tool but would need to pay a discounted price to upgrade to a newer version of that tool
We can thank Apple for this! They refused to adopt upgrade pricing on the App Store (which developers have been asking for since the App Store launched!) and instead introduced Subscriptions.
I like Apple, overall, but they absolutely decimated their software market by forcing apps to either be free with ads or paid subscriptions.
>I'm fine if I can get a reasonable number of years out of it. I'm not expecting infinite updates forever for $9.99.
"Reasonable number" implies that you're fine with it. But where is that threshold? I bet it's different for everyone.
Companies need to be up front with what they are charging for. "Let's say $9.99 because we're not even sure if we'll be around in 5 years" is not a good model.
There's "I expect to get three years of value for $9.99", and then there's the "Halide isn't a subscription product, what are you talking about" people in this thread.
The unpredictability of the pricing model itself is an important point.
We have never, ever locked away Halide from people who already purchased it. If you bought Halide 1.0 in 2017, you can still use it today, with all the features you bought, without paying another penny.
Personally, for the tiny amount I paid back in 2017 for the app, $59.99 one time now is cheap to me. That’s under $1/month over that time which is well worth it to me. If I got “locked out” if I stopped paying, then I’d feel different, but that isn’t the case so keep up the good work!
I might be missing something here but thet "Calendar API" exists for a long time: CalDav.
You can have .ical for a whole Calendar, not only an (offline) event. The calendar can be synced with new events, through CalDav, when they are added to the calendar you shared. You would still have to accept the prompt once but that is it.
I am not against your rant, your are 100% on point there, but maybe your code without framework has issues you don't know?
I would rant against this forced and meaningless deprecations on Symfony-land but the main issue with PHP, IMHO, is people using it don't grok the language strengths - much in the same direction of your rant. For 5-10 years PHP developers have been trying to "bring" great features from other ecosystems making PHP not to be good on anything anymore.
I feel sad. I liked the "hack 'n slash" programming style it allowed. Now everything (everywhere) needs a package manager, a build system, etc.
PHP doesn't do a lot of BC-break. Proposing one and getting it accepted is very difficult (2/3 of +1 votes required). Most cases of BC breaks are based on security concerns.
PHP didn't learn from Python 3 BC fiasco, its governance makes such changes very difficult to be made.
I'd like to complement that. Defining/Discovering the vocabulary for the Ubiquitous Language along with Bounded Contexts (Strategic Design) is where most benefits come from. And is, as said and I agree, the most difficult part - there are no recipes, shortcuts or tools to do that for you.
It doesn't help that there is a bunch of frameworks, libraries, articles with "DDD" on their name, mindlessly gluing together patterns and segregating them into layers (Building Blocks). What I see happening the most is people using them and complaining. Which they should.
Of the two parts that compose DDD, "Strategic Design" and "Building Blocks", only one is essential: Strategic Design. But people usually just talk about the "Building Blocks" (a.k.a Anemic Models), as it seems to be the case of "stevebmark" comment. I agree with him that just having Anemic Models, following blindly the Building Blocks part of DDD as rule, is bad. I just think that calling it DDD is a mistake. DDD is the Strategic Design, you don't even need the code for it to work or produce value.
TLDR: Stripe bought TaxJar last year, to help customers “automatically calculate, report and file sales taxes”. ~25% of TaxJars employees let go this July, when Stripe's valuation dropped 28%.
1. No widespread practice of environment provisioning automation. Today Docker and k8s are ubiquitous. Having a list of requirements your application needs well kept were hard to find - which Heroku needs. 2. In the same sense as above, automated deployment was not a common thing. 3. Barriers to cloud adoption. Development tools were not widespread. Paying for software development and deployment is common now, it wasn't.
reply