Interesting ideas on how mentorship can be organized in a company. This is obviously examples coming from a specific context but still, the whole time bound and matchmaking approach is a good food for thought. It sounds a bit too mechanical and systematic for my taste but I guess it makes sense in their context. A few good extra resources provided as well.
Very interesting approach using code of conducts to fill the gaps of the pure license approach limitations. Indeed focusing on licenses only lead to the Open Source movement which is so much business oriented that ethics is completely overcome (there's so much you can do with licenses after all). This proposals using code of conducts (internal + external) is thus interesting to make proper commons. The question of how much of a deterrent and defensible from free loaders this could be is still open though.
Interesting take on why the Open Source movement is a zombie movement and why Free Software failed at the political level. This explains why we see a rise in the "Post-Open Source" term. This leads to potential ways out. It's a bit too much on the heavy marxist reading to my taste but otherwise it contains good criticism
Long and comprehensive description of how a tiny studio manages to work complete offgrid while traveling. Interesting tips to cherry-pick from.
FR: Après tout, jusqu'où un employeur devrait aller pour financer la mise en place du télétravail? Cet article en français donne une bonne idée des coûts et vraiment cela ne semble pas aussi coûteux pour l'employeur que ce que l'on pourrait supposer grâce aux économies sur le fait que l'employé ne soit pas dans un bureau.
EN: After all how far should the employer pay for remote working setup? This article in French gives a good idea of the costs incurred and really it doesn't seem as expensive to the employer as one could imagine due to how much is spared by not having the employees in an office in the first place.
Overall good piece about how to make quality software. That being said the whole section about "Hire the Best Engineers You Can" should be read with caution... it clearly starts from the "10x coder" fallacy, it's not true and suddenly completely ignores the project context.
Good exploration of what "engineer" and "engineering" means. Also helps to overcome what software people like us assume is done by the "real engineers" while in fact sometimes they can be as sloppy than us.