Towards a Rust Foundation
smallcultfollowing.com
smallcultfollowing.com
I'm happy to have a conversation if you ever wanted to chat more about the details.
https://www.slideshare.net/caniszczyk/bringing-an-open-sourc...
Moving away from Mozilla, regardless of destination, presents an opportunity for the most powerful stakeholders within the community to exert greater influence, many of whom I would be less comfortable with than Mozilla.
Rust, though, is already at Mozilla, whose influence seems to be benign.
I'm curious, which Mozilla entity holds the trademark: is it the 501(c)(3) Mozilla Foundation, or is it their for-profit subsidiary, the Mozilla Corporation?
I never thought about this, but TESS says it's Moco, which is what I'd expect.
For what it's worth I would have greater confidence in such an arrangement than I would in a 501(c)(6) Business League version of a Rust Foundation, which would in my view undermine independence.
If you go the independent foundation route, choosing 501(c)(3) would be in keeping with the stated priority to have Rust's governance be independent. This makes it more difficult for corporations to control the foundation's direction through insisting that their donations be used for specific purposes, because donations to a 501(c)(3) cannot unduly advantage any commercial entity.
ETA: There are different types of "non-profit" organizations under IRS code 501. 501(c)(3) is a "Charitable Organization", and donations are tax deductible. (Tax-deductible donations cannot be used to unduly advantage a commercial entity because if they were, the business could avoid paying taxes on funds they use to further their own initiatives.) 501(c)(6) is a "Business League", where donations are not tax deductible, so donors have much more leverage.
I'm so incredibly not a lawyer, but my understanding is that educational 501c3s need to be predominately educational, in that they have classes and a physical location.
If the primary purpose of the Rust foundation is open source code and standardizing the language, it's not exactly educational.
Also not legal advice, but I literally did it so...
The Linux Foundation / CNCF people will tell you that it's really hard to setup a foundation, and you should leave it up to them. I don't think that's actually true. In my opinion LF gets much more value out of projects (through compounded brand value and revenue opportunities) than the other way around.
Nothing terrible will happen if you go with them... but nothing amazing will happen either. You will get the bare minimum support and infrastructure, and nothing more. Meanwhile, a few people who don't actually contribute any open-source code will benefit immensely from the Rust brand.
EDIT: I just realized that the Linux Foundation people are already on this thread making their sales pitch...
Hope this goes well!
This seems to imply that the US is the only place a foundation would be incorporated? Other jurisdictions may have more favourable legal regimes.
For example, you may fear offending a donor who wants to use the "Rust" trademark for their megabudget conference where they sell themselves as the preeminent Rust experts.
This comes into play if you consider funding development directly through a foundation, which requires large donations.
https://internals.rust-lang.org/t/blog-post-towards-a-rust-f...
These conversations have been going on a long time. This particular iteration of this conversation started before I left Mozilla. It has nothing to do with me personally, regardless of that relationship.
I have long (before, during, and after my employment at Mozilla) have thought that an independent foundation would be excellent for Rust, but am worried about the details. Foundations require active administration, which is even more work. And it's unclear who does that work. I think that we've grown to the point where it very well make sense now, though.
Go values not breaking current code much more than adding features.
"stability" is a tough word; some people use it to mean "doesn't change", and others use it to mean "append-only change."
Languages are software products, they are evolve to fulfill the market needs or they die.
ANSI C compilers are not required to still support K&R C, Annex K was compulsory on C99, became optional on C11, gets() was removed, some semantics corrected,....
For example, C is handled by ISO/IEC JTC1/SC22/WG14.
The idea that Rust would need a foundation is making me uneasy.
The Rust project sees Rust as more than just purely a language. For example, the C ISO group doesn’t run any web facing infrastructure, with all of the legal and financial obligations that implies, nor do they develop compilers, with all of the CI/hosting infrastructure that implies.
They’re just different in scope, which has been true for all of Rust’s lifetime.
There should be compilers from Microsoft, IBM, Apple, GNU/FSF, and several others. There should be a properly ratified international standard that describes the language. There should be support from 16-bit microcontrollers to mainframes.
Languages like C have lots of web facing infrastructure. It just isn't all run by one entity. The eggs are not in one basket.
Java isn't officially standardized (ISO or such), neither are C# nor Python, Ruby, etc.
I would like it to be "feature complete" without having regular churn like C++. Or the recent battle with Python that was a sort of last straw for Guido. C is almost completely stagnant and that's a good thing. Posix as well. If you want to be a long term systems language it seems stability is a critical feature and Rust needs to get that in the next few years. IMHO or course.
That is for the Rust ABI, which much like with for C++ doesn't exist.
The only language with a stable ABI is C (and that is more accidental than explicit). It’s too hard a guarantee to provide with little ROI when you have a workaround, and it chains your implementation to ABI details.
Just as an example, rustc is very clever about struct layout and liberally pads fields to get superior alignment. This may change in the future depending on architectures and paradigms. You don’t want your ABI to define a padding scheme for your targets today, you want future compilers to be smarter.
If you want to guarantee stability you need to align the memory manually on the structs that cross ABI boundaries like shared libraries, and any kind of language construct that lets you do future tricks with ABI within a binary but provides escape hatches for things along the boundary would look identical to how you do things today via attributes.
TL;DR ABI stability in the compiler is simply not desirable. You can already do it manually and you should do it manually. It’s fairly ergonomic as well.
Java, .NET languages have a stable ABI.
All IBM and Unisys mainframe languages have a stable ABI via their language environments.
https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2...
Furthermore, GCC/libstdc++ have maintained ABI compatibility for at least 15 years now, even across an incompatible change of std::string and std::list required for C++11 conformance, so in practice the situation with C++ looks better than with Rust.
https://developers.redhat.com/blog/2015/02/05/gcc5-and-the-c...
There is a trade-off between "provide types a stable layout" (required for a stable ABI) and "optimize my program as much as possible" (e.g. change type-layout using profile-guided optimization to put hot fields inside the same cacheline).
In Rust, if you want to give a type a stable ABI, you just need to stamp `#[repr(C)]` on it. Otherwise, you get optimizations by default.
The amount of types and functions in a code-base is usually much larger than its surface API, and this decision balances optimizing properly, while still providing a stable API.
The main issues I see with this idea are volatility of cryptocurrencies prices, inability of paying with cryptocurrencies in most cases atm, environmental issues regarding the blockchain and the infantry of DAO governing models.
But as an abstract idea I believe DAOs will replace foundations at some point in the future, making such discussions much easier.
2. The Rust community is made of people who have been trying very hard to write, essentially, a bug-free compiler and a bug-resistant programming language, and they know it is incredibly unrealistic to be 100% bug-free. How would you convince them that a DAO with its terms specified in code and not in human legal documents would not have even a single exploitable bug?
It's easier, cheaper and faster to setup a DAO than an international foundation, especially regarding registration, opening bank accounts and international members. Important questions such as "which jurisdiction to register the organization in" or "who manages the bank account" becomes irrelevant in a DAO.
It's also cheaper and easier to manage a DAO over time than a traditional foundation. There is no need of payments for bureaucratic stuff, since the protocol is in charge of organizing and executing decisions.
I don't belong to those convinced it's possible to write bug-free code, however, not every bug means immediate exploit, while exploits can also happen in legal contracts.
The immediate solution is a DAO where access is limited to known legal entities. In case a bug is exploited, you can always fall back on the good old legal system to resolve the conflict.
There are other possible solution, but I don't want to turn this comment into a lecture about DAOs.
We use a DAO in a project I've been involved with for a long time in the past, Bisq. I'm not sure how we could have managed it otherwise, since we were a small project, with contributors all over the world, most of them not knowing each other personally.
I never understood these arguments. People do not live in an abstract space outside existing social and economical structures. If one way or another, this DAO thing turns into an actor paying wages, the related laws will apply in some juridiction.
Now, what you might say is these questions become irrelevant for the structure creating the DAO, and are instead left to be solved by those receiving the benefit. It sounds dubious at best.
The difficulty of answering your remark is that different legal systems probably have different point of views about it.
According to what I was told where I live, I'm allowed to organize activities, even such involved payments, with other people without registering an organization. Especially if those other people come from different countries. As long as I'm declaring my full income and pay taxes.
Such a thing limits what a DAO can do - for example, it can't sign agreements with regular companies (it's not a legal entity) or it cannot employ people.
But as long as you don't do such things, I was told it is allowed. I'm being careful with such statements since I'm not a lawyer.
You may see DAOs as a legal alternative for civil agreements, which are really difficult to make for individuals in the international market.
The article starts by saying that they want to demonstrate that Mozilla is not the sole entity behind rust.
After that, the very first reason they give for wanting to start a foundation is to sign contracts.
> Lately, though, the Rust project has started to hit the limits of what Mozilla can reasonably support. One common example that arises is the need to have some entity that can legally sign contracts “for the Rust project”. For example, we wished recently to sign up for Github’s Token Scanning program, but we weren’t able to figure out who ought to sign the contract.
One problem they listed is having a bank account which would hold onto money from a few sponsors temporarily for a particular conference, before paying it out to catering, venue, and airfare.
How would that work for a DAO? Would you have to write a new contract for each conference? What about paying for last minute arrangements (a flight gets diverted and you need to pay more for travel)? Would the contract allow for that, or block that spending of funds?
Actually, how would it block the spending of funds, or tell what you are spending the money on? It's not like Delta has a bitcoin address you can specify in the smart-contract. You have to pay them in dollars.
The legal system has had centuries of time with millions of people working out "bug-free" code. Something like a DAO might work for your situation but any organization with the sort of resources Rust has would be completely negligent to rely on such a comparatively untraveled path.