KDE devs & other hobbyist programmers, beware: some "captains of industry" see you as a threat to their business models
KDE devs & other hobbyist programmers, beware: some "captains of industry" see you as a threat to their business models
Posted Jan 26, 2024 23:09 UTC (Fri) by kleptog (subscriber, #1183)In reply to: KDE devs & other hobbyist programmers, beware: some "captains of industry" see you as a threat to their business models by rqosa
Parent article: Jujutsu: a new, Git-compatible version control system
Just a small addition to your comprehensive response.
The real deal about the Employee participation in Germany is the workers council, which has a lot more power (They have co-decision or veto rights on things like including, but not limited to: work time, measues controlling workers, worker protection, (Paid) time off rates, firing of employees...)
They're actually called Works Councils in english and exist in many European countries, though they are the strongest in Germany. There's even a Works Council Directive. CxOs in English speaking countries have a hard time distinguishing them from unions but they have distinct roles. The Works Council represents the workers in the business and the goal is to improve the running of the business whereas unions are more focussed on the workers. From personal experience being on a Works Council having to decide whether to approve the firing of a significant number of colleagues to save the business is no fun at all. And that's just in the Netherlands where they're not as strong.
99% of the benefit of a Works Council is the mere fact that management actually has to motivate their decisions and it's surprising how many CxO-level decisions have no more motivation and analysis behind them than fits on a back of a postage stamp. Getting more than a slide-deck the first time round is rare. Once management can actually articulate what they want, the proposal is almost always a good idea.
As an aside, people seem to confuse the terms liability and responsibility with respect to the CRA. When it comes to fixing bugs in Apache, of course the Apache Core Team is responsible. No else has commit rights, so no-one else can fix them in the Apache source. That's different from the responsibility of a manufacturer to deploy any fixes. And completely different from liability which arises from the breaking of specific promises. The CRA is not about that your product in 100%-bug free. That's not possible, just like 100% error free hardware products don't exist. What matters is the process behind it: preventing, finding, reporting, fixing (security) bugs and deploying those fixes. All of which have had well known "best practices" for years, we just don't do them.
work turns into a never-ending barrage of "oops, it's 5:30 PM, but this problem we discovered at the last minute, and you must fix it TONIGHT, and stay up all night long working on it if necessary" demands from bosses!
I'm so glad I've never worked in a place like that. I can't be held to deadlines that I did not agree to. If I gave a deadline and got it wrong, that's on me. But more often it's: that sound you're hearing? That's the sound of your deadline flying past. I honestly don't understand what motivates managers to give deadlines without asking the people who have to do the work if they're even feasible.