See the posting on oss-security for details:
2 Likes
Anyone have any personal lessons they took from this?
- autotools is a liability
- Complexity should be minimized at all costs (e.g. in dependency trees)
- Tools should strive towards a state of completion where the maintenance burden is negligible
4 Likes
In the wise words of Rob Pike: “A little copying is better than a little dependency.”
1 Like
Technical solutions non-withstanding:
- maintainers, make sure you have friends to share the load with (sometimes easier said than done), or at least that give you moral support.
- others, when you see a project which seems to be handled by one person, ask how you can help.
- everyone, learn to recognize and handle bullies.
Essentially, we need to care for each others as humans, with emotions and all. Being along is very tough.
Note: I understand how item 2 above can seem difficult in light of what happened. However, this is a fairly unusual case in that regard. Humans relate with each other all the time, and lean on each others when morale needs it. Being alone is not the answer.
1 Like
I think both @ddevault and @levitte have raised excellent points in this thread. As have others around the net.
One point I haven’t seen raised all that often or all that well is best encapsulated by my username itself both on here and many other places. Namely that if you’re thinking in code or even throwing around terms like source code you’ve already lost the game.
The word code can mean many things in theory. But in practice it means cryptic, inscrutable, and obfuscated crap.
Like even in scenarios where I knew both the programming language and problem domain at hand very well I’ve often had difficulty reading other people’s code. Sometimes I simply couldn’t figure it out. Other times, when I did figure things out with a lot more effort than should have reasonably been necessary, I was absolutely furious at how badly what turned out to be relatively simple underlying ideas behind the implementation were expressed.
In large codebases or codebases where other colleagues expected a certain structure I had to mostly just live with it. But in other cases I was able to either drastically refactor or alternatively produce a much smaller, cleaner, simpler rewrite with equivalent or better functionality.
Getting back to my main point we’re so used to code being cryptic we don’t bat an eyelid at it. Doesn’t matter if that code is correct or buggy, innocent or backdoored. And therein lies one of the big problems. A lot of stuff is simply too unclear even for seasoned domain experts to meaningfully review positively, negatively, etc.
Unlike natural languages computing languages have better defined (even if still often unclear) semantics and used right can often be a superior way to communicate ideas even if the only intended audience/consumer is a fellow human. Yet we squander this opportunity for good communication of ideas in a multitude of ways.
Some problems are almost superficial like poor naming. The stuff that passes for Open Source and Free Software is horrifying to me. Like there is almost no way the cryptic variable names I often see in codebases are how the actual programmer thought of the concept represented by them. What kind of openness is that?
Another example of problems is due to abuse of powerful language features. For example even in languages that have good type inference I still usually write the types out explicitly and strongly encourage others to do likewise for me. The compiler is smart enough to infer the data type of some object? Good for it. You’re smart enough to infer the type of some object? Good for you, sweetie. But the rest of us aren’t, and it’s not right for you to exclude us from understanding the system. (Also sometimes neither are you and the type your compiler will infer may be quite different from the one you intended.) If you know the type write it down. It’s wrong to withhold knowledge.
I could go on but you folks get my point.
When I was studying programming one of the languages I explored was Ada and I saw something in an Ada tutorial at Ada Programming - Wikibooks, open books for an open world that has always stuck with me since. Initially subconsciously, eventually consciously. Key quote:
“Some Ada programmers are reluctant to talk about source code which is often cryptic; they prefer program text which is close to English prose.”
We have to stop coding and start programming. Neither code nor coders have any place in FOSS.
2 Likes
@makesourcenotcode, I couldn’t agree more. However, I see that as an issue that goes across the whole industry, not just in FLOSS software.
Seeing to the topic of this particular thread, that discussion deserves a whole other thread of its own, wouldn’t you say? I’m pretty sure that will become another - and not a little interesting - thread on what culture we foster collectively.
I recently read this article, which I think makes some good points about the need for social infrastructure and why paying maintainers is an insufficient response (even if it is a necessary component of our response).
2 Likes