I'm so tired of it all. Countless times it has been tried to enact laws like this. And it's not just this surveillance law that depresses me, reading up on the cyber resilience act just feels to me like it will suck even more fun out of software development, at least in a professional context.
We just have to get used to this being an eternal political fight. There will always be politicians with a desire for control and/or a lack of technical understanding that will try to take control of people's communication in this way.
I guess the best way to counteract this is well funded institutions whose purpose it is to fight that fight for us. I'm using this realization as an occasion to make a donation to the EFF.
> And it's not just this surveillance law that depresses me, reading up on the cyber resilience act just feels to me like it will suck even more fun out of software development, at least in a professional context.
God forbid people who love to use the title engineer will have to apply the rigour and standards of actual engineering to the work they do.
I had a horror of meeting some. Those can be, basically, put into two categories: 1) completely brainwashed (engineers aren't immune to that, unfortuntely), 2) drowning in regret and alcohol (being hostages of the situation).
1) There are a lot of people doing engineering without a degree. One example: many makers are not engineers and they do a lot of good stuff anyway. What they don't do is taking legal responsibility because they are not allowed to. It's no warranty / no fitness for a purpose stuff. Similarly there is a lot of software with no warranty / no fitness clauses. History demonstrated that it's good enough to keep the world spinning.
2) Most people in the software industry do engineering jobs no matter if they have a degree in Computer Science or Software Engineering (I didn't check the USA name for that, sorry) or in anything else. I know very good software developers, maybe with an architect / engineer job title, with no degree at all or with a degree in Graphic Design or Philosophy or Agronomy. They moved to software development because they tinkered with their computers, wrote some programs and discovered that they are good at it. Nobody notices the difference after 5 or 10 years of work. The only downside it's a little narrowness of expertise: they have many more unknown unknowns because nobody systematically told them what's there outside and how it works, even at high level. One example: that good software developer with the Graphic Design degree told me once that he doesn't really know how networking works. To him it's the configuration screen of his Mac and HTTP calls from Node.js.
> If software dev had been licensed and regulated this way we’d have only a tiny fraction of what we have now in terms of languages, OSes, tooling, etc.
It's starting to sound like a very good idea.
> There are specific areas where it makes sense but doing it broadly will just halt all innovation.
Or speed it by focusing efforts on well designed software.
Yea, like the Windows 9x days. The best days ever, for sure. The best days for a fucking disaster and a collapse of the Western economy in a matter of days if you suggested that turd.
This isn't in relation to either the chat control law or the cyber resilience act, I haven't read either proposal in enough detail to have a strong opinion on them. But I want to comment on the "sucking the fun out of professional software development" part.
Should we expect professional software development to be fun? There's a lot of laws out there which arguably "suck the fun out of" civil engineering, but I certainly appreciate the fact that there are standards in place to try to keep bridges, tunnels and buildings from collapsing.
Maybe it's not the worst idea in the world to have enforced engineering standards for the digital built environment like we have for the non-digital built environment, and treat it less like a playground where programmers can do whatever they want?
Just a thought, I don't have very strong opinions on this topic.
> Maybe it's not the worst idea in the world to have enforced engineering standards for the digital built environment like we have for the non-digital built environment
If you're building infrastructure control systems, sure.
But for software that "enable human-to-human communication"?
Do we have engineering standards for printing out pamphlets, teaching foreign languages, inventing board games, writing a song?
Obviously the standards should be in concordance with how critical the infrastructure is. I thought that went without saying. I'm just trying to ask if we should expect working on critical infrastructure to be "fun" and not burdened by regulations.
Yea, I wouldn't have a problem with that regulation if it would be applied to only these critical areas. But it seems that they want to apply this directive to all software that's sold in the EU.
To be fair, I haven't read the actual draft, just read some reporting about the implications for open source software.
If you were a big corporation who doesn't want to buy a license but speed up dev time, couldn't you just let your devs use mold for development to have faster recompilation cycles, but link the official binaries with some other, slower linker?
Honestly I wish there were mail, calendar and contact apps for other systems, as good as apples with solid webdav/caldav support. Thunderbird is kind of lacking in all aspects.
> As a user, I can't think of anything more frustrating to spend hours or even days on an issue on an open source project that "welcomes" issues and contributions and then creating a detailed GitHub Issue only for it to be responded with with author's "No" and immediately closed.
The article also discusses that. Of course there are better ways to do this than just closing it wihtout comment, even though the end result is still saying "no" to it.
I have open-sourced a library that I wrote for an in-production app at work, and it got a little too popular for me to handle like most open source "consumers" (even though they don't pay me) expect.
Every time there's a feature/pull request, I not only have to think about if the code is correct, but also if it would introduce breaking changes in the way it is used in that production app.
It's very mentally draining to visit the issues page of that repository, because it's full of people needing help or wanting to contribute work. But I can't handle them all within an acceptable timespan.
Every few months I take half an hour to clean up there, and then the issues list is already filled with disgruntled users.
> The response to an issue of "contributions are welcome" or "you can fork it" are inappropriate because the filing of an issue is not a request to fix. It is an issue reporting mechanism. But too often, maintainers become chippy about reported issues.
I agree in hindsight that it probably would've been better to just turn off the pull requests feature when creating a repository if you can't commit yourself to the potential workload it creates.
> Saying no is fine but please be honest and upfront on a repository's README. If someone says "this is open source but it's mainly a personal project and/or library and I will aggressively close issues", then that does wonders to set expectations. And I think that's the key idea. Setting expectations, upfront, is the key to effective communication.
Most of the time you don't realize that you really can't handle all that workload when you're still in the "honeymoon" phase of the thing you're open-sourcing. What are you supposed to do when it gets to the point where it's just overwhelming you to even look at the issues list?
> > As a user, I can't think of anything more frustrating to spend hours or even days on an issue on an open source project that "welcomes" issues and contributions and then creating a detailed GitHub Issue only for it to be responded with with author's "No" and immediately closed.
> The article also discusses that
They mention that but they don't really discuss it, and I disagree with the conclusion and advice.
GitHub allows disabling issues altogether. Just do that snd save everyone trouble.
> What are you supposed to do when it gets to the point where it's just overwhelming you to even look at the issues list?
My thoughts are my overall opinion and approach: clear communication. Just update the README, appropriately comment on issues that are closed as a result, and maybe even disable issues.
This is slightly off-topic, but reading your responses on this thread just rub me the wrong way. You're acting like you're entitled for open-source devs to support you and value your contributions for the sole reason that they might put a line on their resume?
As if you had the right to be angry at somebody just because they had the audacity to open source code and struggling with maintaining it.
Of course it is simple to say "communicate this clearly" in hindsight. And I kind of did that. Still there are users who expect more from me than I can give.
Yet again, I have not once indicated anger (what?) or entitlement. Yes, I have been frustrated at unclear communication, and I do not consider the expectation of clear communication to be entitlement.
I am moving towards open sourcing some projects (already have), and I am trying to think about this myself. I have not landed on a solution I am happy with or even followed my own README advice, yet. In my experience, it is very pleasant to work in repositories that set good expectations with clear communication. But it has been frustrating to interact with a "contributions welcome" repository where issues are swatted down like flies, especially when the reporter offers to debug and even help contribute a fix. I just stop going there, and I would have preferred to just have such culture be clear upfront.
I have even started considering offering paid support for important issues to be fixed, and I am trying to take an active approach in contributing to projects I like using, so I really don't think I approach things as you imply.
Edit: Also to be clear, I am not speaking to anyone specifically. These are general sentiments.
I would love to use the open source alternatives to Lightroom, but I find the cloud offering too convenient. The photos are available from everywhere, even on my phone I can import photos directly from the SD card and start doing light edits. When I arrive home, all the photos have already been copied to my computer where I can finish the project on the big screen.
Is there something that approximates this "effortless" experience using some cloud service and the freedom to use whatever software to manage and convert the photos?
I keep all my raw files in git-annex. I wouldn't say that it is effortless, you need to have a good understand of git, but if you do, it works really well and is extremely flexible. Raw files go in git annex and sidecar files (XMP, PP3) go into git itself.
Portability has become a challenge for me in darktable (which is my only choice in photo-editing).
My archive is now large enough (~8 TB) that it is impractical to carry around. Keeping edits synchronized between home and remote is hard. Darktable's internal database doesn't play well with remote edits, either. It's tricky.
I'm convinced that there is a simple/clever solution to the problem using existing tools (rsync/git/google drive/etc), but it will require someone with a really solid understanding of Darktable's inner workings and data-structures to prevent corruption of the database/library or, worse, the archive itself.
Yes. I love Lightroom for that. It's very convenient and approachable. I think the dealbreaker for me for not using RawTherapee/Darktable was the performance. Lightable or Capture One are way more snappier to work with. You see results as you change things. Which is really important when I'm editing bunch of photos at once.
Right now the "Alte Elbtunnel" is undergoing maintenance in one of the two tunnels. Since as long as I've lived here, it hasn't been open to cars, but the large elevators previously used for cars are still serving bicyclists and pedestrians during the daytime. They get quite full during rush hour.
