There is stuff which can be test for software with CI/CD and there is stuff which can not.
For example lots of software related to hardware stuff.
So on my side, I really preffer that developper has time to release FW, and keep this soft as closed source. Then do things which matter for them to feel good and deliver good quality. Pretty sure they have thinked about opensource, and opensource is definitely not for everything and every product. It’s not something which solved all problem. And there is some part of the code, that you don’t want to be published, because they are in “house stuff”, and there are horrible thing that you don’t want anyone to see.
And I preffer to know that there is 20 FW around with FW 1.34B which has this issue and 1.35 which fix it. It’s a lot easier to follow as a user.
I’m using opensource software everyday and I like that. But I also like closed source stuff.
Both have different quality and having both is better than just : release everything, specifically in the audio stuff.
I live in France, and here the national train company deploys regularly upgrades of the phone app.
They release too much upgrades in short time, and most important: no retro-compatible.
I regularly have to upgrade this app if I wanna use it, most of time just to check a train schedule.
It gets me tired and bored to have to spend too much time to upgrade apps on my phone and computers.
Once upon a time some people said “Agile method is the future”.
Many companies followed this without a real reflexion, without thinking if Agile, and CI/CD concepts can fit their business. But they don’t give a sh…, the new numeric fake prophets said this, so let go !
Now their business get reaaaaally slow because misunderstanding of these methods and concepts, Other methods would better fit to their business, but they don’t care, “being Agile” is the new trend for some years in France now.
Agile method, CI/CD, can be very powerful tools, in some specific cases, for specific businesses.
But I honestly don’t think it can be an improvement for the hardware music stuff. It would be more focus-killing than anything.
There is also the rule of not breaking the APIs, i.e. add new features but do not break the existent ones. And in this case, it’s much worse because it’s impacting the final users, which is never a good idea.
The thing is that there are a lot of good practices. Following just one doesn’t imply quality but the more you try to adscribe to, the better. At least theoretically, because the way you actually implement them is definitely the only thing that matters in practice.
The only way I see more than sporadic updates happen, is through automatic download and installation of firmware updates directly by the devices themselves. Which opens the door to all sorts of security and privacy issues because those devices would need a (semi?) constant internet connection of course. There’d be usage analytics, devices tied to user accounts (only for preset sharing and backup, surely) and sooner or later business models with cheaper hardware maybe but regular payments to keep it all running. Because software development is expensive.
The current situation of devices getting major new features sometimes many, many years after launch is an incredible luxury. It should not be expected at all! (IMO) Because if we (as customers) take that for granted, the manufacturers will at some point need to figure out a way to monetize those updates. The current trend everywhere are monetization models based on either subscription or exploitation of user data (or both). And I don’t want musical hardware instruments to play any part in that.
continuous delivery is great for web based services but for potentially brickable hardware devices which contain all my precious un-backed-up projects? no ta!
although i’m all in favour of faster-turnover beta programmes for people who want to live life on the edge…
This is so perfectly explained!
We have to remember that, as consumers, we have some power, so we have responsibilities (don’t know if this word is ok in english).
That’s why we should not ask for methods and concepts that do not fit in contexts they do not belong
