I don't know much about Igalia but they are worker owned and I always see them work on high skill requirement tasks. Makes me wish I was good enough to work for them.

This seems to be a win-win where developers benefit from more work in niche areas, companies benefit by getting better developers for the things they want done, and Igalia gets paid (effectively) for matching the two together, sourcing sufficient work/developers, etc.

Just because work is 'out-sourced' to contractors does not mean it is a sweatshop....

It's a cooperative sweatshop in that sense.

And the developers own Igalia.

Their games and systems tie into huge gambling operations on 3rd party sites

If you have 30mins for a video I recommend People Make Games' documentary on it https://www.youtube.com/watch?v=eMmNy11Mn7g

Loot box style underage gambling in their live service games - TF2 hats, counterstrike skins, "trading cards", etc etc

Lootboxes comes to mind.

The .308 footgun with software contracting stems from a misunderstanding of what we pay software developers for. The model under which contracting seems like the right move is "we pay software developers because we want a unit of software", like how you pay a carpenter to build you some custom cabinets. If the union of "things you have a very particular opinion about, and can specify coherently" and "things you don't care about" completely cover a project, contracting works great for that purpose.

But most of the time you don't want "a unit of software", you want some amorphous blob of product and business wants and needs, continuously changing at the whims of business, businessmen, and customers. In this context, sure, you're paying your developers to solve problems, but moreover you're paying them to store the institutional knowledge of how your particular system is built. Code is much easier to write than to read, because writing code involves applying a mental model that fits your understanding of the world onto the application, whereas reading code requires you to try and recreate someone else's alien mental model. In the situation of in-house products and business automation, at some point your senior developers become more valuable for their understanding of your codebase than their code output productivity.

The context of "I want this particular thing fixed in a popular open source codebase that there are existing people with expertise in", contracting makes a ton of sense, because you aren't the sole buyer of that expertise.

If you have competent people on both sides who care, I don't see why it wouldn't work.

The problem seems, at least from a distance, to be that bosses treat it as a fire-and-forget solution.

We haven't had any software done by oursiders yet, but we have hired consultants to help us on specifics, like changing our infra and help move local servers to the cloud. They've been very effective and helped us a lot.

We had talks though so we found someone who we could trust had the knowledge, and we were knowledgeable enough ourselves that we could determine that. We then followed up closely.

This is mostly because the title of contracter has come to mean many things. In the original form, of outsourcing temporary work to experts in the field it still works very very well. Where it fails is when a business contracts out business critical work, or contracts to a general company rather than experts.

Valve contracts out to actually competent people and companies rather than giant bodycount consulting firms.

I've seen both good and bad contractors in multiple industries.

When I worked in the HFC/Fiber plant design industry, the simple act of "Don't use the same boilerplate MSA for every type of vendor" and being more specific about project requirements in the RFP makes it very clear what is expected, and suddenly we'd get better bids, and would carefully review the bids to make sure that the response indicated they understood the work.

We also had our own 'internal' cost estimates (i.e. if we had the in house capacity, how long would it take to do and how much would it cost) which made it clear when a vendor was in over their head under-bidding just to get the work, which was never a good thing.

And, I've seen that done in the software industry as well, and it worked.

That said, the main 'extra' challenge in IT is that key is that many of the good players aren't going to be the ones beating down your door like the big 4 or a WITCH consultancy will.

But really at the end of the day, the problem is what often happens is that business-people who don't really know (or necessarily -care-) about specifics enough unfortunately are the people picking things like vendors.

And worse, sometimes they're the ones writing the spec and not letting engineers review it. [0]

[0] - This once led to an off-shore body shop getting a requirement along the lines of 'the stored procedures and SQL called should be configurable' and sure enough the web.config had ALL the SQL and stored procedures as XML elements, loaded from config just before the DB call, thing was a bitch to debug and their testing alone wreaked havoc on our dev DB.

Igalia isn’t your typical contractor. It’s made up of competent developers that actually want to be there and care to see open source succeed. Completely different ball game.

Nope. Plenty of top-tier contractors work quietly with their clientele and let the companies take the credit (so long as they reference the contractor to others, keeping the gravy train going.)

If you don't see it happening, the game is being played as intended.

300 is extremely small for a company of their size in terms of revenue and impact. Linus media group and their other companies for instance is over 100 people, and is much smaller in impact and revenue than a company like valve, despite not being far off the number of employers (within an order of magnitude)...

300 people running Steam, creating games and maintaining Steam Deck / Linux and stuff?

Yes, 300 is quite small.

I think a better way to think of it is in terms of revenue per employee. Valve is WAY up there.

the implied observation is that valve is extremely small relative to what it does and how big most people would expect it to be

Of course smaller companies exist — there are 1 person companies! But in a world where many tech companies have 50,000+ employees, 300 is much closer to 100 or 10 and they can all be considered small.

And then you consider it in context: a company with huge impact, brand recognition, and revenue (about $50M/employee in 2025). They’ve remained extremely small compared to how big they could grow.