I have a lot of experience in building open source foundations, from my time at Apache, Eclipse and the Linux Foundation, lots of pros and cons across different entities in terms of how much professional help you want (versus volunteer labor). I generally don't recommend standing up your own foundation from scratch unless you're extremely well funded. The Linux Foundation essentially offers "Foundation as a Service" for projects. It hosts a variety of projects and organizations, from LetsEncrypt.org, to Kubernetes (CNCF) to GraphQL to NodeJS (OpenJS) to the R Consortium and more. I created a presentation here not so long ago about the process/benefits: https://www.slideshare.net/caniszczyk/bringing-an-open-sourc...
I'm happy to have a conversation if you ever wanted to chat more about the details.
I saw you posted this in other places too. Several of us have some LF experience, so we're already broadly familiar, but I appreciate it! We'll reach out if appropriate, thanks!
Wow. You created a Hacker News account an hour ago just to say this?
Who cares if it's "contentless?" Interactions on HN are frequently petty, mean spirited, and uncivil. Two people who are extremely active and give a lot to two different communities but don't know each other in real life had a pleasant interaction here that could have a fruitful outcome. Was this an event of Earth-shattering importance? No. But to read it as an illustration of the "vapidity...that infects open source projects" strikes me as noxiously cynical.
Event planning resources for conferences, graphic design help, legal staff who specialize in OSS issues, money for infrastructure costs (CI/CD, compute and storage resources), money for day-to-day tools (JIRA, Slack, Zoom, Discourse), documentation and web design resources, and much more. Basically all of the background conditions necessary for collaboration and ecosystem growth to be as unimpeded by resource scarcity as possible.
Governance can be set up in a number of ways, depending on the charter, with power allocated to different stakeholders in different configurations. See slide 42 from Chris's presentation. As a Rust user, I would follow the creation of such a charter with great interest.
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.
To be honest I don't know what this means. I was expected a yes or no answer. Does the Linux Foundation have final say over the organization or does its members?
Projects can be set up so that one entity (possibly a company which is a Linux Foundation Member) exerts dominant influence. This is one reason that many companies are comfortable bringing projects to the LF — and that's arguably better on balance for the Open Source ecosystem than them keeping those projects in-house and their governance murky.
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'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.
I wonder if it's reasonable to donate that trademark to the 501(c)(3) Mozilla Foundation and to then formalize a charter laying out Rust governance.
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.
> should the Foundation be a 501(c)(3) (a non-profit, in other words) or not?
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.
The problem with trying to become a 501(c)(3) nonprofit is that you have to show a "charitable purpose", which can sometimes be hard to do ("supporting open-source software" is not a valid charitable purpose under current US law, sadly enough) [not legal advice]
I successfully started a 501(c)(3) private foundation for precisely the charitable purpose of "supporting (scientific) open source software" in 2017. The IRS granted it with no questions asked.
Also not legal advice, but I literally did it so...
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.
An independent foundation for Rust makes a lot of sense. No doubt the Linux Foundation will pounce on this opportunity to absorb yet another project into its orbit... I would prefer if Rust steered clear of LF / CNCF if possible. Their governance and financials are opaque, they prioritize corporate sponsors and fancy events at the expense of every other priority, and there is already too much power concentrated in a very small group of people.
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...
A classic example of this going wrong is the Gentoo Foundation. Not only did it make them lose the founder of Gentoo (which, admittedly, isn't as much of a problem with Rust: Hoare has already moved on to bigger things), but it caused a variety of organizational troubles that still can be seen in Gentoo today.
Note that this proposal is not about changing the governance of Rust the language. That is and will remain the responsibility of an independent group. This is purely about handling administration of the Rust project and having a legal entity which can sign contracts, hold trademarks, own domain names, etc.
Depending on how you set up administration, independent governance can become difficult to sustain. The more money you take from donors, especially "directed" donations with strings attached, the harder it is.
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.
Yeah, that's why I'd prefer for the Rust Foundation to be as lean as possible, explicitly excluding raising donations for the whole project and paying developers from its scope. Funding development could then be done by other entities, not related to the foundation.
I think hiring of devs might be good long term though provided funding is there. There are always areas which might not be something people would work for fun on but which might be important to ecosystem.
Framing Mozilla as the “steward of the language” is one reason why we’re making this move. Don’t get me wrong, Mozilla is important to Rust, but (in all things other than the trademark, which is a nuclear option they’ve given no indication of ever using) the relationship is much more of a “large supporter of” then “in control of” one. Having a foundation would make this much more clear to folks who aren’t deeply involved in Rust.
From the very beginning, the folks sponsoring the Rust effort from within Mozilla made sure that Mozilla couldn't directly control things. And Mozilla also just isn't that kind of organization to begin with, honestly.
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.
The time is right for this step, Rust will benefit from having a proper umbrella organization. Also, it's a very well-writen post on what could be a boring topic.
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,....
Every non-toy, non-academic programming language should be non breaking. I know, there is a gray zone and some do not give a sh*. But as a company it is really hard investing into something that is breaking.
The Rust project has much more things under its wings than the C ISO group does. It’s a superset.
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.
That is common for toy languages without wide industry support. It doesn't inspire confidence.
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.
I'd prefer the evolution of Rust to slow down and stabilize. More like C and much less like C++. OTOH there are a few things I feel the language needs. Better control of memory layout, and a stable ABI in particular, so it can become a good foundation for more libraries and infrastructure.
And memory layout through repr(align). I also disagree that rust should slow down. There are a number of critical features that need to land for the language should “stabilize” (it is stable).
I agree a few more things need to get in. But AFAICT the abi is not stable and you may need to recompile all dependencies when updating the compiler.
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.
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.
C++ didn’t have a pragmatically stable ABI until like a year ago on MSVC. You had to jump through hoops with extern C APIs or COM and the like. The same is true in Rust, and even in C++ with different tool chains on windows.
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.
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.
I assume it may not be a popular opinion here, but it would be so much easier if projects like Rust could have a DAO (decentralized autonomous organization) instead of a foundation, and a blockchain account managed by this DAO instead of a bank account.
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.
1. What is the advantage of a DAO in your eyes? (Your comment mostly says that one could be done, not why.)
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?
You're right, I should have mentioned the advantages to begin with.
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.
> 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.
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.
I didn't meant the DAO to be an actor outside the legal system.
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.
> 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.
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.
I don't understand how a DAO would solve their problems.
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.
> 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 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.
I'm happy to have a conversation if you ever wanted to chat more about the details.