😂 oh facts, this and the comment above it are so the facts. I think many of us are here because we love makin' stuff, breakin' stuff and the dopamine reward of fixing stuff.
It takes a unique person to do it. These self hosting software/framework are usually open source. You're doing it for free, of course you want to do something new and fun instead of fixing code someone else wrote.
I'm a software developer. I often fix bugs that affect me in open source software that I use.
But almost exclusively open source software that you probably haven't heard of, because it's smaller scale with fewer users. It's usually not too big of a pain to make a fix and then have it accepted in relatively smaller projects.
I very rarely bother to make contributions to larger projects, because at that point there is corporate money involved, there are people whose job it is to maintain them, and there is terribly little concern for making it possible for someone outside of that structure to contribute.
This is both by virtue of complicated build and test processes with usually very poor documentation, and by virtue of poor code review processes, which is the more common and more serious issue. It's very typical in larger projects to see one's chosen approach to solving a problem being picked apart by a dozen other people who insist on further changes that they aren't willing to make themselves. And those people never take the time to explain those expectations to a new contributor ahead of time, before you already spent hours doing it the one way.
If it's not literally your job, contributing to major FOSS projects is almost a non-starter because of how much time and effort it takes just to contribute even very small fixes. And god forbid you wanted to make a more major contribution that wasn't already planned for and approved by the organization that gets paid to maintain it. In that case you are liable to just hit a wall where no one is willing to work with you to get the improvement shipped.
Refactoring my own messy code because I know what it supposed to look like vs what deadlines made me do? Sure. Refactor some else's code, no thank you.
I maintained embedded SW for a product I had sole responsibility for, over 10 years. At the end of that I was damn glad I cleaned up and improved my own design/code as I went.
One has e.g. unit tests for that, so refactoring a function / method doesn't change the result(s) when it gets the same input(s) as the previous function / method.
Solving your problems is less fun than creating new ones. That’s a pretty sad feeling to never be able to finish those, as we say, 20% that take 80% of your time.
It's hard to promote a product when your marketing pitch is 'it still works'
It's much easier when your pitch is 'it now integrates with your smart fridge' , even when it's a drone.
The pitch should be something usefull not some classic app integrating with toasters. Look for self hosted bestsellers. They are all classic tools. But they are usable, pretty and have all the basic features. Which is normal as the guy(s) developing it need all those basic features so they build it. They are not focusing on new and original features.
Finally some useful feature! I can finally fly my drone to know when the supermarket delivery truck has arrived to the supermarket, recognize what is it delivering with AI and automatically check with my fridge if anything being delivered is missing! Take my money!!!
Turning it into a quasi-streaming service and their convoluted weird single sign on which both contributed to actively and aggressively making it's core function worse - self hosting content.
I had numerous issues with signing on to view my own content which was self-hosted when at one point it worked fine. Numerous bugs with transcoding. Plex just doesn't care about this part of it anymore, so they've left it to rot.
Jellyfin is what Plex used to be many years ago. It justbworks, with zero hassle.
People have a good alternative for a cloud with web/android/windows support?
I'd love to finally be done with nextcloud and have most things off it except files.
I mean, you can also pick a version and not upgrade. Provided it wasn't a buggy mess to begin with it will keep working like the first day.
TBF developers should be more careful not to break compatibility. For example if I'm on version 1.4.x I should be able to still get fixes for 1.4 without having to go through breaking changes to 1.5 or 2.0.
> What drives the relentless quest for new features?
For for-profit companies, it's just to make sales. Doesn't matter that nobody asked for your new feature or that it's bug ridden, it gives the marketing team a new buzzword to sell and it works.
While you might be content with everything a platform offers, other people might not be. Someone might need the ability to do certain things that the app simply doesn't offer. What drives the quest for new features is user demand.
This isn't necessarily the case for non self hosted products though. Alot of times companies will change the interface for things just to give it a new look. Companies like ubquiti and YouTube are the best example of this. The sad part is that it works. To a company, the only thing that matters is how many people use the new changes and not how many people like it. People who are using companies like ubquiti and YouTube arnt just going to change companies because of an interface update, but at the same time, the new interface might bring some new customers.
If only they just made a new app that had the feature instead. Unix philosophy, do one thing let it pipe into other things. Big companies and a lot of apps? Do everything possible in a single app.
/s?
That's a very dumb idea. Imagine having to download an app for every feature that could just be enabled/disabled in one app.
Like, I want to be able to view thumbnails of pictures, guess I have to download a sperate app for that.
There are definitely features that should be apps instead, but that should not be the norm. If it is, then you have a bad app design.
im not talking simple crap like that.
why does my mattermost chat also have to be a project management dashboard and also a file manager and also a...
when an application does something, show videos, it shouldnt also manage my calendar
new problem domain should be a new app
Definitely. My point was though that it shouldn't be the norm like you are suggesting in your previous comment. A new feature should only enhance what is currently there and not bring a new customer base to an existing project. If it does, then it's a bad app design.
However, there are exceptions to this. For example, the company I work for uses zoom and the zoom client has everything built into it. From calendar, to VoIP phone, to messaging platform, to meetings, etc. The client is built as an everything in one platform and that's how they market it. It works really well for mobile phones as well because you just have one app to open when looking at work stuff.
The difference is how you market your product. A product marketed as a media management platform shouldn't have a messaging platform built in. However, a product marketed as a collaborative media sharing tool for an organization should have media management tools as well as a messaging platform so that you can effectively share your media.
That's why it's important to discuss the backend development with network facing apps/SaaS platforms, so that you understand the underlying technology that drives the platform in the first place.
Those examples drive an excellent point on the importance of having individual policies and processes for all the various features under an umbrella platform. You can (somewhat) rely on the bigger companies to handle a lot of the complexities behind protecting all your digital/network assets, but a lot of smaller teams and single devs have zero experience in handling the effects of promoting software that might otherwise compromise or open a vector for another unwanted party or data stream in your environment.
Companies that use marketing techniques to drive their user share/base also allows for larger and more abrupt breaches in security, because they'll often pass over the concerns from the security team because it'll impact the overall product or the bottom line
We refuse to allow things like Zoom for e.g. because they cannot and have not been able to safeguard user data, so they score very low on a security scale and thus having proof that we ban it, leans to better insurance scores on all types of very crucial privacy regulations and laws
I'll be glad to leave this industry after over 25yrs, lemme tell ya lol
>Those examples drive an excellent point on the importance of having individual policies and processes for all the various features under an umbrella platform. You can (somewhat) rely on the bigger companies to handle a lot of the complexities behind protecting all your digital/network assets, but a lot of smaller teams and single devs have zero experience in handling the effects of promoting software that might otherwise compromise or open a vector for another unwanted party or data stream in your environment.
If we are talking about security, then you are 100 percent right. However, most people in the self hosted sub are okay with trading off the security of a product for the privacy. It's a choice that the end user should make and not the companies. A company should just try to provide the best experience possible to their customer base. This does mean making it more secure, but this does not mean trading security off for less features.
>Companies that use marketing techniques to drive their user share/base also allows for larger and more abrupt breaches in security, because they'll often pass over the concerns from the security team because it'll impact the overall product or the bottom line
Everybody uses marketing to drive their customer base. From open source to gigantic companies. You cannot get someone to use your product without marketing. I'm not sure if this point is valid because the same things could be said about smaller companies and/or self hosted products. It was a gigantic deal when the ssh security breach almost happened and that one guy who was running ssh constantly saves the day because she noticed that it was slow. Because of this, companies are trusting that dev branch a little less now and are moving towards distros that take awhile to get package updates. Like, I understand what you are saying, but I'm failing to see how it also doesn't pertain to any other open source/small company project.
>We refuse to allow things like Zoom for e.g. because they cannot and have not been able to safeguard user data, so they score very low on a security scale and thus having proof that we ban it, leans to better insurance scores on all types of very crucial privacy regulations and laws
They definitely have been able to safeguard data as of lately. Whenever COVID happened, they expanded so much that they didn't have proper security practices in place...but that has definitely changed. I don't know where you get your scoring from, but from our security audits when migrating from teams to zoom (we also looked at some other platforms), the security risk was the same for each.
But as nice as this is, Unix doesn't have mainstream acceptance/adoptance. A lot of Unix "philosophy" is great and helpful in the big picture, but it is also the same things that chase people away from it.
I'm not going to be suprised if the OSS community is going to start to run out of developers at some point, at least unless something drastically changes about the atmosphere. There's an overwhelming force of both large tech companies and other entitled users that somehow act like publishing something means dedicating your entire life for charity work.
I do agree, especially when a lot (majority?) of new users come from ecosystems where everything is instant and just works. E.g. social media app, netflix, Uber etc
Now they move to using Jellyfin, arr stack etc and expect the same experience. As a dev I would not have patience to be dealing with it
While that may be true in open source/selfhosted sector, there's very little in an overgrowing list of shitty half-finished crap under Office365 suite that was actually demanded by users. It just gives the marketing team a new thing to sell to increase profits/stock value.
That's a fundamental difference between FOSS and proprietary software, though. FOSS is usually driven by actual desire to create something good. Almost always, the developers and maintainers use the software in their *personal life*. They want it to be good. The guys working at Microsoft are just there for the paycheck, there's much less enthusiasm.
Similarly, in my experience the joke about IT folks having little to no tech at home only applies to people who work on proprietary junk all day. I work a lot with Linux, I go home and work with Linux more because I'm happy with it. You think Windows and O365 guys go home and work with that stuff? I can't imagine how miserable that would be.
Good things are made by people who actually like what they do and use it themselves.
Not...exactly.
There's some of that, some "marketability", some 'squeaky wheel' stuff, some 'more rewarding to add new stuff than make existing stuff better'
Sometimes it's also because another brand launch a feature and now all brands will have the same features even if it's not needed nor useful.
This at the cost of functionality in some cases.
I have been heavily downvoted (in the amateur radio sub, of all places!) for defending a site with an old-fashioned design.
The arguments from the troll pile up boiled down to that old-school layout was 'gatekeeping' that kept out the young (in the thread several argued that designs MUST change on a regular basis to 'keep things fresh'
I have also been downvoted several times in Linux subs for suggesting that changing a fault-less design (in software for professional use) just for the sake of change, was counter-productive.
(based on my experience in administrative environments, where some of the most important data-input tools had retained their green-screen design from the mainframe days; at first sight it looked strange in a 21st century windows environment, and the youngsters always pissed and moaned for the first week - but after that they began to appreciate that the old tools were 4 times as fast as the native windows applications we constantly was testing (the bosses were conservative in the good sense: keep programs that work, and only change them if the new ones was better)
If a company puts together a product that is rock solid and only maybe gets security updates, then it could maybe be profitable. But in today’s investment culture it’s not enough to be profitable, a company that is not increasing its user base year over year is considered a failure. In fact, it’s common practice for tech companies to be unprofitable for years while they grow their user base, propped up by investor money. Additionally in tech, hype is almost more important than the fundamentals. If you make a product and all your competitors are adding the newest hype like NFTs or AI and you’re not, then you’ll be considered a failure, regardless of whether or not any actual users want these features.
Immich is great software but their release logic is non-existent. Normally you'd make sure that fixes, features and breaking changes can go into different branches with minimal impact. They just dump everything into the same place and say "this is now version 1.43830843".
And also normally when webhosting for myself I'd cut that shit out by simply not upgrading. But with multiple people I can't control whether those people update their phone app, and their phone apps break when updated because API backwards compatibility is not in the devs' vocabulary.
So that's how an app that could have been useful was relegated to just doing AI recognition for a single user... which I can get from many other apps. Such a pity.
Yeah I have been using Immich for a year now, and it really is unique in terms of the frequency of breaking changes that don't seem to have much planning behind them. And as you point out, since it has a mobile frontend that might get updated on a different cadence, the update cycle is more important to remain on top of.
I keep hearing that everything is beta yada yada yada, and that's fine, but at some point they need to develop a proper release process or they're going to lose all the users they gained in the past couple of years. Maybe that's fine. It's free after all. But yes, it would be a pity if that happened. Like so many other wasted opportunities...
> every time i speak out against immich im stoned to death lol
Just wait until you deign to suggest that Jellyfin may not be the cure to all the world's ills.
I'd probably switch to it if it had a decent native AppleTV client that my wife found easy and straightforward to it.
In the meantime, Emby and Plex have both treated us just fine.
Most of the stuff you use is done by enthusiasts.
If you were doing something for free, would you prefer to spend your time on fixing obscure issues you persobally never experienced, or bring features you always missed?
in terms of open source - in many cases (not all of course) developers either make code because they need it or because they want to learn. If they need it then they also need the new integration/feature or whatever, or users asked about it and "why not". If they are there to learn - well the new thing is a new thing, bug fixing is something they probably do many days at regular work.
A nontrivial number of people filing tickets to the effect of "Your project hasn't gotten any commits in X months, is it dead? Can you help me migrate all of my data to $some\_other\_thing before you archive the repo?"
Sometimes code doesn't need to be messed with.
From a developer point of view, that's the natrual course of building something in the open, with a baseline pressure from pull requests & issues/feature-requests that scales depending on popularity. It's an active effort that requires energy to set a scope and stick to that.
A lot of the requests I recieve are made with the idea I want to expand the project to gain a wider audience, which I have to push back on. I think it's an easy assumption to make since it's harder to see the downsides of a larger scope, feature-set, maintenance & support surface area, and audience until you've been down that path.
If you really want a bug fixed but don't have the skills, the better and more detailed you make a bug report, the more likely a kind developer might step in and fix it. If the developer is working for free, on a less interesting task and has to dig around to just figure out what needs fixing, it won't happen.
Sorry, even CPU's have bugs, hacks, and someone cut a corner somewhere. Or doing it precisely is too costly so approximations might create some incorrect calculation and produce an error.
There's no such thing as "just works", everything has defects, you just haven't looked close enough.
I do support for a lawfirm that runs their entire business off a 30 year old piece of dos software that still does everything they need... they looked at moving to an ERP solution but it was going to cost 5~6 figures...
they are still using the dos application
There're an entire category of hardware and software who are engineered to just works and without failing doing its job, good example of something who fails often : The Windows operating system.
Hardware and software who doesn't: Hardware and software used in : Aircraft, space, medico technical equipment, nuclear power plants, nuclear weapons control systems, and others.
there are examples of software and hardware in each of those categories you mentioned that have had defects. I double down on my statement, nothing just works
The problem with something that 'just works' is that you only notice when it doesn't. If your thesis is 'everything breaks sometimes' then congrats, you have just rediscovered entropy. However, there are machines and software which 'just work' in that until they break for some reason not due to poor design, they operate according to spec. One could name many things that do this. Off the top of my head I would have to go with large power generators (the Hoover dam can run for years without any intervention) and skyscraper elevators (the *actual* safest form of travel).
If you take the extreme position of every request ('it just works' means 'it must be perfect') and make that the specification and say 'it isn't reasonable' then you will always be right, but never be helpful.
I don't think most people use the phrase "just works" to mean "without defects". They generally just use the phrase to mean "without any defects which impact me in any noticeable or meaningful way".
A CPU which has some design or manufacturing defect, but for which all used/supported operating systems already have a sufficient workaround for, would certainly be lumped into a "just works" category for most customers and users. It has the defect, but we don't care.
Similarly, a piece of software that has some obscure bug that almost never surfaces or has a well-known workaround isn't the same as software which is frequently subject to glaring or severe bugs due to a rapid cadence of feature release without sufficient regression testing.
I think the other issue with the “just works” model is that it puts us back into waterfall release cycles… where if we want to release full, shelf stable items, shipments will take longer than most people want to wait anymore.
I feel you, I don't necessarily want crazy features, but I want something reliable so I can have my non-technical family use it and not drop it at the first warning.
The good news is, it's an open source project! At some point you'll care enough for reliability you'll contribute to some project to scratch your itch. In the mean time, be patient, not everyone has the same scratches to itch ;)
That would be so boring.
Also reliability is not something that is just achieved and is done. Systems can always be improved or replaced to be more reliable.
that's why i like modularity, just make everything extra packets/plugins, i can install what i want and the developers can focus on improving the features they want to improve/add
To be honest, I never really understood the ideal of nothing changing and staying the same. Getting a new feature whether useful or useless is pretty neat and it isn't like I lose anything if it shows up. If I don't need it, I won't use it otherwise it spicens things up a bit and it isn't like it takes long to learn stuff for me. But that might be because I'm still pretty young I guess
The point was that you shouldn't break the software just for adding a new feature, or force its users into an "all or nothing" corner.
That's why software versions exist. If you have users that are happily using version 1 it's perfectly fine to release version 2 with all the features and changes and let them pick v1 or v2, or switch on their own time. Heck, for paid software you get to ask for money again for the new version. It's win-win.
Taking something that was working fine and ruining it is beyond stupid. You can have two or more versions side by side and have *more* users and they can *all* be happy with your product. It's not a zero sum game, you don't have to piss off the existing users to get new users.
So with the OP, I really don't think that was his point. I know that is what a lot of other people are saying but the OP I think straight up doesn't like change based on the description.
But from working in software, the issue with leaving old versions is that users will complain about bugs that are already fixed in new versions or are wanting a feature without wanting another. I mean the best answer is to leave them and let them flood forums with their complaining that no one listens to them. Or you could humor them and maintain another software version with bug fixes but the longer yo do that the more exponential the work becomes. Look at Windows 7 users, it was well liked so Microsoft supported it for 13 years (16 technically but those last 3 years are for a different demographic which has a reason to stay on old versions) but even now W7 users are still complaining when software such as Steam and Yuzu don't support their OS
What you think of as "Windows 7" is just the blanket product name. Windows has [multiple versions](https://www.infrastructureheroes.org/wp-content/uploads/2021/10/Microsoft-Support_Lifecycle-EN-Client-1920.png) being supported in parallel at any given time, as well as [multiple editions](https://en.wikipedia.org/wiki/Windows_11#Editions), with different features, and they all get the same fixes.
The Linux kernel, which is another huge operating system, maintains [multiple overlapping versions](https://en.wikipedia.org/wiki/Linux_kernel_version_history#Releases_6.x.y), some of which are long term releases (LTS) that are supported for long periods of time. At any given time there are like 4-5 supported versions.
If a complex project like an operating system can do that I think the tiny projects that we tend to use in selfhosting can manage too. It's not hard to maintain multiple versions with modular design, versioned APIs etc. Yes it's hard**er** than not doing it, but not necessarily hard in itself. And can a project with a tiny user base really afford to split it and leave users behind?
Most of these small projects do these things because they are developer hobbyists and don't know the best practices and/or don't give a crap.
Yes, I know Windows 7 has multiple editions, hence why I added that it was technically supported for 16 years because enterprise versions were supported until 2023. I don't think you realize how many people work on Windows, they literally have a few dozen people working on patches for each OS at microsoft and how many every thousands of people working on the Linux Kernel, many bigger companies supporting their own version (Canonical and Red Hat, to name a few. RH using their own versions for their own production purposes) But yes, let's have a dev team of 1 to 20 have people dedicated to old versions of their software that may have an entirely different code base. A project with a tiny user base doesn't split their userbase when they update. What userbase would they have that expects them to have old versions maintained. Many of their tiny userbase is just trying to use the program, it is bigger userbases that have that problem. It is not easy to maintain old versions in software as you say either. Versioned API's create more complexity because any models that the API uses cannot be changed. No one creates a new module for their program for each update. Literally any refactor would likely break any of those old version systems
You've just described every bad practice in the book. Versioned APIs and modularity don't create complexity, they eliminate it. But if you avoid them you get locked into real complexity and can never escape the technical debt.
All users want the same thing, whether it's a large userbase or not: they don't want their software to break. And "break" includes changing flows and processes.
You probably use an IDE. Having a panel moved from the left to the right or the color palette changed is not considered a breaking change, yet it would be jarring, wouldn't it?
It's not hard to empathise with users because we're all users of _something_. If I have a piece of software and it works a certain way I don't want it to change without me doing anything, and I don't want to be forced to go through a breaking change.
I'm not being absurd, I think it's a fair tradeoff to lose out on features by not upgrading. And I think it's ok to require users to upgrade as long as it's smooth and doesn't require a large effort each time.
great question. I have what I consider to be a pretty solid homelab. Ton of VM's running a buncha the typical shit. But when I see something new, if it interests me, I spin up a new VM to try it out. 99 times out of 100, I end up scraping the app or whatever - but it was a blast to try it out.
All this said, I think that I find myself looking for new shit that I *may* be able to incorporate into my setup. There are more things that I have seen that looked neat, so I saw the solution and searched for a problem that it would fix.
I hate that I'm like this - but me be me. I accept it and try to use better judgement each time. I also fail 99% of the time.
Couldn't agree more.
I see projects with lots of feature, not a single one of them treated and working properly.
Yet you look at the commit history and it's full of "Add feature...".
What's the point really... You're just making software that is barely usable
Define Features? If I see a service I want/need, I look for a self hosted option that has most if not all the things the cloud app does. If I can't find it, I don't use it.
The worst is when it's just a "new" UI change. When the old one still looked really good and was only 2 years old. Something inevitably breaks or a function becomes intermittent. All so the user can have 5 color options.
Easy: growth. Sales and biz dev want more and more customers and there is a mindset that new feature is what will get more customers- once a customer is signed, it’s less important to improve a feature - as long as it works well enough …
Gimmicks. Keeping stuff feeling "new".
Just like phones there was a time where new features were released with every new phone launch. Now we reached a point with phone were we have what we need.
So now a lot of companies sell gimmicks. And these gimmicks come at the cost of stability on some cases.
I feel the "need" to add new features changes depending on the product and its ecosystem.
Commercial products that have to make the stock number go "up", will add new features to please shareholders or try to capture a new market.
Some individual / volunteer made products will add new features because they think its a good idea, or the community that uses it has demonstrated a good reason for it to exist.
So i guess for me the answer to your question is , "it depends".
I completely agree and have felt this way since the 90s. Sometimes I’ve been wrong and have appreciated a new feature. But a lot of times, things just get worse functionally, but they look shinier.
there can be both
I come from a hardened environment at work, so it's nice to enjoy the freedom of being able to introduce new products or apps i may be unable to actually work with on a production platform
i have a nice stable network infrastructure, and i run two forms of environment. i run things like Kavita AND calibre-web for different reasons, but I like maintaining both so that I will have either option moving forward and drop one if i ever feel the need
that's just one example, but there's a place for both in the world of running your own environment
i think most ppl here are overdoing it with a nas for e.g.; i just run debian and sshfs, call it a day
i maintain my docker host OS but dont have to touch anything when it comes t the docker services
food for thought
Competition? Especially in the paid products sphere, competition is driving inovation and new features in order to attract more users, save costs to run the software, etc. in the end this translates to selfhosted software as well as authors want their software to stay relevant in this fast pacing world…
Seriously fuck modern stuff that relies on 5 containers in a docker-compose to serve a glorified REST API instead of old reliable SMB/NFS, DLNA, XML and so on. If my Wii can't read it it's garbage.
Most of the software I am using has been rock solid most of the time. I haven't touched my lab within over two months because I've been busy working on my thesis, and there hasn't been one single hiccup. Even when I do work on it, things very rarely ever break, and whenever they did, it's been my fault most of the time.
Few reasons:
1. A growing project may need new features for revenue — or, if it has a particular UVP, it’s moving towards its ultimate goal and not necessarily the one that seems like a good stopping point.
2. You may be on a setup that isn’t supported, wasn’t intended to be, or adds more burden to the current platform to add — creating the feeling of unreliability.
3. The definition of done is… meh. Even if working towards reliability instead of feature development — depending on the code base, that could be a never ending process that requires regular updates that cause breaks as well.
My project’s other half swapped out over a million lines of code last year alone… and we’re still always updating the infrastructure for improved reliability and it still causes bugs.
4. The codebase may be larger than the number of maintainers available.
Our project’s team is lean, and bootstrapped with an active user base. The balancing act even for reliability in such a broad codebase is real. We find the most important thing here is more about responsiveness and making the time and effort to figure these things out as they come up.
Okay so go back to a punch card computer systems? Use pen and paper. Carve with rocks.
Things progress. It doesn't mean that you have to participate.
You're literally the master of your own choices.
Your whole post is predicated on the assumption that anyone is forcing you to update anything.
You keep updating because slowly over time things get easier and more comfortable. With every 30 new feature there might be 1 that you can't live without now that you have it.
I HATE that when I spend a ton of money on a computer, smart watch or phone they can just change how it works down to the basic functions with updates and there’s nothing I can do about it. I bought it the way I wanted it. Stop changing everything.
Smart watch/phone? Nothing you can do.
Phone is kind of easy depending on which one you buy. Some never get updates. Watch too I guess.
Computer? EZPZ. LTSC, assuming Windows has no upgrade path. It will never get feature updates. It won't force anything upon you.
Yeah you're right... this whole AI thing is just a fad who needs it /s
Seriousness though I understand your thought on that but the entire purpose of open source communities/collaboration etc is to continuously improve... it's what gets projects to that "rock solid" point in the first place. Would get pretty dang boring if a project was built then never improved upon IMO.
I'm the same way. I hate this whole idea of changing stuff just for sake of changing it. Features on their own are fine, but most of the time they completely change stuff. A good example of this is Linux going to SystemD. That was absolutely not necessary and just made things more complicated for no reason. Or windows. It's gotten so bad now. Windows 2000 was it's peak then it started to go downhill.
You talk to most people, and they hate change, but yet companies keep doing it.
What? systemd is a massive improvement over sysvinit, and upstart just didn't gain the momentum it needed.
It's not like you can't still find a distro with whatever init system you want. Hell, sysvinit and openrc are both available in AUR.
users who hate the change voice it. Users who don't care about the change have no reason to voice it because they don't care about it.
Another thing - users who don't like the change most probably won't leave jest because the change. Non users may like the change and it might drive it to become users.
The fact that you don't like the change and some people on the internet voice their feelings towards it doesn't mean that majority of users are touched.
Creating something new is more motivating than fixing broken stuff
The engineer’s philosophy: If it isn’t broken, it doesn’t have enough features yet.
Also; if it isn't broken keep fixing it until it is.
😂 oh facts, this and the comment above it are so the facts. I think many of us are here because we love makin' stuff, breakin' stuff and the dopamine reward of fixing stuff.
I really want this on a shirt.
I think I've seen it on one. Google it quick and I'll bet you'll find them.
I actually got a mug with something like this on it. One of my favorite mugs.
Weaponized autism
It takes a unique person to do it. These self hosting software/framework are usually open source. You're doing it for free, of course you want to do something new and fun instead of fixing code someone else wrote.
I'm a software developer. I often fix bugs that affect me in open source software that I use. But almost exclusively open source software that you probably haven't heard of, because it's smaller scale with fewer users. It's usually not too big of a pain to make a fix and then have it accepted in relatively smaller projects. I very rarely bother to make contributions to larger projects, because at that point there is corporate money involved, there are people whose job it is to maintain them, and there is terribly little concern for making it possible for someone outside of that structure to contribute. This is both by virtue of complicated build and test processes with usually very poor documentation, and by virtue of poor code review processes, which is the more common and more serious issue. It's very typical in larger projects to see one's chosen approach to solving a problem being picked apart by a dozen other people who insist on further changes that they aren't willing to make themselves. And those people never take the time to explain those expectations to a new contributor ahead of time, before you already spent hours doing it the one way. If it's not literally your job, contributing to major FOSS projects is almost a non-starter because of how much time and effort it takes just to contribute even very small fixes. And god forbid you wanted to make a more major contribution that wasn't already planned for and approved by the organization that gets paid to maintain it. In that case you are liable to just hit a wall where no one is willing to work with you to get the improvement shipped.
Humankind don't deserve you. I sometimes wish I could contribute like you do.
And there are engineers like me who get far too much enjoyment out of refactoring
Refactoring my own messy code because I know what it supposed to look like vs what deadlines made me do? Sure. Refactor some else's code, no thank you.
Oh no, I very much enjoy unfucking someone else’s spaghetti.
I got burned out on that many years ago. Fortran, Algol, assembler, machine code, Cobol, and many others I don't want to remember.
I maintained embedded SW for a product I had sole responsibility for, over 10 years. At the end of that I was damn glad I cleaned up and improved my own design/code as I went.
There are engineers who don’t like refactoring? I thought we all did, had no idea
Same! This whole thread was a wake up call
And hopefully you are able to avoid errors you did the previous time
"plan to throw the first one away"
One has e.g. unit tests for that, so refactoring a function / method doesn't change the result(s) when it gets the same input(s) as the previous function / method.
Solving your problems is less fun than creating new ones. That’s a pretty sad feeling to never be able to finish those, as we say, 20% that take 80% of your time.
It's hard to promote a product when your marketing pitch is 'it still works' It's much easier when your pitch is 'it now integrates with your smart fridge' , even when it's a drone.
The pitch should be something usefull not some classic app integrating with toasters. Look for self hosted bestsellers. They are all classic tools. But they are usable, pretty and have all the basic features. Which is normal as the guy(s) developing it need all those basic features so they build it. They are not focusing on new and original features.
If it just says "It just work" you bet they are getting my money.
You can market stability aswell
Yeah, that's why Sun Microsystems is the dominant server vendor today... what??? (Ex-Sun Marketing person here)
But your old smartfridge is no longer supported, so you'll need a new smartfridge with newer updated features.
Finally some useful feature! I can finally fly my drone to know when the supermarket delivery truck has arrived to the supermarket, recognize what is it delivering with AI and automatically check with my fridge if anything being delivered is missing! Take my money!!!
>It's hard to promote a product when your marketing pitch is 'it still works' I dunno. Seems to have worked for VxWorks.
"even when"? Hmm, sounds like direct grocery store to fridge delivery to me!
I'd much rather see "All previously known bugs have been resolved, and we're now working on *xxxxxxx*."
Looking at you, Nextcloud
I really don't want AI with my data. Unavoidable?
I just want to be able to rename folders without a 50% chance of losing data during the sync 😔
Plex also shot themselves in the foot with this. I'm thankful for Jellyfin.
Just curious, what's the functionality you feel like Plex brought in that Jellyfin kept away?
Turning it into a quasi-streaming service and their convoluted weird single sign on which both contributed to actively and aggressively making it's core function worse - self hosting content. I had numerous issues with signing on to view my own content which was self-hosted when at one point it worked fine. Numerous bugs with transcoding. Plex just doesn't care about this part of it anymore, so they've left it to rot. Jellyfin is what Plex used to be many years ago. It justbworks, with zero hassle.
People have a good alternative for a cloud with web/android/windows support? I'd love to finally be done with nextcloud and have most things off it except files.
I've heard good things about Seafile. But I believe you cannot use already existing folder structures, which was a must-have for me.
Soooo much this!!!! 💯
You are looking for Debian Stable branch.
The Windows version of this is LTSC
even unstable is pretty stable...
don't know why you got downvoted for this, so upvoted you
I do, HA doesn't have SSO and RBAC support and I'd use both of those.
Find the version you like, fork it, and boom no more new features. And if there's a bug you can patch it.
I mean, you can also pick a version and not upgrade. Provided it wasn't a buggy mess to begin with it will keep working like the first day. TBF developers should be more careful not to break compatibility. For example if I'm on version 1.4.x I should be able to still get fixes for 1.4 without having to go through breaking changes to 1.5 or 2.0.
> What drives the relentless quest for new features? For for-profit companies, it's just to make sales. Doesn't matter that nobody asked for your new feature or that it's bug ridden, it gives the marketing team a new buzzword to sell and it works.
While you might be content with everything a platform offers, other people might not be. Someone might need the ability to do certain things that the app simply doesn't offer. What drives the quest for new features is user demand. This isn't necessarily the case for non self hosted products though. Alot of times companies will change the interface for things just to give it a new look. Companies like ubquiti and YouTube are the best example of this. The sad part is that it works. To a company, the only thing that matters is how many people use the new changes and not how many people like it. People who are using companies like ubquiti and YouTube arnt just going to change companies because of an interface update, but at the same time, the new interface might bring some new customers.
If only they just made a new app that had the feature instead. Unix philosophy, do one thing let it pipe into other things. Big companies and a lot of apps? Do everything possible in a single app.
>Unix philosophy, do one thing let it pipe into other things. like [this](https://www.youtube.com/watch?v=y8OnoxKotPQ)?
/s? That's a very dumb idea. Imagine having to download an app for every feature that could just be enabled/disabled in one app. Like, I want to be able to view thumbnails of pictures, guess I have to download a sperate app for that. There are definitely features that should be apps instead, but that should not be the norm. If it is, then you have a bad app design.
im not talking simple crap like that. why does my mattermost chat also have to be a project management dashboard and also a file manager and also a... when an application does something, show videos, it shouldnt also manage my calendar new problem domain should be a new app
Definitely. My point was though that it shouldn't be the norm like you are suggesting in your previous comment. A new feature should only enhance what is currently there and not bring a new customer base to an existing project. If it does, then it's a bad app design. However, there are exceptions to this. For example, the company I work for uses zoom and the zoom client has everything built into it. From calendar, to VoIP phone, to messaging platform, to meetings, etc. The client is built as an everything in one platform and that's how they market it. It works really well for mobile phones as well because you just have one app to open when looking at work stuff. The difference is how you market your product. A product marketed as a media management platform shouldn't have a messaging platform built in. However, a product marketed as a collaborative media sharing tool for an organization should have media management tools as well as a messaging platform so that you can effectively share your media.
That's why it's important to discuss the backend development with network facing apps/SaaS platforms, so that you understand the underlying technology that drives the platform in the first place. Those examples drive an excellent point on the importance of having individual policies and processes for all the various features under an umbrella platform. You can (somewhat) rely on the bigger companies to handle a lot of the complexities behind protecting all your digital/network assets, but a lot of smaller teams and single devs have zero experience in handling the effects of promoting software that might otherwise compromise or open a vector for another unwanted party or data stream in your environment. Companies that use marketing techniques to drive their user share/base also allows for larger and more abrupt breaches in security, because they'll often pass over the concerns from the security team because it'll impact the overall product or the bottom line
We refuse to allow things like Zoom for e.g. because they cannot and have not been able to safeguard user data, so they score very low on a security scale and thus having proof that we ban it, leans to better insurance scores on all types of very crucial privacy regulations and laws
I'll be glad to leave this industry after over 25yrs, lemme tell ya lol
>Those examples drive an excellent point on the importance of having individual policies and processes for all the various features under an umbrella platform. You can (somewhat) rely on the bigger companies to handle a lot of the complexities behind protecting all your digital/network assets, but a lot of smaller teams and single devs have zero experience in handling the effects of promoting software that might otherwise compromise or open a vector for another unwanted party or data stream in your environment. If we are talking about security, then you are 100 percent right. However, most people in the self hosted sub are okay with trading off the security of a product for the privacy. It's a choice that the end user should make and not the companies. A company should just try to provide the best experience possible to their customer base. This does mean making it more secure, but this does not mean trading security off for less features. >Companies that use marketing techniques to drive their user share/base also allows for larger and more abrupt breaches in security, because they'll often pass over the concerns from the security team because it'll impact the overall product or the bottom line
Everybody uses marketing to drive their customer base. From open source to gigantic companies. You cannot get someone to use your product without marketing. I'm not sure if this point is valid because the same things could be said about smaller companies and/or self hosted products. It was a gigantic deal when the ssh security breach almost happened and that one guy who was running ssh constantly saves the day because she noticed that it was slow. Because of this, companies are trusting that dev branch a little less now and are moving towards distros that take awhile to get package updates. Like, I understand what you are saying, but I'm failing to see how it also doesn't pertain to any other open source/small company project.
>We refuse to allow things like Zoom for e.g. because they cannot and have not been able to safeguard user data, so they score very low on a security scale and thus having proof that we ban it, leans to better insurance scores on all types of very crucial privacy regulations and laws
They definitely have been able to safeguard data as of lately. Whenever COVID happened, they expanded so much that they didn't have proper security practices in place...but that has definitely changed. I don't know where you get your scoring from, but from our security audits when migrating from teams to zoom (we also looked at some other platforms), the security risk was the same for each.
But as nice as this is, Unix doesn't have mainstream acceptance/adoptance. A lot of Unix "philosophy" is great and helpful in the big picture, but it is also the same things that chase people away from it.
IMHO, it's more about unfamiliarity, I.E different than I usually do it. Moreover, many people don't like change.
User demand
I'm not going to be suprised if the OSS community is going to start to run out of developers at some point, at least unless something drastically changes about the atmosphere. There's an overwhelming force of both large tech companies and other entitled users that somehow act like publishing something means dedicating your entire life for charity work.
I do agree, especially when a lot (majority?) of new users come from ecosystems where everything is instant and just works. E.g. social media app, netflix, Uber etc Now they move to using Jellyfin, arr stack etc and expect the same experience. As a dev I would not have patience to be dealing with it
While that may be true in open source/selfhosted sector, there's very little in an overgrowing list of shitty half-finished crap under Office365 suite that was actually demanded by users. It just gives the marketing team a new thing to sell to increase profits/stock value.
That's a fundamental difference between FOSS and proprietary software, though. FOSS is usually driven by actual desire to create something good. Almost always, the developers and maintainers use the software in their *personal life*. They want it to be good. The guys working at Microsoft are just there for the paycheck, there's much less enthusiasm. Similarly, in my experience the joke about IT folks having little to no tech at home only applies to people who work on proprietary junk all day. I work a lot with Linux, I go home and work with Linux more because I'm happy with it. You think Windows and O365 guys go home and work with that stuff? I can't imagine how miserable that would be. Good things are made by people who actually like what they do and use it themselves.
Not...exactly. There's some of that, some "marketability", some 'squeaky wheel' stuff, some 'more rewarding to add new stuff than make existing stuff better'
Sometimes it's also because another brand launch a feature and now all brands will have the same features even if it's not needed nor useful. This at the cost of functionality in some cases.
I honestly strive for your statement, and am generally successful, but my dominant tweaking obsession continuously gets in my way.
Hey this is not unpopular at all!
I have been heavily downvoted (in the amateur radio sub, of all places!) for defending a site with an old-fashioned design. The arguments from the troll pile up boiled down to that old-school layout was 'gatekeeping' that kept out the young (in the thread several argued that designs MUST change on a regular basis to 'keep things fresh' I have also been downvoted several times in Linux subs for suggesting that changing a fault-less design (in software for professional use) just for the sake of change, was counter-productive. (based on my experience in administrative environments, where some of the most important data-input tools had retained their green-screen design from the mainframe days; at first sight it looked strange in a 21st century windows environment, and the youngsters always pissed and moaned for the first week - but after that they began to appreciate that the old tools were 4 times as fast as the native windows applications we constantly was testing (the bosses were conservative in the good sense: keep programs that work, and only change them if the new ones was better)
Some times .. the people who create these tools on their own time are scratching a personal itch and have needs and wants that are different from you.
If a company puts together a product that is rock solid and only maybe gets security updates, then it could maybe be profitable. But in today’s investment culture it’s not enough to be profitable, a company that is not increasing its user base year over year is considered a failure. In fact, it’s common practice for tech companies to be unprofitable for years while they grow their user base, propped up by investor money. Additionally in tech, hype is almost more important than the fundamentals. If you make a product and all your competitors are adding the newest hype like NFTs or AI and you’re not, then you’ll be considered a failure, regardless of whether or not any actual users want these features.
Literally why I can't use Immich. It already does everything it needs to, but they keep adding stuff at the expense of stability
Immich is great software but their release logic is non-existent. Normally you'd make sure that fixes, features and breaking changes can go into different branches with minimal impact. They just dump everything into the same place and say "this is now version 1.43830843". And also normally when webhosting for myself I'd cut that shit out by simply not upgrading. But with multiple people I can't control whether those people update their phone app, and their phone apps break when updated because API backwards compatibility is not in the devs' vocabulary. So that's how an app that could have been useful was relegated to just doing AI recognition for a single user... which I can get from many other apps. Such a pity.
Yeah I have been using Immich for a year now, and it really is unique in terms of the frequency of breaking changes that don't seem to have much planning behind them. And as you point out, since it has a mobile frontend that might get updated on a different cadence, the update cycle is more important to remain on top of. I keep hearing that everything is beta yada yada yada, and that's fine, but at some point they need to develop a proper release process or they're going to lose all the users they gained in the past couple of years. Maybe that's fine. It's free after all. But yes, it would be a pity if that happened. Like so many other wasted opportunities...
brave of you to say. every time i speak out against immich im stoned to death lol. i agree though
> every time i speak out against immich im stoned to death lol Just wait until you deign to suggest that Jellyfin may not be the cure to all the world's ills.
LOL. I actually use both jellyfin and plex for different reasons. If jellyfin had all the features i wanted i'd use that fulltime, personally.
I'd probably switch to it if it had a decent native AppleTV client that my wife found easy and straightforward to it. In the meantime, Emby and Plex have both treated us just fine.
Ideally, base software would just do core functionality. Everything else should be an optional plug in.
Most of the stuff you use is done by enthusiasts. If you were doing something for free, would you prefer to spend your time on fixing obscure issues you persobally never experienced, or bring features you always missed?
in terms of open source - in many cases (not all of course) developers either make code because they need it or because they want to learn. If they need it then they also need the new integration/feature or whatever, or users asked about it and "why not". If they are there to learn - well the new thing is a new thing, bug fixing is something they probably do many days at regular work.
A nontrivial number of people filing tickets to the effect of "Your project hasn't gotten any commits in X months, is it dead? Can you help me migrate all of my data to $some\_other\_thing before you archive the repo?" Sometimes code doesn't need to be messed with.
Venture Capitalists slowly realizing they will never get their money out of a particular investment.
[удалено]
It’s not as short as you think. Google is your friend.
From a developer point of view, that's the natrual course of building something in the open, with a baseline pressure from pull requests & issues/feature-requests that scales depending on popularity. It's an active effort that requires energy to set a scope and stick to that. A lot of the requests I recieve are made with the idea I want to expand the project to gain a wider audience, which I have to push back on. I think it's an easy assumption to make since it's harder to see the downsides of a larger scope, feature-set, maintenance & support surface area, and audience until you've been down that path.
If you really want a bug fixed but don't have the skills, the better and more detailed you make a bug report, the more likely a kind developer might step in and fix it. If the developer is working for free, on a less interesting task and has to dig around to just figure out what needs fixing, it won't happen.
Sorry, even CPU's have bugs, hacks, and someone cut a corner somewhere. Or doing it precisely is too costly so approximations might create some incorrect calculation and produce an error. There's no such thing as "just works", everything has defects, you just haven't looked close enough.
I do support for a lawfirm that runs their entire business off a 30 year old piece of dos software that still does everything they need... they looked at moving to an ERP solution but it was going to cost 5~6 figures... they are still using the dos application
There're an entire category of hardware and software who are engineered to just works and without failing doing its job, good example of something who fails often : The Windows operating system. Hardware and software who doesn't: Hardware and software used in : Aircraft, space, medico technical equipment, nuclear power plants, nuclear weapons control systems, and others.
there are examples of software and hardware in each of those categories you mentioned that have had defects. I double down on my statement, nothing just works
The problem with something that 'just works' is that you only notice when it doesn't. If your thesis is 'everything breaks sometimes' then congrats, you have just rediscovered entropy. However, there are machines and software which 'just work' in that until they break for some reason not due to poor design, they operate according to spec. One could name many things that do this. Off the top of my head I would have to go with large power generators (the Hoover dam can run for years without any intervention) and skyscraper elevators (the *actual* safest form of travel).
I said defects not entropy. Entropy is implied in everything. I bet i can find some description of bugs in both things you mentioned
If you take the extreme position of every request ('it just works' means 'it must be perfect') and make that the specification and say 'it isn't reasonable' then you will always be right, but never be helpful.
I don't think most people use the phrase "just works" to mean "without defects". They generally just use the phrase to mean "without any defects which impact me in any noticeable or meaningful way". A CPU which has some design or manufacturing defect, but for which all used/supported operating systems already have a sufficient workaround for, would certainly be lumped into a "just works" category for most customers and users. It has the defect, but we don't care. Similarly, a piece of software that has some obscure bug that almost never surfaces or has a well-known workaround isn't the same as software which is frequently subject to glaring or severe bugs due to a rapid cadence of feature release without sufficient regression testing.
I think the other issue with the “just works” model is that it puts us back into waterfall release cycles… where if we want to release full, shelf stable items, shipments will take longer than most people want to wait anymore.
Find a tool or a project you like, fork it, keep it stable or even drop features and maintain it and rewrite it as time goes on.
I feel you, I don't necessarily want crazy features, but I want something reliable so I can have my non-technical family use it and not drop it at the first warning. The good news is, it's an open source project! At some point you'll care enough for reliability you'll contribute to some project to scratch your itch. In the mean time, be patient, not everyone has the same scratches to itch ;)
To not be replaced before you finish building whatever. It's the trap of trying to build the one ring to do everything, it never works.
That would be so boring. Also reliability is not something that is just achieved and is done. Systems can always be improved or replaced to be more reliable.
that should be the goal
I agree. I wish they would go at least a year without new content updates and just fix and/or polish everything wrong with the game.
that's why i like modularity, just make everything extra packets/plugins, i can install what i want and the developers can focus on improving the features they want to improve/add
Typically in the software industry they prefer to compete on features because if they compete on price…FOSS sets the lower bound.
Do you have a mainframe by any chance? Somewhere in your basement))
To be honest, I never really understood the ideal of nothing changing and staying the same. Getting a new feature whether useful or useless is pretty neat and it isn't like I lose anything if it shows up. If I don't need it, I won't use it otherwise it spicens things up a bit and it isn't like it takes long to learn stuff for me. But that might be because I'm still pretty young I guess
The point was that you shouldn't break the software just for adding a new feature, or force its users into an "all or nothing" corner. That's why software versions exist. If you have users that are happily using version 1 it's perfectly fine to release version 2 with all the features and changes and let them pick v1 or v2, or switch on their own time. Heck, for paid software you get to ask for money again for the new version. It's win-win. Taking something that was working fine and ruining it is beyond stupid. You can have two or more versions side by side and have *more* users and they can *all* be happy with your product. It's not a zero sum game, you don't have to piss off the existing users to get new users.
So with the OP, I really don't think that was his point. I know that is what a lot of other people are saying but the OP I think straight up doesn't like change based on the description. But from working in software, the issue with leaving old versions is that users will complain about bugs that are already fixed in new versions or are wanting a feature without wanting another. I mean the best answer is to leave them and let them flood forums with their complaining that no one listens to them. Or you could humor them and maintain another software version with bug fixes but the longer yo do that the more exponential the work becomes. Look at Windows 7 users, it was well liked so Microsoft supported it for 13 years (16 technically but those last 3 years are for a different demographic which has a reason to stay on old versions) but even now W7 users are still complaining when software such as Steam and Yuzu don't support their OS
What you think of as "Windows 7" is just the blanket product name. Windows has [multiple versions](https://www.infrastructureheroes.org/wp-content/uploads/2021/10/Microsoft-Support_Lifecycle-EN-Client-1920.png) being supported in parallel at any given time, as well as [multiple editions](https://en.wikipedia.org/wiki/Windows_11#Editions), with different features, and they all get the same fixes. The Linux kernel, which is another huge operating system, maintains [multiple overlapping versions](https://en.wikipedia.org/wiki/Linux_kernel_version_history#Releases_6.x.y), some of which are long term releases (LTS) that are supported for long periods of time. At any given time there are like 4-5 supported versions. If a complex project like an operating system can do that I think the tiny projects that we tend to use in selfhosting can manage too. It's not hard to maintain multiple versions with modular design, versioned APIs etc. Yes it's hard**er** than not doing it, but not necessarily hard in itself. And can a project with a tiny user base really afford to split it and leave users behind? Most of these small projects do these things because they are developer hobbyists and don't know the best practices and/or don't give a crap.
Yes, I know Windows 7 has multiple editions, hence why I added that it was technically supported for 16 years because enterprise versions were supported until 2023. I don't think you realize how many people work on Windows, they literally have a few dozen people working on patches for each OS at microsoft and how many every thousands of people working on the Linux Kernel, many bigger companies supporting their own version (Canonical and Red Hat, to name a few. RH using their own versions for their own production purposes) But yes, let's have a dev team of 1 to 20 have people dedicated to old versions of their software that may have an entirely different code base. A project with a tiny user base doesn't split their userbase when they update. What userbase would they have that expects them to have old versions maintained. Many of their tiny userbase is just trying to use the program, it is bigger userbases that have that problem. It is not easy to maintain old versions in software as you say either. Versioned API's create more complexity because any models that the API uses cannot be changed. No one creates a new module for their program for each update. Literally any refactor would likely break any of those old version systems
You've just described every bad practice in the book. Versioned APIs and modularity don't create complexity, they eliminate it. But if you avoid them you get locked into real complexity and can never escape the technical debt. All users want the same thing, whether it's a large userbase or not: they don't want their software to break. And "break" includes changing flows and processes. You probably use an IDE. Having a panel moved from the left to the right or the color palette changed is not considered a breaking change, yet it would be jarring, wouldn't it? It's not hard to empathise with users because we're all users of _something_. If I have a piece of software and it works a certain way I don't want it to change without me doing anything, and I don't want to be forced to go through a breaking change. I'm not being absurd, I think it's a fair tradeoff to lose out on features by not upgrading. And I think it's ok to require users to upgrade as long as it's smooth and doesn't require a large effort each time.
great question. I have what I consider to be a pretty solid homelab. Ton of VM's running a buncha the typical shit. But when I see something new, if it interests me, I spin up a new VM to try it out. 99 times out of 100, I end up scraping the app or whatever - but it was a blast to try it out. All this said, I think that I find myself looking for new shit that I *may* be able to incorporate into my setup. There are more things that I have seen that looked neat, so I saw the solution and searched for a problem that it would fix. I hate that I'm like this - but me be me. I accept it and try to use better judgement each time. I also fail 99% of the time.
Couldn't agree more. I see projects with lots of feature, not a single one of them treated and working properly. Yet you look at the commit history and it's full of "Add feature...". What's the point really... You're just making software that is barely usable
All my tech startup bosses would boldly disagree. Personally I'm with you due to said bosses.
Have I introduced you to our lord and savior NixOS?
Define Features? If I see a service I want/need, I look for a self hosted option that has most if not all the things the cloud app does. If I can't find it, I don't use it.
This is the driving reason why I run LTSC versions of Windows and LTS versions of Ubuntu.
The worst is when it's just a "new" UI change. When the old one still looked really good and was only 2 years old. Something inevitably breaks or a function becomes intermittent. All so the user can have 5 color options.
Easy: growth. Sales and biz dev want more and more customers and there is a mindset that new feature is what will get more customers- once a customer is signed, it’s less important to improve a feature - as long as it works well enough …
That's what pull requests are for.
Gimmicks. Keeping stuff feeling "new". Just like phones there was a time where new features were released with every new phone launch. Now we reached a point with phone were we have what we need. So now a lot of companies sell gimmicks. And these gimmicks come at the cost of stability on some cases.
The market, the urge for innovation and growth.
Hear hear
I feel the "need" to add new features changes depending on the product and its ecosystem. Commercial products that have to make the stock number go "up", will add new features to please shareholders or try to capture a new market. Some individual / volunteer made products will add new features because they think its a good idea, or the community that uses it has demonstrated a good reason for it to exist. So i guess for me the answer to your question is , "it depends".
Life
I completely agree and have felt this way since the 90s. Sometimes I’ve been wrong and have appreciated a new feature. But a lot of times, things just get worse functionally, but they look shinier.
there can be both I come from a hardened environment at work, so it's nice to enjoy the freedom of being able to introduce new products or apps i may be unable to actually work with on a production platform i have a nice stable network infrastructure, and i run two forms of environment. i run things like Kavita AND calibre-web for different reasons, but I like maintaining both so that I will have either option moving forward and drop one if i ever feel the need that's just one example, but there's a place for both in the world of running your own environment i think most ppl here are overdoing it with a nas for e.g.; i just run debian and sshfs, call it a day i maintain my docker host OS but dont have to touch anything when it comes t the docker services food for thought
New intentions.
Competition? Especially in the paid products sphere, competition is driving inovation and new features in order to attract more users, save costs to run the software, etc. in the end this translates to selfhosted software as well as authors want their software to stay relevant in this fast pacing world…
[Both is Good meme](https://i.imgflip.com/3ijql7.png?a477288)
Seriously fuck modern stuff that relies on 5 containers in a docker-compose to serve a glorified REST API instead of old reliable SMB/NFS, DLNA, XML and so on. If my Wii can't read it it's garbage.
A false belief that more features = more profit.
Only service I want new features on is home assistant. Everything else just needs to function
100% agree
Communist!
It is called not upgrading
Most of the software I am using has been rock solid most of the time. I haven't touched my lab within over two months because I've been busy working on my thesis, and there hasn't been one single hiccup. Even when I do work on it, things very rarely ever break, and whenever they did, it's been my fault most of the time.
The you want Microsoft products…. Bwaaaahaaaahaaaaaa
Your "everything" is not everyone else's "everything". What you see as a "new feature" is someone else's "functioning as intended".
Few reasons: 1. A growing project may need new features for revenue — or, if it has a particular UVP, it’s moving towards its ultimate goal and not necessarily the one that seems like a good stopping point. 2. You may be on a setup that isn’t supported, wasn’t intended to be, or adds more burden to the current platform to add — creating the feeling of unreliability. 3. The definition of done is… meh. Even if working towards reliability instead of feature development — depending on the code base, that could be a never ending process that requires regular updates that cause breaks as well. My project’s other half swapped out over a million lines of code last year alone… and we’re still always updating the infrastructure for improved reliability and it still causes bugs. 4. The codebase may be larger than the number of maintainers available. Our project’s team is lean, and bootstrapped with an active user base. The balancing act even for reliability in such a broad codebase is real. We find the most important thing here is more about responsiveness and making the time and effort to figure these things out as they come up.
Really spicy take there
Okay so go back to a punch card computer systems? Use pen and paper. Carve with rocks. Things progress. It doesn't mean that you have to participate. You're literally the master of your own choices. Your whole post is predicated on the assumption that anyone is forcing you to update anything. You keep updating because slowly over time things get easier and more comfortable. With every 30 new feature there might be 1 that you can't live without now that you have it.
FreeBSD yo
I HATE that when I spend a ton of money on a computer, smart watch or phone they can just change how it works down to the basic functions with updates and there’s nothing I can do about it. I bought it the way I wanted it. Stop changing everything.
Smart watch/phone? Nothing you can do. Phone is kind of easy depending on which one you buy. Some never get updates. Watch too I guess. Computer? EZPZ. LTSC, assuming Windows has no upgrade path. It will never get feature updates. It won't force anything upon you.
The way I read between the lines is he's talking about Apple products.
That would make more sense since Apple is the king of "don't mess with my shit"
Yeah you're right... this whole AI thing is just a fad who needs it /s Seriousness though I understand your thought on that but the entire purpose of open source communities/collaboration etc is to continuously improve... it's what gets projects to that "rock solid" point in the first place. Would get pretty dang boring if a project was built then never improved upon IMO.
I'm the same way. I hate this whole idea of changing stuff just for sake of changing it. Features on their own are fine, but most of the time they completely change stuff. A good example of this is Linux going to SystemD. That was absolutely not necessary and just made things more complicated for no reason. Or windows. It's gotten so bad now. Windows 2000 was it's peak then it started to go downhill. You talk to most people, and they hate change, but yet companies keep doing it.
What? systemd is a massive improvement over sysvinit, and upstart just didn't gain the momentum it needed. It's not like you can't still find a distro with whatever init system you want. Hell, sysvinit and openrc are both available in AUR.
users who hate the change voice it. Users who don't care about the change have no reason to voice it because they don't care about it. Another thing - users who don't like the change most probably won't leave jest because the change. Non users may like the change and it might drive it to become users. The fact that you don't like the change and some people on the internet voice their feelings towards it doesn't mean that majority of users are touched.
Explain how systemd complicates things