I disagree. I don’t subscribe to the idea that giving something away comes with any obligation whatsoever.
Almost everything I have coded on my own time in the last 20 years went to public repos on sourceforge/github/gitlab. That’s the default for me, since I want my work in a repo, and I want it backed up remotely.
I add documentation when I feel like it, i.e. when it helps me. I don’t feel obliged answering other people’s questions, but I try to help people when I have time. I also don’t invite pull requests, although I sometimes accept them. My code, my time, my rules. Works pretty well for me. YMMV.
Post the DT2 launch, I’m simply staggered by the number of pronouncements about what is and isn’t possible on the other hardware to match the new DT2 features elsewhere …
… by people who simply can’t know enough to know what’s possible and what is not.
Because the people who actually know work for elektron and are highly unlikely to tell us.
On some absolute level I agree, on the small scale I think people who have been involved with hardware and software development are generally saying how difficult it could be, which is generally kept up by the lack of results. When new firmwares come out or business priority changes, we will know
it honestly makes this board entirely unreadable surrounding a product launch, when all the arm chair embedded hardware engineers come out of the woodwork and begin arguing with each other about straight-up fantasyland nonsense
this is a bugbear of mine…
but what Ive come to realise is “It should be simple to code” , shouldn’t be taken literally …
frankly, end-users use its to some how justify , what they are asking should take priority / be done quickly… there is the implication, this request is ‘easier’ than others !
we see this all the time with bug and feature requests., in different forms.
other favourite ones of mine is…
“every other synth/sequencer has this feature”
“its 2024, how can it be done like this?”
again, the implication is… it should never have been released like this, it needs immediate attention.
so really, “it should be simple to code”.
is really just another way, of trying push an individuals ideas/agenda, in the same way, as users often try to get others to agree an FR is needed, to try to give the idea ‘weight’ .
as for, “that’d be hard to code”, yeah, im guilty of this… but I think often, this is just a reaction to the ‘easy to code’ being pushed so hard, that it gets tiring.
I try to avoid this now, but it is hard sometimes
this is 100% true… esp. as some have experience in the same area of product development.
and frankly, most of us that would utter these words, would usually prefix it with something like ‘but we dont know the code base’ etc.
however, honestly… the hard lesson ive learnt is. no one wants to hear it !
so you are wasting you breath, and potentially just creating an argument.
thats because, as I said above…
the phrase is just used to promote a viewpoint… and you saying its not true, is kind of just putting their idea down … which they will not respond well to.
as I said, a lesson I learnt the hard way… and also find a frustration, but it is what it is
People with experience in a team pulling something complex off needed to call on several persons’ life experiences and past failures to get to that point.
The “it should be easy”! Is the happiest path. And my goodness it should be! Never bespoilt by surprise.
People who say it probably won’t happen are calling to several real world times at which our projects were a misstep in under-budgeting, over-promising, hardware limitations and undocumented platform quirks, the refactor we don’t talk about in public, the one that drowned everyone, no survivors.
often this phrase is uttered just before finding out the true extent of the problem, and coming to regret these words.
on the flip side, we sometimes get the “this is going to be a nightmare”, only to find there is a quick solution.
you never really know in software dev, the devil is (always) in the detail !
Thank you for posting this. It succinctly summarizes a bunch of thoughts I didn’t have the time to communicate in a recent thread about Syntakt 2 vs upgrading the current ST firmware. I mean, on one hand those kinds of blue sky speculative threads are kind of fun, but on the other they’re complete wastes of time, and perhaps even slightly dangerous because they often create unmanaged, and typically unrealistic expectations, which may ultimately hurt Elektron (or any other small-to mid sized manufacturer).
Exactly! The former is a curse, the latter is a blessing
I think we’ve all been burned so hard ourselves by our own overconfidence or worse, bad engineering decisions out of our control, pushes by less grounded, more magical thinking sales/marketing/executive pet project, unglued client expectations to realistic disappointment in execution.
I work to avoid disappointment by grounding myself in what is most likely and if i get surprised, RAD.
Yeah, there’s fun, but the fun is tempered by the gripe loops people get themselves into, the crab bucket where people want to express their emotions but in ultimately toxic ways to themselves and reinforcement with others. Socially antisocial but not in cool punk ways
It’s sort of a microcosm of other reinforcement loops and not nearly as harmful as those, and it’s important to allow a little blowoff, I think it’s mostly important to figure out ways to keep that shit at bay internally and the volunteer mods here do a pretty good job at keeping it from getting unbalanced and negative.
I see these guys are also making pronouncements about how Elektron prioritise product development … sounds like they have insight into the product roadmap.
EDIT: I meant feature requests … guess it’s a given that bugs come first.
don’t remember where someone used the argument about using AI to “understand legacy code” or something like that, but funny enough, NetBSD and Gentoo banned any of that stuff calling it “tainted code”, so, if Elektron follows this train of thought I guess “understanding legacy code” might not be such an easy task.
Do not commit tainted code to the repository
Code generated by a large language model or similar technology, such as GitHub/Microsoft’s Copilot, OpenAI’s ChatGPT, or Facebook/Meta’s Code Llama, is presumed to be tainted code, and must not be committed without prior written approval by core.
Way to get out ahead of the problem! I respect the game here. The AI tools can’t replace programmers if you defacto state that AI-produced code is tainted and therefore inadmissable to the repo. Guaranteed job security from AI
I think it’s more aimed at making sure the code written/merged is under the correct licensing. Open source licenses can be a huge PITA, many of them are not compatible with each other, and code under less restricted licenses suddenly containing merged code from more restrictive origins ”taints” the code base with the more restrictive license. If you then have proprietary code depending on that less restrictive license and suddenly the less restrictive license is no longer applicable you have massive problems with the proprietary code
Edit: that would actually track in the music world as well, if AI suggests music that is influenced by AI consuming music not properly licensed you are up shit creek
this one small developer working on the Electrosmith Daisy embedded platform made their code available, It Should Be Easy to open source every embedded platform and the proprietary DSP code of each chip. something something monome Norns
also if you do that someone else should update the firmware for me, that should also Be Easy
also if you could notate your entire codebase, toolchain, and any build environment sub-tools for outside readability, that’d be great kthxbai!
i do think it’s great when people are able to and capable of sharing this stuff with the world.
but dreams and expectations get pretty fucky when someone injects their not really valuable opinions on the myriad of reasons why people don’t do this*, especially with a product of great complexity. and the expectations of active engagement and support are not grounded either…
It’s an interesting sub-set of GAS for gear people already own. They want alternative firmware that doesn’t exist, that they fantasize will pop into existence… over actually using what they own for what the gear does, today.
It also unsurprisingly burdens others with the tasks of doing the work they generally aren’t capable of performing.
*as in they’re dumb, they’re lazy, they hate baby jesus, they’re so ENTITLED! they should be more anti-capitalist, like Uli! commercial products should all be designed ground-up like FOSS, and if they weren’t, they should be dismantled and ground-up rebuilt for me
