Cost? It's a freebie. I'm still doing my tasks, in addition to saving them tons of money with better tools.
Creating new work that wasn’t in the roadmap (excluding tech debt and other necessities to get roadmap work done) is a problem.
The right way to grow is to learn how to work with the company to get important work into the roadmap.
I’ve worked with some peers who had good ideas and good intentions, but they’d unintentionally try to blow up the roadmap and reset planning by prioritizing their work over the things we needed to get done.
Working with the business to get things prioritized is a necessary skill. A lot of engineers just want to work on whatever they want to work on most, but that’s a problem in the context of an organization trying to coordinate.
I am not talking about creating additional work, I am talking about solving problems not on management's radar screen. Some problems are only visible from the floor.
> The right way to grow is to learn how to work with the company to get important work into the roadmap.
That is not always possible because valuable things sometimes have to be demonstrated to be understood. Not all things can be explained in the abstract, sometimes you have to build the thing first before people understand how useful it is.
May be it's actually a management challenge to turn this enthusiasm into money?
What's a problem for one person makes an opportunity for another person.
The existence of this thread belies this. Running everything like a product is the fad today. It’s a fad because running a “product” means understanding its lifecycle and resourcing it as appropriate. But the mandate in BigCorp is to run printer ink fulfillment with the same methodology as an actual product, so lots of leadership time is spent thinking about toner or whatever.
It’s inefficiency created in the pursuit of efficiency via control.
Kind of a big problem here, as you're defining the right way as also the way that frustrates you (and assumingly others) the most.
You probably also write obtuse, impenetrable code to prove how clever you are — with a growth mindset, of course. Wouldn’t want anyone to maintain it later.
You just made a bunch of things up.
When things break u can say that u have already had this discussion and it was not ur responsibility to fix it at the time
That's what's missing from Graydon's analysis: risk-aversion is also a strong incentive in many corporations. I would argue it's the rule for middle managers, with growth being the exception.
Also missing is telemetry and coordination, where companies use FOSS to find out what other companies are doing, or to coordinate policy, esp. when they fund a leading contributor from whom other companies need buy-in.
Put another way, a FOSS contributor is not an individual, they are a company representative, and their opinion has the weight proportional to the companies' influence.
The contributor's influence also depends on the composition of the other contributors. Alternate influences become impossible when a company dominates the contributors; hence e.g., the CNCF tracks metrics for ensuring that it takes a plurality to dominate.
But really this posting isn't about FOSS contribution at all; it's about the under-valuation of avoided future costs. But that's a much harder problem, because you get all sorts of illusory accounting when people project potential costs they're avoiding.
E.g., I um heard that at (big firm with ~1000 developers), the QA team was successful arguing for additional funding because they were finding more bugs. So the kernel team started tracking edits as fixing potential bugs, to restore the balance of funding. They hated the game, but had to play it.
In my field (fin tech) managers often do not have the background to be able to assess spontaneous technical contributions. So they assume that if something was not planned and requested by management it did not need to be solved.