I don't think a year is long enough though - especially for something that's unique and foundational. A complex product built using BigTable, for example, may need more than a year to migrate to something else.
In my opinion, a year is not a lot of time for any complex integration with a service. Compare that to AWS which still support effectively-retired products indefinitely.
A year is actually not that much for porting such a huge legacy system to a new platform. I imagine most of the work was making the interfaces from/to other platforms.
> The thing is, even the ESR is only supported for about a year before being completely cut off in favour of a new ESR that has only been available for about 6-12 weeks at that point. There are some large businesses out there who run the same software foundation for a decade or more.
For software like that, a web browser is not the right platform. Web browsers view a shared space which constantly changes and gets updated with new APIs and deprecated APIs and so forth.
If you want decade-long stability, use a platform that is tightly controlled and gives guarantees of backwards compatibility, for example Java or .NET.
I think it would be better to be 10 years from launch and 5 years from "unlaunch".
Also, if the company goes bankrupt the source code and necessary tools should become open source or even public domain as to allow third parties to keep providing updates.
And that's where things go off the rails. A release that is only supported for five years is a hobby project.
The kind of software projects that make the world go round continue past the lives of their original authors and can easily span decades. 5 years is just enough for the original shake-out.
That may be true but a year out when new feature X just needs to "work", the time necessary to make that happen is going to depend in part on the quality of the foundation it's being built on.
If you want to build something permanent and long-lasting, go build bridges. It does seem kind of silly to expect software to be around for a long time.
1 year? Jesus christ. You know, in other industries things are routinely supported for decades. It is a good thing large chunks of actually essential infrastructure aren't designed by web people.
It's hard to say, but I think a year is an optimistic guess, and closer to two years more realistic. That's really not that long in terms of browser years though, and you can start building stuff on it today if you want to build a product for the future.
There's a difference between end-user software and software that you're going to produce things in.
2 years is a reasonable time to expect that the user will move on to the next LTS browser version. 2 years is not a lot of time to release a game without having to upgrade the engine mid-project.
I think the thing is that the codebase after 5 years of development was already capable of making 19M/year, and the past 7 extra years have just added 1M/year. The next year of development will not add any more because the thing is collapsing under it’s own weight.
5 years if you keep up with the framework bizarre churn of adding and changing things. If you did not, there is a fair chance that you run an update in a year and things are broken or unsupported or at least deprecated/unused by other developers.
reply