Rather than trying to be T-shaped, I think it is better to be curious and follow up learning paths on those innate feelings for exploration. Maybe your skill set becomes fractal looking. I think this can be the basis for unique value creation. (E.g. the typography course Steve Jobs did as a student, leading to care/attention to fonts on the early Macs).
I do agree with the basic idea of being T-shaped, however. I've personally seen project teams having fragile delivery capability due to a lack of skills, or lack of skill overlaps, which made the team reliant on individuals that could be off sick, on vacation, or assigned elsewhere.
Since the author mentions there are many users of curl on Apple platforms, there should be a pool of engineers from which a volunteer could be found to help out.
The author didn't mention reaching out to Apple for help? My opinion is if Apple documentation call out the use of curl as part of a workflow or enabling step, or actually as part of a product, then there is a moral duty to help out (not a legal or license duty).
I would prefer to see the big tech companies contribute to a foundation who could redistribute funds to key open source groups. A credit for a cloud instance of the machine would be sufficient in most cases. It would also remove undue influence of one vendor over another. Maybe such a thing exists, and I would welcome if someone pointed it out.
> then there is a moral duty to help out (not a legal or license duty).
May I invite you to descend off that hobby horse for a moment ?
Let us perhaps replace the word "Apple" with a variable parameter, say, $VERY_LARGE_CORPORATION
Lets say you turn up at said $VERY_LARGE_CORPORATION and start talking to them about something wishy-washy, intangible and wholly subjective such as a "moral duty".
You will be laughed out of the room.
Once a company grows to a size where employees are measured in the tens or hundreds of thousands then it is simply impossible to get involved in edge-cases and subjective matters. Everything has to be defined and measurable because otherwise the whole caboodle descends into utter chaos very quickly.
If you work somewhere that you feel that talking about a "moral duty" would be laughed out of a room, please take a moment to consider whether you want to continue toiling for that organization.
Look at the page for curl.se: Fastly is a sponsor. Look at sqlite's page: Bloomberg is a sponsor. Look at openssls page: nginx, Shiguredo, Activision, and Microsoft are sponsors.
All of those companies use all of those tools. Where js the indignation over them only supporting one? I posit that there either is no moral duty as supposed, or its been fulfilled by the single sponsorship. In which case Apple's open-source contributions have paid over their debt multiple times over.
> Where js the indignation over them only supporting one
Most of those companies sponsor many projects.
> I posit that there either is no moral duty as supposed, or its been fulfilled by the single sponsorship
Maybe but the issue in OP is that Apple has specific hardware requirements and various OSS developers are struggling to support M1 chips without paying out of pocket to support them. Whether it's moral or not, there is definitely a logistics issue between Apple and the very real and very important OSS communities.
Whilst I have heard of B Corporation, I will admit I don't know a great deal about it/them.
However a brief look round their website suggests to me that what they do is basically structured ESG (Environmental, Social and Governance).
ESG is somewhat different to what we are talking about here. ESG has become a hot-topic in the corporate world, especially for listed companies where investors can now screen for companies based on ESG metrics.
Over-simplified definition of ESG is treating your staff well (working conditions etc), treating your immediate community well (not polluting rivers etc) and contributing to good causes through corporate philanthropy.
The whole point is ESG is about how corporations interact with the humans in their operational environment.
BUT You cannot extrapolate ESG to open-source software, because ultimately, if you look at it through the corporate eye, software is software. And the corporate eye looks at software through the legal (licensing) lens, because that gives them something tangible and measurable to work with, which is the preferred modus-operandi of the corporate mind.
Therefore if a piece of software is openly published with an extremely permissive license then you cannot blame the corporation for taking the path of least resistance (i.e. using it inline with the written terms of the license, which, depending on the license wording, could be little more than ensuring a credit is written in the correct places).
Again, this comes down to the problem with scale. If you have tens of thousands of employees, software licensing is difficult, and if you had to "do deals" for each and every piece of open-source software then it would very quickly become unmanageable.
Equally, a typical corporation with thousands of employees, could easily use thousands of pieces of open-source software. Because there is no price-tag on open-source software, you would then be in a position of having to engage in lengthly discussions that involve multiple departments in order to agree on what to pay each and every open-source developer. It all becomes very messy very quickly.
Don't get me wrong, I see where you are coming from on this.
But to be perfectly honest, OSS developers are not entirely without blame here.
Sitting there, releasing code on an overly permissive license and then wondering why nobody is paying you .... it's sort of a case of dream life meeting harsh reality, really.
OSS developers live in the wishy-washy world of subjective views and "moral duty".
Corporations need standardisation and clarity because otherwise they descend into chaos.
The easiest way to do that is through less-permissive licenses that have a clear requirement for remuneration.
Otherwise, if you start talking about "donations" or anything else, then you start walking into that subjective ground again. And especially in terms of "donations", every man and his dog thinks corporates are "rich" and can afford to donate to their cause. So your request for "donations" will be lumped in the in-box along with everyone else's.
Software is a lot more than software. Here is why open source should be part of the ESG calculations; because a random person from Nebraska maintains a critical dependency of some part of your stack and could get bored or worse.
Well, ignore "moral duty", it's just not a notion expressible in corp-speak.
Take "good PR"; it's readily understandable. Why won't Apple, or any other company that won't mind spending $2k on good PR among the IT crowd, pick up the lead? Any PR department worth their free lattes should.
I agree with your assessment of the current state of things, but we shouldn't just accept that as the only option.
Is it really too much to expect that the most senior engineers in a company could carve off a small portion of the marketing budget for "community good-will" and make small donations of platform credits (which cost close to zero) or cash?
If each of the $100B+ tech companies put just $10M into open source with a bit of care, I wager they would make the money back in developer job satisfaction and evangelism alone.
> I would prefer to see the big tech companies contribute to a foundation who could redistribute funds to key open source groups.
You mean like the Linux Foundation? Or the Cloud Native Computing Foundation? Or the Rust Foundation? Or the Python Software Foundation? Or the Free Software Foundation? Or the Software Freedom Conservancy? Or the Mozilla Corporation?
Why would Apple do anything? They're getting it for free while contributing nothing. It's what you should expect when developing permissively licensed software.
Apple do contribute to some open source projects, by employing developers and also being actively involved. IRRC clang + llvm for example.
There are global enterprises which (internally) explicitly forbid any empolyees to contribute to open source code used to develop their product (tools, IDEs) and even used in their product (The Linux kernel for example).
That said, Apple providing Daniel / the Curl project with a machine should be a no-brainer.
>That said, Apple providing Daniel / the Curl project with a machine should be a no-brainer.
The problem with that is where do you stop ?
How many OSS projects are there ? Where do you draw the line on who gets a free machine ? Then we get into the question of whether it's just the project maintainers or any contributor ? And if the contributors, then how many LoC do they need to contribute before they get a free machine ? If Bob just submits a PR to bump a version number, does he get a free machine ?
Giving a free machine to any Tom, Dick or Harry who has ever published a piece of OSS code is simply not a serious proposition.
Here's a solid proposal. One machine per project. Project defined as a source tarball/repo used when building the OS. So all the stuff that comes from FreeBSD base counts as one project, sorry developer(s) of /usr/bin/cal, you'll have to fight for access with the rest of the FreeBSD team.
Exception policies for shenanigans.
It's not that hard to share a mac among a developer team, so one mac per project is a good start. There's natural downward pressure on the number of upstream projects used, so one for each of those is a good start. If you also make it request based rather than reaching out to send them, the capex won't be too bad; some upstreams won't be interested anyway.
If I were Tim Apple and wanted to donate a machine to particular projects; anonymously through an engineer or lawyer is exactly how I’d do it. Having it be known that Apple is a hardass and gives nothing helps keep the noise down.
When I first was learning to program I was shocked at the logical mistakes and errors I was making. I thought these were an initial bout of bad luck that would pass. But no! And I learned the craft of debugging before my programming hobby took could really take off.
Programming takes high precision thinking. Learning mathematics is what has tuned my mind to better, more precise, thinking. So I am grateful for this and feel I am a much better programmer for it. It also seems to sharpen up ones debugging skills.
There are other things that help also. Second, I'd say learning to write well helps a lot also. Programming is communication (by way of the source code you leave behind for others to read and interpret). A deft hand for exposition sits at the centre of good naming practices for code.
I think pg is one of the best placed people to critique the situation because he knows what a start-up is and how to do one, he's in the same tier of society (top tier wealth), and he knows what is takes to run a social network.
The "it is going to be hardcore from here" email the CEO sent to Tesla employees 'worked', but the same email to Twitter employees resulted in significant resignations. I think the CEO was shocked and this underlies pg's point.
Given that it was a forced buy, the game was always that of a corporate raider approach - go in, make the unpleasant but needed decisions, and then sell out as soon as the value uptick became realisable. pg applauded the cut to staff IIRC.
CEO should have taken a leaf out of Rupert Murdoch's book - as the owner don't write the headlines - let the editor do that. Being behind the scenes to just make the most considered accurate business decisions was the right way.
If instead you are out in front of the public, you're emotional side will kick in due to the slings-and-arrows coming from the audience. Hence the wrong decisions will be made.
You can't wear both the hats of 'eccentric' Corporate Jester and Corporate Raider at the same time. The Dave Chapelle boo-ing incident just underlies this.
I see reading as a knowledge compression function. So it is efficient to read something that the writer otherwise spent a long time assembling.
But reading is just a route to quality thinking. Another route is via technical debate. You verbally describe a problem and solution and then your peers drill into that and offer counterpoints. This is in my experience as beneficial as reading due its interactive aspect - which reading does not offer.
I'm glad someone pointed out these things, as I concur. I learnt C++ via the C++ programming language book, and it gave me many of the above benefits/insights. (The book has its faults though). It is akin to trawling through the CLRS book. It does make you a better programmer but no-one knows why. (An attempt at sarcasm - I know most of us never need to do advanced data structures/algorithms but it helps refine the mind for programming challenges).
The article focuses on the financial world. Historically in the UK (and elsewhere) finance roles have had strong interest for applicants, and high salaries were on offer. So the industry could pick the "most talented".
Now the model has broken down which is the motivation for the article. That's because the "talented" C++ developers have been hived off by the big tech firms (which can pay equivalent salaries or more), or the top video game companies (which generally pay low but make up for it in fun).
What remains are the "normal" developers. But their nature of business means you can't achieve a market edge with that level of talent, all else being equal.
This was never the case for COBOL because that was deployed to keep the business running, not for creating unique value and market edge. So "normal" developers work out just fine.
Finance firms hire a lot of talented graduates. They need to work against their natural inclinations, and provide training and mentorship to get those folks up to speed with C++; a long journey. They don't want to do it due to being seen as providing a cross-subsidy to their competitors when the graduates switch companies.
It is very possible to do this if you are a contractor working on a tech stack that people consider “legacy” because the software built on this will more likely be in a maintenance/bug fix phase (as a broad generalisation).
Pure bug fixing can be like being paid to solve coding puzzles. But of course often bugs are at the intersection of non technical factors other folks here have mentioned.
The proposal was unstable on both sides in fact. Jobs didn't fully appreciate the importance of power efficiency at the time - an internal team scrambled to demonstrate why Intel would have been a non-starter due to power budget. There were also ecosystem issues, since gearing up for an embedded device at that time mostly meant choosing ARM architecture for that complexity tier they were engineering.
So a deal based on any price wasn't a realistic avenue for iPhone. The fact that Intel was actually considered was itself a radical move on behalf of Steve (absent the technical obstacles that emerged later).
Actually that is the "Innovator's Dilemma" in action. Managers will always prefer to safeguard and enhance the high margin aspects of the business and discourage/under-invest in low margin disruptor aspects of the business due to cannibalization of profits and thus missing profit guidance for the quarter (thus losing compensation personally). They knew the tide was changing but organisation dynamics prevents a course correction.
Only a few companies can buck the Innovator's Dilemma, usually only founder led enterprises with significant control.
The Innovator's Dilemma isn't about missing quarterly guidance. The dilemma is that it's perfectly rational and profit maximizing to continue focusing on your cash cow even when obsolescence is a foregone conclusion. It wouldn't be a true dilemma, otherwise.
The incumbent is the only player that can maximally squeeze the very considerable remaining profits from old technology, and they should do so with gusto. Moreover, switching to new technologies comes with more risk, even when it seems obvious what the new market will look like because the old market has almost zero risk--it's completely proven.
All the "solutions" to avoid the dilemma, like selling the old technology to take future profits and then pivoting to the new market, are just corporate branding shell games. They might even be in fact sub-optimal, but in any event the fundamental dynamics remain the same.
Except it didn't actually work out. It worked out at the time, and thus was "perfectly rational" then but rationality should not have a limited time horizon because then it is limited. This is the problem with short-term thinking, it eventually leads to loss.
What value is there in corporations being immortal? That is, why forego substantial and easy profits merely to exist as the same corporation further down the road?
There are transaction costs to creating and building a corporation, but do those offset the clear costs of leaving money on the table, especially in the modern world of highly liquid capital, and particularly in markets with clear technological breaks. The lesson of the Innovator's Dilemma is that very often the perfectly, unqualifiedly rational decision is to press your advantage to the very end. And importantly it not only maximizes short-term profits, but implicitly it maximizes long-term profits globally by most efficiently allocating resources. Why waste energy swimming upstream when there are endless fish spawning and starting their journey upstream already along with ample resources of their own.
There isn't anything particular about a company being immortal. The issue is now. No one wants to be there when a company is dying. There's nothing heroic about "going down with the ship" in the corporate world.
I do agree with the basic idea of being T-shaped, however. I've personally seen project teams having fragile delivery capability due to a lack of skills, or lack of skill overlaps, which made the team reliant on individuals that could be off sick, on vacation, or assigned elsewhere.