Am I the only one thinking continuous deployment should be expected on firmware releases today?
There are so many feature requests and possible also some bugs that needs to be fixed, and it takes ages between every firmware release. Why not make the firmware opensource or at least practice continuous deployment?
It should be possible to do more frequent release with small improvements.
Just my thoughts 
/Martin
Hmmā¦quantity over quality?
Iām all for devs taking their time.
So we can have B clones for a fraction of the priceā¦ Great idea ! #mutable
Itās not something I miss.
For some products it definitely makes sense. But for something that is more or less hardware-based, I donāt think frequent releases is - or rather should - be needed.
/thomas
Iād appreciate it if more companys would consider making firmware code open source on discontinued products (likely wonāt happen), but for current product lines, no. Iād rather have more companys take their time to ensure a good and stable product hits the market, than several half-assed attempts by hobbyists to improve code which get abandoned sooner then later.
Also not every feature request makes sense, thereās usually tons of them, yes, but you gotta maintain balance between what you can squeeze in gear and what would make sense having in there and provide a good UI and UX.
Arenāt we missing something here ? Continuous deployment assumes thereās an automated test suite of regression tests. Iām not familiar with hardware/firmware development, but it wouldnāt surprise me at all to find that some regression testing can only be done manually ā¦ leading to slower deployment cycles.
Iām pretty sure you can still have continuous integration on firmware build using unit tests
Also Iād actually say we need the opposite, good, stable products on release and longer product life cycles in general.
But obviously itās a jungle out there, new products hitting the market in rapid succession, how you gotta reach customers and stick out when everyone is breathing new stuff to buy?
Toughā¦but all that new shit must be coming out of peopleās ears already, no?
Hmm - I canāt remember the manufacturer. But I remember seeing a video from a german audio-tech manuafacturer. They had fantastic test-automation.
The mainboard was mounted in a testrig, and they had automated testing on both a component-level as well as high-level functionality.
Consider that getting getting hardware returned from customers is very expensive and time-consuming. So it makes sense to really test everything.
/thomas
Fair enough ā¦ Iām not familiar with firmware/hardware development. But would you be happy being responsible for a product and continuous deployment of firmware without some QA over the whole thing ? The āwhole thingā in this case meaning turning some knobs and pushing some buttons.
I guess itās possible.
EDIT: Ah ā¦ I see I overlapped with @synthbie
To make Continuous Deployment work you need great automated testing, and the ability to roll back instantly if something goes wrong.
Testing hardware is tricky, and rolling back when you donāt own the hardware itās deployed to would be interesting.
And there is usually a lot of inertia to overcome to change to a CD process, especially if there is one dev team currently switching tasks between all the different products Elektron supports at once.
I think itās easier said than done.
And much as I love open source, I donāt see how Elektron could stay in business that way. Their hardware is nice, but not nice enough that it could support the whole business.
I donāt. Assuming an instrument is released with the features announced and free from bugs, I never expect a single update after that.
In reality, hardware isnāt released with all features announced nor is it bug free, but thatās where my level of expectation is. That some go out of their way to update and sometimes change the instrument through firmware is a fantastic icing on the cake that certainly sets some apart from others, but itās never something I presume.
You got Synthstrom, Novation and Elektron in the update corner, setting the standard for what new firmware can provide. You got MFB and Sequential (mostly, and not counting the Tempest) in the other corner, and their instruments are equally great for what they do, updates or not.
Iād say we need good, stable and feature complete products from day one. Generalizing continuous deployment in music instruments will only lead to more incomplete machines being released and later abandoned.
hardware isnāt released with all features announced nor is it bug free, but thatās where my level of expectation is
I couldnāt agree more. The software dev mentality in hardware stuff has spoiled too much stuff already. Alsoā¦ #Overbridge ?
Make the firmware opensource is not really interesting if the company is not willing to provide good (and free !) developer support (tooling, documentation, etc). That costs money.
Yeah, thatās what I meant. A good, stable and feature complete product should also lead to longer life cycles, no need to release product after product after product to stay relevant.
I find this cycle of half complete products and constant firmware updates/requests entirely fucking annoying. Iām really moving away from gear that sits in this model and more towards things that are pretty much the finished article on release. Theyāre musical instruments, not mobile phones.
I understand that things can be improved and that itās nice to add cool new features without having to package them in a new product, but it creates too much expectation and entitlement, too much thinking about what we want, not what we have.
Knee-jerk response here: I def donāt want this. CD is fine for web software, in which the user is largely unaware of the āinstallationā process (downloading and running in their browser). The browser creates a sandbox around the software, limiting its interaction with the OS. Fixes can be delivered quickly, features tested (users experimented on) etc.
Hardware (what firmware operates on) is the basis of the running machine. If the developer makes a mistake, that could hose the machine. CD promotes short release cycles: no matter your workflow, bugs creep out.
Also, itās in the name:
Hard: almost impossible to update
Firm: difficult to update
Soft: easy to update
Personally, I want my hardware to work for months or years, completely disconnected from the network, before thinking about updates.
Yes, apparently
I think we only tolerate it with mobile phones because we would pay ongoing costs for the connection anyway. The handset cost just slips into the monthly outgoings alongside something we canāt argue with.
Imagine if your washing machine, oven or air con needed upgrades? The horror!
Well, as already stated above, the term continuous deployment doesnāt fit in this context, because Elektron has no control over the hardware for automated deployments/rollbacks (+ automatic detection if a deployment is bad / not just wait for users complaining).
In this case it would be a kind of ārolling releaseā mechanism, which is an absolutely pain-in-the-ass for development, support and the user base.
Iām not sure why some of you think that Con. deploy/deliver/release == bad quality?
Of course everything should be properly tested before a release - so letās start by agreeing on that term
And it is possible to structure the firmware to handle updates more like an app on your phone - so rolling back etc. is a lot easier and prevent you from bricking the device.
About finalized products from day one - I think that is a good thing, though unrealistic. We have seen a lot of HW devices the past years, which has benefitted from firmware updates over the years. Adding new features, demands and requests that was not identified on launch time.
I do agree that a pitfall to avoid is the release of unfinished products, at we see it on software especially in the game industry.
And I disagree that hardware today has to be hard to update. You can do it very smoothly today. You just have to structure the firmware container to handle this more smoothly than you would this 20 years ago. And companies do.
Thanks for all your thoughts on this subject. I think itās interesting to hear all the different perspective on this matter
/Martin