It's a bit of a sour article but it rings so true... We let Open Source take the mantle in companies which are mostly free loaders and churn closed products, or even worse have them closed and DRM protected. There's really quite some work to still realize the Free Software goals.

Some relationships here are definitely shady. Be careful who you trust with your traffic.

This is indeed an open question. Looks like it has the potential to lead to interesting boards in any case.

Definitely a good move to have more sustainable income for Mastodon.

Looks like another certification circus is about to begin...

I felt that a bit the past couple of years when looking how the ecosystem evolved. The situation seems concerning to me.

This is one way to frame it I guess. Code is indeed an investment, tests are here to protect it.

I'm not sure this dichotomy is enough for building a taxonomy of FOSS projects. But I guess it's a start and captures something often missing in other such attempts.

Just another hype cycle... The developer profession being in danger is greatly exaggerated.

If you expected another outcome on the average developer job from the LLM craze... you likely didn't pay attention enough.

If the funding dries up... we'll have another AI winter on our hands indeed.

Interesting point of view. I'm not sure I fully agree with the classification but it gives something to mull over. For sure the less reliable your estimates the more padding is needed to have some predictability.

Or why estimates need to happen in one way or another.

There are indeed cases where you don't want to hurt your reputation...

It looks like desperate times for the venture capitalists behind the AI bubble...

Or why I really hate the whole certification business. Especially for process and practice's related topics, this pushes the multiplication of brands and churches to sustain them. The right approach is almost always a blend of different influences and flavours.

When hype meets group think, you can quickly create broken culture in your organization... We're seeing more examples lately.

Developers tend to push for pair programming mostly for technical and code quality reasons. This is fine, but often the fact that it also spreads knowledge and ensures business continuity is forgotten.

I willadmit it... I laughed. And that's just one business risk among many.

This matches what I see. For some tasks these can be helpful tools, but it definitely need a strong hand to steer them in the right direction and to know when to not use them. If you're a junior you'd better invest in the craft rather than such tools. If you got experience, use with care and keep the ethical conundrum in mind.