> Mozilla and the Rust Core Team are happy to announce plans to create a Rust foundation. Our goal is to have the first iteration of the foundation up and running by the end of the year.
Good idea. I can definately see this working out for Rust.
> The various trademarks and ___domain names associated with Rust, Cargo, and crates.io will move into the foundation, which will also take financial responsibility for the costs they incur.
Very important folks.
This direction looks very interesting. We'll see what happens.
It is good news that rust is settling up a independent foundation.
If other shelved or high risk Mozilla projects such as MDN , servo , thunderbird setup similarly it would enable us to directly contribute to the projects instead of the foundation or not at all.
The only project the corporation would never let go is Firefox as it their revenue source , however
other projects could perhaps be salvaged
I agree it would be best if FF was it's own foundation. I would like to hear some arguments from Mozilla about this. It seems an idea that only has upsides to me. I get the feeling Mozilla is kind-of hijacking the donations people think are going towards Firefox.
This topic keeps coming up. Mozilla is viewed as a bloated entity whose only legitimate activity is maintaining Firefox. No-one cares about the other initiatives they spend money and resources on, and they especially don't want their donations going toward Mozilla's overpaid leadership.
People would like to donate directly to Firefox, but as things stand, this isn't an option. This isn't because Firefox falls under the Mozilla brand, it's because Mozilla choose not to accept Firefox-specific donations.
Mozilla Foundation can't accept Firefox specific donations because the Mozilla Foundation does not develop Firefox. The Mozilla Corporation does and the foundation cannot give money to the corporation (only the other way around). So you'd need to redo a whole lot of things for this to be possible.
> Mozilla Foundation can't accept Firefox specific donations because the Mozilla Foundation does not develop Firefox. The Mozilla Corporation does and the foundation cannot give money to the corporation (only the other way around).
Does that mean that not only it is impossible to make Firefox specific donations but also that it is guaranteed that none of the money donated to Mozilla can ever end up being used for Firefox development?
As GoOnThenDoTell pointed out, they could probably independently pay for Firefox developers but it'd probably be a messy approach.
Keep in mind that the Mozilla foundation gets something like $10 million in donations per year while the Corporation gets $500 million per year from Firefox search deals. So donations are a drop in the bucket compared to the existing revenue streams.
That's true but as MaxBarraclough points out in this discussion the Mozilla Corporation could simply remove an equal number of it's engineers from Firefox development. Thus your donation provides no net gain. There'd also probably be some overhead from managing those new Foundation engineers as they probably, legally, cannot be directly managed by the Corporation.
So as long as the Mozilla mission is not aligned with the "Firefox mission" there is no winning.
Mitchell Baker is paid by the Mozilla Corporation which in turn is paid by it's search deals. She is paid $0 by the Mozilla Foundation and it's donations. Feel free to checkout the foundation financial statement from 2018 (it's on page 7):
Which in the context of how Mozilla deals with donations is a separate and unrelated discussion.
edit: More broadly, pointing out someone as making a false statement does not mean you agree with the opposite view, simply that you don't like people spreading false statements.
Sure, you were right to point out that freshsqueeze was incorrect in saying they funnel donations to their overpaid CEO, but the fungibility point is an important one.
A related point on fungibility turned up in earlier discussions: donating directly to Firefox might not count for much if Mozilla balance it out by redirecting the same sum of their general fund away from Firefox. [0][1]
The corporation basically exists to make the Google Search Deal possible. And considering that the search deal pays more than donations to the Apache Foundation and the Mozilla Foundation combined, it looks like it was a smart move.
* According to https://www.mozilla.org/en-US/foundation/annualreport/2018/ (different document, but notice that both are for year 2018), the Mozilla Corporation got $435M from royalties, subscriptions, and advertising. In other words, while the Foundation is not technically allowed to give the Corporation money, that doesn't seem to be a problem.
I wouldn't ask why the need for the corporation. I'd ask why the need for the foundation. Though I'm pretty sure I know the answer: the foundation exists to limit the exploitative behaviour of the corporation. Remember: Benefit Corporations didn't exist at the time.
> By forming a commercial subsidiary, the revenue-generating activities of the new entity can provide funds to support development, testing, and productization of the various Mozilla open source technologies. This benefits both end-users of Firefox and Thunderbird, and developers and others who want to use the Mozilla open source code in various ways. Having the Mozilla Corporation handle revenue-generating activities associated with these products also allows the Mozilla Foundation to achieve its goals while still itself remaining a tax-exempt organization.
They'd need to probably do it all independently of the corporation's development efforts which would be rather inefficient. Might still make some IRS agents twitch since it could look like trying to get around tax laws by the corporation.
Realistically, the corporation makes so much more money from Firefox search deals versus foundation donations that this shouldn't be necessary. But as long as the Mozilla leadership wants to screw Firefox they will find a way. For example, by removing an equal number of engineers from Firefox development on the corporation side as the foundation hires.
They are going to do that anyway as Firefox keeps loosing market share the search revenues is going to diminish .
They have been unable to find alternative revenue streams.
TBH it is hard to make a recurring revenue of $ 400M even from scratch , Mozilla has an existing culture that is not simply geared towards this kind of product building . I would be skeptical of even competent board and management doing this .
>TBH it is hard to make a recurring revenue of $ 400M even from scratch
True but they also didn't need to had they made decisions geared around long term sustainability. They could have kept Firefox running with a budget of under $150 million a year (~500 employees) and invested the rest. That'd be a nest egg of probably $4 billion by now including growth. That's enough for them to keep going for decades with no external revenue.
Instead they kept spending money on moonshot projects to become an independent megacorp. Failing every time. Now they don't have many options remaining.
That's not true, if the lawyers wanted to set up a pathway for that then it could happen via various legal entities and hoops. Mozilla doesn't want the community to have that much say and they don't want to lose that much control and be dependent on users. The problem is they keep losing share of the market. I'm not sure how they can fix that since google is always a little bit ahead because they essentially dictate which way internet technology goes these days because they control 80% of the browsers out there via chrome.
On the other hand, Mozilla has done a lot of stuff which is outside the scope of "Firefox", but which is good for the community as a whole. I mean, that's what Firefox was originally: an offshoot of the Mozilla monstrosity that Mozilla (the organization) took and ran with, to everyone's appreciation.
Plus, if people were donating towards Firefox specifically, how many of them would be upset that Mozilla was spending "their" money on developing a whole new programming language? "This is a waste of my money, just use C++ or something instead of reinventing the wheel".
Some folks believe very strongly in the advocacy that Mozilla undertakes, and believe that separating the software efforts from the advocacy would diminish the funding for advocacy.
Which is probably true; Google is unlikely to spend half a billion a year on Mozilla's advocacy efforts.
> Google is unlikely to spend half a billion a year on Mozilla's advocacy efforts.
AFAIK, Google's money goes to the Mozilla Corporation, while the donations go to the Mozilla Foundation. So the advocacy is already separated, isn't it?
2% of annual net-revenues from MozCorp go to the Foundation; and Google's deal is with the Foundation, but I'm iffy on how much makes it straight into MozCorp.
I'm pretty sure MoCo owns the Google deal. From that same Wikipedia article in the section about MoCo:
> It also handles relationships with businesses, many of which generate income. Unlike the Mozilla Foundation, the Mozilla Corporation is a tax-paying entity, which gives it much greater freedom in the revenue and business activities it can pursue. From 2004 to 2014, the majority of revenue came from a deal with Google, which was the default search engine in the Firefox web browser.
I did more digging, looks like it's with the corp:
> In CY 2018, Mozilla Corporation generated $435.702 million from royalties, subscriptions and advertising revenue compared to $542 million in CY 2017. 2017 was an outlier, due in part to changes in the search revenue deal that was negotiated that year. Despite the year-over-year change, Mozilla remains in a strong financial position with cash reserves to support continued innovation, partnerships and diversification of the Firefox product lines to fuel its organizational mission.
However, as noted earlier, the corp does pay for the foundation's advocacy:
> A portion of search revenue combined with grants and donations is used to fuel the advocacy and movement building work of the Mozilla Foundation and its broad network of supporters of Mozilla’s mission.
This is true. Execs at the non-profit foundation have been pocketing millions of dollars. And I cannot really point out what they do. I guess this is common in many non-profits, where people donate, and people at the top siphon it off. There's some corruption at play at the top.
Mozilla makes 500million, the CEO takes 2.5million, not saying that isn't too much, but given it leaves 497.5 million left, I doubt you can blame that for the failings of FireFox.
The problem is not per se that execs at NPOs pocket millions of dollars. After all, that is the market rate - and NPOs have an interest in attracting (and retaining!) high quality staff.
NPOs and NGOs should not have to depend on people willing to exploit themselves for the cause, not on the leadership level and not on the base level (where this is even more common).
The problem is rather that CxO payment in general has gone through the roof over the last 60 years, with the problem becoming ever worse since the fall of the USSR. The ratio of CxO to average worker pay was 20-to-1 in 1965, 58-to-1 in 1989 - and in 2018 it hit 278-to-1!
> The problem is not per se that execs at NPOs pocket millions of dollars.
It is, because money is not infinite so those resources spend on high level execs could be spend way effectively elsewhere.
> interest in attracting (and retaining!) high quality staff.
I know ton of high quality people (researchers) and they aren’t pay millions of dollars. A C-level desk warmer could do its job as effectively if paid a high, yet decent (in comparison to the average wage) amount.
> A C-level desk warmer could do its job as effectively if paid a high, yet decent (in comparison to the average wage) amount.
The problem is you won't even find a desk warmer, at least none with actual experience in leading a ~750 employees organization, without taking part in the wage racket.
The only ones you'll end up hiring are either newbies wanting to use your organization as a "career trampoline" (which is bad because you want stability, not a change of course every other year) or failures that don't have a chance anywhere else.
The system must be fixed, and the system is absurd CxO pay. Relying on individuals sacrificing themselves/their orgs won't work.
I'm afraid that now the best way to donate to Firefox, MDN, Thunderbird, etc is to donate your time, by writing code or content and making pull requests.
This is a much harder way to donate than simply by paying money, though.
I really don't see how servo can live on. I can't imagine the core team being very enthusiastic about taking up the reins and not getting any pay for doing it.
One important question not touched on my the blog post: Where will the Foundation be located?
Will is be US-based like Mozilla, or will it be somewhere else, like Europe?
A couple of foundations have moved away from the US in recent years, for example the Eclipse Foundation (Belgium) and the RISC-V Foundation (Switzerland).
It seems foundational (if you'd forgive the pun) to know under what laws the foundation will operate, and who (if anybody) will be excluded from taking part in the project because of sanctions regimes.
I really hope that a neutral jurisdiction will be chosen. RISC-V is a good example to follow, here is a quote from their website:
Incorporation in Switzerland has the effect of calming concerns of political disruption to the open collaboration model. RISC-V International does not maintain any commercial interest in products or services as a non-profit, membership organization. There have not been any export restrictions on RISC-V in the US and we have complied with all US laws. The move does not circumvent any existing restrictions, but rather alleviates uncertainty going forward.
> I really hope that a neutral jurisdiction will be chosen.
Countries by definition are not neutral. Switzerland is an odd special case, but even they're not truly neutral. European perspective may be different by I've always considered the US to be relatively neutral in legal senses. There's a strong backdrop of rule by law in the US.
Coordination with Swiss research organisations might provide benefits beyond any generic anti-US sentiment as well. Lots of excellent work happening there at the moment.
Tongue in cheek - kind of? If a country can try banning the export of cryptography, why not try banning the export of programming languages to say China? After all US companies make lots of important ones!
Our government has repeatedly made it policy to block access to software of domestic origin through export controls [0] [1]
Historically I'd argue most nations could trust the US government only to wield economic sanctions against our adversaries, but the current administration has made all nations our adversary.
I can see a real possibility of the current administration enacting export controls on the European Union for a perceived slight against the President, and Congress will not stop him. For example, if crates.io is an American-based software service, there is a real possibility that the US could ban the owners from allowing access from EU IPs.
Granted, the same is true of GitHub, npm, freaking google... but the tl;dr is that I don't think you can trust us today or tomorrow. I don't trust my government, why should you?
> Historically I'd argue most nations could trust the US government only to wield economic sanctions against our adversaries, but the current administration has made all nations our adversary.
US senators are threatening sanctions against the German harbor town of Sassnitz https://www.dw.com/de/us-senatoren-drohen-sassnitz-zu-schade... to prevent the nord stream gas pipeline from being built. They’d prefer if germany bought liquefied gas from the US. (It’s a bit more complicated than that, but the threat is a new escalation)
All the countries from the first link have EU sanctions as well, and as long as the projects are on GitHub it won’t really make a difference even if there weren’t.
I’m as appalled at our government’s foreign policy as the next person, but I would bet my bottom dollar on there not being a blanket government mandated EU IP ban in the next four years regardless of the election results. There’s a long way between tariffs and targeted export restrictions for the EU, and the lobbying to NOT cut off all US internet businesses from the EU would be insane.
You have far more faith than I do. If Trump wins a second term, they'll make a big show of negotiating a trade deal with Britain and the EU after Brexit is realized.
If those negotiations break down they may use economic sanctions to show they mean business.
> I can see a real possibility of the current administration enacting export controls on the European Union for a perceived slight against the President, and Congress will not stop him. For example, if crates.io is an American-based software service, there is a real possibility that the US could ban the owners from allowing access from EU IPs.
This seems incredibly far fetched. Paranoia is a healthy practice but there is a point when it goes too far.
I don't think it is.
(disclaimer: I do live in the EU)
The current US administration is already trying today to force close allies to conform to their will using economical pressure. I can imagine a future where this might escalate, so in my opinion forcing US companies to block certain origin countries if not that far fetched.
There's nothing about privacy that's relevant to the creation of a Foundation here IMO.
On the software patents aspect Mozilla doesn't have any patents it would need to give to the Rust Foundation so I don't see this being relevant either.
It's interesting how many commenters are saying "not in the US". The US is very strong on rule by law with regards to corporate law and nothing has really changed here. The court systems are also quite good.
Only because Switzerland doesn't have the typical 'Foundation' structure as found in the US. For all intents, it's a nonprofit Foundation but since they're now domiciled in Switzerland they use the "Association" nomenclature.
> The purpose of the association is the promotion and development of free or open source hardware and software technologies and applications for use on computer systems with a focus on the development and implementation of a free and open RISC-V instruction set architecture (Instruction Set Architecture, ISA). The association pursues a non-profit and not a financial, self-serving or commercial purpose. For this purpose, the association can, among other things, promote and finance research and development initiatives and other activities and participate in other companies or cooperations that are geared towards the main purpose.
The biggest question I have is whether or not this new foundation will be a 501(c)(3) charity (or European analogue), versus a 501(c)(6) "business league".
The big distinction between the two of them is that donations to a 501(c)(3) charity are tax deductible and therefore may not be used to unduly advantage any commercial entity, while donations to a 501(c)(6) are not tax deductible and thus are unrestricted.
If it's a 501(c)(6), then the foundation will serve its biggest donors first and foremost. In theory, it may also serve the public good — but only to the extent that it is in the interest of those donors.
A reasonable BOD can ameliorate any of the downsides with a (C)(6) quite easily, and while the perception may linger, it's entirely possible and likely that the Foundation will serve the Rust community regardless of whatever legal structure they choose. There are plenty of reasons to avoid (C)(3)s as well if you do want to fund the project with corporate dollars since those contributions are usually routed through an organization's philanthropic arm and usually can't be approved by business unit owners. (C)(3)s also have more stringent reporting requirements which can be a nice 'check' on any abuses but usually result in a lot more overhead.
I've served on a non-profit board (the Apache Software Foundation, which is a 501(c)(3)), and I don't believe that counting on the composition of the board to maintain independence would be reliable. Board members come and go. If you care about independence, it should be baked into the corporate structure.
It is true that it is more difficult to get funds for a 501(c)(3) than a 501(c)(6). That forces the organization to operate lean and constrains possible initiatives (e.g. funding development), but also serves as a buffer against influence.
Paradoxically, a maximally independent organization may serve the interests of the long tail of potential corporate donors, because they don't have to worry that the biggest player in their space will capture it via pay-to-play.
(For those not up on the acronym, BOD stands for Board Of Directors in this context.)
Yeah, no arguments here, all fair points. I guess my point is that the Rust folks may have good reasons to pursue a (c)(6) and I don't think it says much about the future of the project if they go that route. With forethought, you can engineer the board and management structure to really be technology focused and provide in-built protection from 'corporatization' of the project.
Please stop this 501(c)(6) vs 501(c)(3) nonsense, it's just a tax status, the Trump Foundation as a 501(c)(3) and was dissolved, the tax status doesn't imply much outside of it being a non profit...
The most important thing is ensuring that the community has representation on the board and other governance structures. There are some organizations like the Apache Software Foundation that do an OK job at this, there are others that don't even offer projects/maintainers seats on the board.
There are also organizations like the Linux Foundation and Eclipse Foundation which essentially act as "Foundation as a Service" and host multiple foundations in one with different governance structures.
The example of the Trump Foundation's dissolution in fact illustrates that the difference between non-profits is meaningful. Many of the activities of the Trump Foundation would have been fine for a (c)(6). A major rationale for dissolution was inappropriate use of tax-deductible donations.
This is actually good news. Rust was in the Mozilla incubator for the longest time. Moving out signals it’s mature enough to stand on it own. Mozilla has done a great job in incubating Rust. Now is the time for Rust to fly on its own wings.
I want to clarify: The Rust project has been largely "outside" of the Mozilla incubator for quite a while already; with most of the governance being non-Mozilla individuals. The main things Mozilla provided was infrastructure (a lot of which has moved out in the past year), trademark ownership, and paying some people to work on Rust full-time (which many companies do now).
Make no mistake, Mozilla has contributed a lot to the Rust project, but the particular stage of maturity you mention was achieved some years ago :)
Yes. Well said. It's understood that Rust has been in matured state for a long time. The current gesture is more of rhetoric signal than the actual stage of maturing.
Why are Mozilla clearly so closely involved in the announcement of the creation of a foundation? To be honest it does come across that the desire to state that there is distance between Rust and Mozilla somewhat exceeds the actual distance. Certainly it's understandable, based on this language, that GP understood the moment of separation to be more "now" than "several years ago".
> Mozilla and the Rust Core Team are happy to announce plans to create a Rust foundation. Our goal is to have the first iteration of the foundation up and running by the end of the year.
(Later changed to
> the Rust Core Team and Mozilla are happy to announce plans to create a Rust foundation. The Rust Core Team's goal is to have the first iteration of the foundation up and running by the end of the year.
The text was changed due to feedback provided elsewhere in this HN page.
The blog post was drafted by the core and foundation team, however we did get sign-off from Mozilla on it.
Mozilla currently owns the trademarks that the Rust foundation plans to take ownership of, so they have to be involved to some extent. They have agreed to transfer it as mentioned in the blog post, and are going to work with us to make that happen.
The Rust project as an open source project with open governance has been pretty independent of Mozilla for quite a while now. However, Mozilla did provide some crucial services including trademark ownership, which is _extremely_ relevant to the discussion of forming a foundation.
Trademark ownership and is rarely impactful to the day-to-day workings of the Rust project, which is why I consider these irrelevant to whether or not Rust is still being "incubated" by Mozilla.
To be clear, I don't have any real concerns here, it just seemed a bit inconsistent; the foundation sounds like an important new phase, and I am a very happy Rust user who is somewhat amazed at the extent to which I have come to feel that I can not only use it in places where a compiled language obviously makes sense but that it is convenient enough that I could actually replace some of my prior usage of dynamically typed/interpreted languages.
You should setup donations ASAP. I think that now is a good time to do that since a lot of Rust users are somewhat upset by the recent events and would be willing to help out.
Of course that's true for accepting donations, but what about contributions that aren't treated as donations? Or could another foundation receive donations and hold them in trust until the new foundation is able to receive them? Is the new foundation actually expected to be in immediate need of funds such that this would be worth considering?
The Perl Foundation (https://www.perlfoundation.org/) has existed for many years. I've been a board member for a year or so.
We began life primarily to support the YAPC (Yet Another Perl Conference) community-run conferences, but now we also support development of the language itself.
I'm probably just fantasizing, but it would be great the Rust Foundation took over Servo and they built it into its own browser separate from Firefox. ("Separate" as in "different stewardship". I don't mind if Firefox and Servo share some code in the form of library crates.) If there was someplace I could donate to support both Rust and a freedom-respecting web browser, that place would get a whole bunch of money from me.
Improving Rust itself is already a humongous task with no shortage of issues to solve. Taking on something as big as Servo on top would be a horrible distraction.
I'm not clear on the specifics, but will Mozilla continue to finance active development in rust? The announcement is ambivalent on this, could they actually be trying to remove another cost factor from their portfolio?
Mozilla has had to reduce its investment in Rust significantly, but it’s not abandoning Rust. Mozilla has committed to financial and logistical support while we get the foundation up and running, and we expect they will become a sponsor once that is an option.
Abandon as in no longer contributing to the development of the language or as in no longer use it? I find the later incredibly unlikely and the former possible, but also unlikely.
It’s not clear whether they will continue to be assigned to Rust, though. At least, I didn’t find this explicitly confirmed anywhere.
If anything, I’d love to know how many Mozilla employees were working on Rust full-time as their paid job before the layoffs, and then after. I can’t find these numbers cited anywhere.
Pietro’s sibling answer seems to be that Mozilla will transition to be a sponsor — I’d love to know whether this means they will keep investing development time (and how much).
> If anything, I’d love to know how many Mozilla employees were working on Rust full-time as their paid job before the layoffs, and then after. I can’t find these numbers cited anywhere.
I don't understand what this actually means or any implications of this other than the IP being transferred which would prevent Mozilla from shutting it down and the community having to fork under a new name and to also allow monetary donations. Is the long term goal for a foundation like this to eventually hire full time devs?
The trademarks being transferred is the primary implication right now.
Part of why we've been discussing this so long and not made moves yet is that there are a lot of things that a foundation could do, like hiring devs. But we're unsure what we would want to commit to it doing. Hiring devs has some big advantages, but also a lot of disadvantages too. For now, we're focusing purely on the trademark ownership part, as a sort of MVP.
> Hiring devs has some big advantages, but also a lot of disadvantages too.
The Blender Foundation has been employing devs for, like, forever -- they're (usually) the ones who fix all the little things since everyone else wants to work on 'more cowbell'.
Maybe shoot Ton Roosendaal a friendly email or something as he has years of experience in this matter?
> Hiring devs has some big advantages, but also a lot of disadvantages too
I'm curious on what or those from your point of few.
From the disadvantage point I can see: It won't be easy to figure out what they should work on. I think if you have a foundation which has sponsors that pay for dev-time, those might also want to see the issues and features prioritized that they are interested in. However devs might have different desires on what they want to work on. That's kind of true for every environment, but I guess it might even be more true in an environment like Rust which attracts a high amount of smart, creative and passionate people.
Now this can obviously be dealt with via project management. But I think that still might not exactly be what some of the Rust contributors hoped to get out of a foundation (getting paid for working on stuff they like).
It is nice that Rust is getting an independent foundation but I hope it will not be too independent.
My idea of programming languages is that they are better when they are designed with their use case. And in the case of Rust, it is to make a web browser engine. I don't know what the current situation is with Servo but I think that it would be a good thing to keep a privileged relationship between the Servo team (or what is left of it) and the Rust foundation.
Rust is not for every project, in fact it is terrible for many projects, but if your project has the same needs as for a web browser engine, then it is great. By making the foundation too independent, we may end up with a monster (no need for another C++), a useless "jack of all trades, master of none", or simply lacking features that are essential for making a good web browser because it is not good enough for some committee.
There is an implicit assumption in your post that a foundation would have governance over the language itself. The Rust project is already organized with a pretty de-centralized team structure; the language team gets to decide what's in the language, and nobody else. I'm on the core team and I don't get to make these calls!
So, I don't think you have much to worry about there. :)
It may be a controversial opinion, but I actually agree.
Languages need a strong direction, with specific goals in mind. Otherwise, they just wind up being a little bit of everything and not really great at anything (or wind up with a dozen duplicate implementations of the same idea).
I don't think Rust should be limited to just a browser engine language though, multiple companies are already looking at it to 1:1 replace some C++ for its security improvements without sacrificing significant runtime performance.
I agree. Something like Rust Language Foundation has both the clarity and gravity that it deserves. We will always have crates and components for fun names.
The "Ferrous Foundation" is appealingly alliterative. But it also makes it easier to expand the focus beyond Rust — which is probably a negative, because it makes it harder to concentrate on core competency.
Every foundation is engaged in a perpetual struggle over whether to expand its mission. But in the vast majority of cases, mission creep weakens the organization's ability to achieve its primary goals.
(Crafting a concise mission statement will help inoculate against mission creep, and should be done regardless.)
That is true. I'm not sure how it's relevant though. If we're trying to be independent, the status of Mozilla is not really of note, no? (And all Rust stuff is under the corporation, not foundation.)
The creation of an independent non-profit foundation that will legally own and control all digital and physical property associated with the Rust language (from the Rust name itself to domains like crates.io) is a great development for the language.
IMHO, this was overdue: Rust's impact and influence today is global, and extends well beyond the confines of Mozilla. Many businesses and organizations building mission-critical applications with Rust will now be able to support and influence development of the language more directly through the new foundation. Long term, I have an inkling that it will lead to greater/broader adoption of Rust.
Yeah, it's just really hard to get things right. And time spent managing a foundation's business takes time away from managing the project itself, at least in the beginning, where there is significant overlap.
Basically, bootstrapping is always a hard problem :)
When it comes to the Rust project: it was already well outside the confines of Mozilla, with an independent leadership team, and with a lot of the infrastructure being run by other companies (Github/Microsoft for CI, Amazon for storage, etc)
The main stuff that was left over was the trademarks, domains, and some infrastructure.
This post will trouble many Rust fans, tempting them to "downvote it to oblivion", because it voices uncomfortable truths.
This is a critical time in Rust's history, and choices made now will determine whether Rust succeeds and achieves a long-lasting and influential presence, or fades into fond obscurity like the overwhelming majority of its kin. Make no mistake, the latter course remains very, very possible. At their peaks, no one would have believed this fate would take Common Lisp, Ada, Oberon or Pascal. Each had a vigorous ecosystem and numerous devoted users and implementers. Each still has devotees in its obscurity, but each's present obscurity is undeniable.
These truths must be voiced, and acted on, if Rust is not to share the fate of those once equally-vigorous languages.
The first uncomfortable truth is that the numbers matter. It is not enough, for a language to succeed, to gain new users, trying out the language, at a satisfying rate. They must also remain users, and must find, before they give up, that early difficulties adjusting fade. They must find the language better, on all the axes that really matter, for the problems they face, than what they have used before. Hard as it may be for it fans to believe, this is not the universal experience. Rust is stronger on some axes than the languages people come to it from, and weaker on others. It must become strong on all.
The borrow checker, as it is implemented, ultimately turns away too many new users before they achieve proficiency, and burdens exploratory designs when they are least ready to carry it. The slowness of builds is an enduring impediment to production use that will not continue to be excused. The NPM-like ease of falling into unwise dependency on abandoned library components, and the permanence of unfairly-claimed names in the repository, are traps that lead to troubling experiences. Scrupulous users will identify other problems.
To achieve maturity is not the norm, for any language. It is, it must be repeated, a game of numbers. A large-enough number of people must be motivated to try it. A large-enough subset of those must find enough to like to motivate them to continue learning. Enough of them must stay long enough to learn enough to do their regular work in the language. And, enough of those still on board must find a place where they can actually do their work in the language. If any of these numbers is not large enough, for long enough, the language will unavoidably fade into obscurity, deserved or not.
As popular as Rust already is in some pockets of the wide internet, these numbers are not now large enough for Rust to endure and not fade. The window during which its newness and trendiness are enough, on their own, to motivate people to try it is rapidly closing.
While nothing can guarantee success, many things can guarantee failure. One of the latter would be not to change what keeps the numbers down. Needed changes will be unpopular with self-selected early adopters who overcame difficulties and have little contact with those who did not, and left; but change is necessary.
The first and most uncomfortable change needed is to make the borrow checker less draconian. Allow beginners to know how many violations they have, yet run. A running and useful program motivates improvement at every level, ultimately including rigor. Dead code benefits no one, howsoever clean it is.
Beginners exploring the language need early, even if partial, successes. Everyone exploring the design of a new program has far more urgent concerns than borrow rigor. Those can always be returned to, in time, and will be if they remain visible. Allow libraries with violations to be used, and even to be shared, unguarded by "unsafe" blocks; still noting, in each build, how many violations remain.
Rust's reason for being invented was to displace unsafe languages from use where they are most harmful, most particularly C. In this it is, however resolutely, failing. The C users who remain have seen many, many languages rise to popularity and fade away, and have resisted all temptation. They are self-selected to continue resisting temptation. Most remaining C users love it for its faults. They are proud to overcome C's faults, individually, without help.
Most former C users who might have jumped already did. Many jumped to C++. Coding C++98 is enough like coding C that the merits of Rust, particularly its modernity and its initial simplicity, had appeal. But Rust has become complicated, and C++ has evolved, through C++11, C++14, C++17, now C++20, soon 23, and 26. Coding C++20 is little like coding C++98; 98's temptations to unsafety do not appeal.
Furthermore, C++ is and will remain a much stronger language than Rust for capturing semantics in libraries. Moving to Rust means a dizzying step down in expressive power, both in ability to capture semantics in libraries and to use the uniquely powerful libraries it has enabled. While such power is needed in a minority of applications, it is needed badly there. C++ is not being displaced by Rust.
New Rust users are coming, predominantly, from other languages instead, notably Java and Go, and scripting languages. Rust is an overwhelmingly better design than the first two, and runs overwhelmingly faster than the others. But its safety, when borrow-clean, does not distinguish it from them. The appeal of safety is not what wins the users it gains today.
Rust wins users from these languages by being a better experience. The borrow checker is just tolerated, in exchange for the language's modern and substantially more powerful design, including its Drop trait that enables programmed control of resources, its default const and default pass-by-move semantics, and the careful, comprehensive and coherent design of its built-in and core library types.
If Rust succeeds and does not fade, it will be by playing to these strengths among current users of these other languages, but moreso by resolving its weaknesses. The painfully slow compiler can and must be replaced, if it cannot be fixed. The library ecosystem must be made a strength, not a cause of weakness and fragile dependency. And the borrow checker must become an aid to rigor, not a gauntlet for beginners to suffer and, too often, fall to.
Rust's future will be assured only when more complain of its flaws than boast of its successes.
Thanks for all the thought you put into this post.
While I think some of your points have value, I'm not sure this is best time/place to have this discussion. Perhaps /r/rust or a blog post might allow you to have the discussion you are hoping for.
Please, turn this into blogpost. I’ve had very similar feelings for some time.
I tolerate the borrow checker because I want to use Rust’s other features. I think Rust with no borrow checker is much closer to my dream language than it is right now. Rust with an optional borrow checker is in fact even better.
What would Rust without a borrow checker look like to you? Syntactic sugar or automatic wrapping of types in Box and Arc as appropriate? auto-cloning of !Copy types?
I’d start from allowing multiple mutable references. Second would probably be something about relaxing lifetimes but I can’t properly articulate it right now.
Start by allowing anything at all: not ignoring it, but reporting it. And continue reporting it, until it is wrapped in "unsafe" or fixed.
It would not be a mistake to report the total number of "unsafe" blocks harbored in the program when it is linked, from all sources, alongside the live borrow violations. Safety, like development, is a process, not an endpoint.
> New Rust users are coming, predominantly, from other languages instead, notably Java and Go, and scripting languages
True
> The appeal of safety is not what wins the users it gains today.
You are wrong here, mate. If borrow checker prevents mass adoption, I am okay with that. I have dabbled enough problems in poorly written code by "full stack" developers who write code by combining different blog-posts from Medium without any thoughts to underlying memory model, that I am happy that some language feature prevents these folks to take up a Language.
Does it seem tone-deaf to anyone else that this blog post is clearly written from the perspective of and to be interpreted as the opinion of the Mozilla project leadership and not the "Rust Project"?
I mean, if there's any time where you want to be clear about the distinction it would be now, right? What people who really care about Rust need to know now is that it will prosper outside the control of its corporate backer.
Telling us the Mozilla still supports Rust (at a time where it's by definition true that it is reducing its support) is communication that should come from Mozilla, not rust-lang.org.
> is clearly written from the perspective of and to be interpreted as the opinion of the Mozilla project leadership
Could you say a bit more about what makes you read it like this? It is from the Core Team, one of which is employed by Mozilla to work on Rust, and one of which was laid off and contributed to Rust in their spare time. (out of 9 people)
Mozilla is an important part of this transition story, which is why we included the stuff about them; there's no way to ignore the intellectual property owner when discussing how that property will be transferred to another entity.
While I don't share the sentiment of the OP, I would guess lines like this may be the key for them:
>Mozilla and the Rust Core Team are happy to announce plans to create a Rust foundation. Our goal is to have the first iteration of the foundation up and running by the end of the year.
I read this as "Mozilla is currently still largely in control. This is the moment where they will cede to the new, more independent, foundation." But the fact that it follows "Mozilla and the Rust Core Team" with "our" may taint the rest of the use of "our" throughout the post for others.
I see! Thank you. We spent a lot of time going over every word in this post, so I am not sure if we can edit that to make it more clear, but I'll take a look.
What would you like it to read? There's a collaborative process going on and Mozilla is supporting us. There's no reason for us on that angle to frame it any other way.
Mozilla has been holding the Rust trademark because of history, but also in trust.
Yes, you can apply a negative reading to this, but this is a really big jump. You could also be happy about the fact that not all is broken.
I was trying to step into the shoes of a less generous reader there, sorry if that wasn't clear. I think the post was clear and I agree. Mozilla is still a massive steward and this post was made to directly address that.
I read it as "Mozilla holds all the legal assets and will work with the new foundation to transfer them" – so that's probably trademarks, logos, infrastructure, etc.
This is a standard thing in English academic grammar. When you are listing multiple entities, you list them alphabetically. That's the most likely the reason for how it was written. Academic papers list all authors alphabetically and papers are named are named after the first few authors.
> Does it seem tone-deaf to anyone else that this blog post is clearly written from the perspective of and to be interpreted as the opinion of the Mozilla project leadership and not the "Rust Project"?
I didn't get that impression while reading this blog post. Is there something in particular that gave you this impression? (Mozilla doesn't really have any leadership role in Rust, as I understand it)
At this point those two might groups overlap substantially , also rust may not want to antagonise Moz or anyone else , while support is reduced they still assistance until they can stand on their own feed the language maybe reflects that.
Oh, I honestly never expected that line. Good job, and good luck to the foundation efforts.