As the GP says, this probably refers to the practice of having short pithy statements to guide decision making. That is, AWS uses "Tenets" to help guide their decision making, Niko found that useful and wanted to do the same thing for Rust.
The post you linked to above links to a YouTube video[1] where he describes where the principles came from: some "design tenets" he came up with to help guide design of the async feature in Rust. Later he realized that they weren't specific to the async work, but were more about Rust in general. There has since been a lot of iteration involving others in the Rust community, and he's no longer calling them tenets.
And really, if you actually read the principles themselves, do they really sound like they're based on the design tenets that AWS uses? They sound an awful lot like principles that the Rust community has been using, but never articulated before. Maybe some more iteration is necessary, but it doesn't look very sinister.
Tenets as used internally at AWS are a set of principles that each team decides for themselves, as guides in the face of ambiguity. There's no overarching set of tenets (that I'm aware of), so this is probably just referring to the idea of having a guiding set of principles to resolve tradeoffs.
This. Each org, team, and project has their own set of tenets. There are a few common sense tenets that are overarching (Security is priority 0), but there is no one set of 'AWS tenets.'
Tenets are used as quick statements to validate decisions. And the tenants are always up for debate and revision.
Using 'AWS tenets' isn't some nefarious way to control Rust. It's borrowing a useful (IMO) management/decision making structure to help guide decisions. Using 'AWS tenants' doesn't give AWS undue influence anymore than using the concept of Andon cords gives Toyota undue influence.
I disagree a lot. I don’t think using AWS Tenets was done nefariously.. but it has an important implication on the Rust community as a whole.
Engineers are really relying on the Rust Foundation to do right by them, and by adopting Amazon or other big tech company principles it’s spitting in the face of engineers who don’t trust them and adding the potential for bias in decision making of the foundation.
I’m hopeful that the Amazon contributors will understand this and show full support.
Again, Rust hasn't adopted Amazon's principals. It has adopted a mechanism used by Amazon by which it can define its own principles.
The tenets of the team I work on are stuff like 'treat every customer like your best friend on their worst day'. And 'learn something new every day'. They are tenets of a team in AWS, which makes them (to some extent) 'AWS tenets'.
Are they somehow nefarious because there are people who don't trust anything that remotely relates to Amazon? Or are they innocuous statements of intent that are applicable to most companies?
You don't have to like or trust Toyota to use Andon cords. You don't have to like or trust McKinsey to use the 7-S framework. You don't have to like or trust Motorola to use Six Sigma. You don't have to like or trust Amazon to use 'AWS tenets'.
Right and now we are in semiconductor shortages because people adopted Toyota concepts in a non-Toyota context. In the mean time, Toyota adapted their own concepts to weather the storm of semiconductor shortages, for a short while atleast.
This is a misunderstanding. Amazon and AWS use "tenets" as a tool for focusing and aligning a team on what it values. The Rust Principles are an application of that tool for the Rust project, not adopting the exact same tenets that teams at Amazon/AWS use. See this 90 second video for a quick rundown of how tenets are used.
Yes, that is exactly what is happening here! When the Rustacean Principles were created, Niko said in his blog post[1] that the idea of creating principles was inspired by AWS. Not that the principles themselves were taken from AWS.
Writing tenets is a tool, like making a checklist is a tool. You can use the idea of making a checklist without using the checklist items.
