Definitely something architects should do more. Understanding the business needs should be the input to the technical decisions. Otherwise you might just happily build the wrong thing.

I wish more product companies would pick this license. Going for AGPL with a support and/or double license offering is a strong model in my opinion.

It's bloody hard to build a strategy. This article is full of good wisdom to make one. This won't make it really easier, but at least you won't start in the wrong direction and will be able to know if what you produce is any good.

Definitely this. Managing expectations is a big part of management. It's also important for customer relationship. In both cases, clear communication and finding misunderstandings early are key.

Unsurprising trend... this was a market where there was no chance to have a single dominant platform due to the existing studio behemoths. So now we're in the streaming wars, people can't afford to pay for every silos... and they turn to piracy again. Could have been all avoided if we went the "global license" route instead of dumping money on platforms.

Unsurprising move, they claim it's for the betterment of mankind but in practice it's mostly about capturing as much market share as possible.

This is a stupid move on Unity's part... they're built on LGPL but ban others in their store to have LGPL dependencies. Shame on them. Good move from Videolabs though, wish them lots of success.

That's a very good question. What will be left once all the hype is gone? Not all bubbles leaving something behind... we can hope this one will.

Good point on why you don't want to drive your organization simply on RFCs. Yet another fad of "this worked for them, let's do it as well"... per usual this fails to take into account the specificity of the context where it worked.

Interesting food for thought. The later point about the tension between business and users lately is also a good one and should be kept in mind. That's an ethical concern you find most in companies publishing Free Software though. It's not the full packaged solution but a good starting point.

There will always be some design and some testing. The intensity of both activities needs to be properly managed over time though.

Very good review of the McKinsey paper about developer productivity. It not only highlights all the problems with it, it also makes suggestions to make a better paper next time.

Interesting approximations to get a feel of how much a cloud project will cost.

Unsurprisingly after people massively converged to two main closed source engines for their games, they start to be massively screwed over. Maybe it's time for them to finally turn to Free Software alternatives?

I'd take the more stack related side of this article with a pinch of salt. It seems a bit too specific to the company behind the story. The rest of the article rings true and spot on though.

And now the part two, with more warnings about what you measure. Also proposes a few ideas toward the end.

Excellent piece. Be careful what you measure. If you measure the wrong things people will game the system.

More thinking gets around the debate about tech debt. This is definitely welcome. Using more precise labels can indeed being clarity in conversations.

Clearly very much inspired by the science peer review system. Having experienced it, indeed I wish more business decisions would be made that way.

Very good advice. Don't waste time believing false business claims and trying to replicate them. Easier said than done though, most people don't have the privilege of insiders knowledge.