> Out of USD4.5MM of revenue for the PSF in 2019, around 63% of it came from PyCon. USD1.9MM was the costs of having PyCon, which means that for every dollar spent on PyCon, the PSF gets back 1.50 dollars.
There's an ongoing discussion about potential adoption into upstream, though.
The thing here is: it would be harmful if we, Ferrous Systems, claimed or even be confused with a more general Rust spec. That's a) the privilege of the Rust project and b) problematic if consumers were to understand it that way.
Doesn't Rust have a Reference manual already? A "spec" just wouldn't be very meaningful given the lack of independent implementations. But to the extent that the reference manual doesn't suffice for documenting the language, that's a defect which could and should be fixed.
The manual isn't directly consumable by formal processes. The compiler design doesn't have to be influenced by a specification, but it does have to be described by one.
On this topic (certified libraries) I suspect an interesting evolution might happen: by observing how you guys at Ferrous achieved this milestone while keeping a consistent openness, other actors (companies, consultancies and academic institutions) start seriously thinking about the possibility of contributing with high quality and certified libraries for a lot of scenarios. In other words I’d look at this as a milestone that opens to new and disrupting ideas
That matches our experience. They were super pragmatic. Also, their feedback was tough, but always technically grounded and from the perspective of "is the user always well informed?".
It's certainly an unusual pricing style, but people grok it and appreciate it. Also, note that this is for the "quality managed" version - additional support and documents that I sign off for safety (so enter a liability) are more expensive.
But on the other side, there's so many that would buy if it were more accessible.
(disclaimer: also a co-founder of Ferrous Systems)
The ISO 26262 is certainly an effective standard. The boxes to tick are of the kind "do you have your requirements written down?" ("will someone later know what this thing does?").
So, we do have to tick boxes, but we're free to pick on how to tick boxes :). What TÜV now certified is that our box-ticking process is fine.
I have absolutely no problem with framing this as box-ticking in some way, but that box-ticking has _meaning_. However, on an existing tool, that means you write the spec (spec.ferrocene.dev) and check if everything has a test implemented. Yep, that's an amount of pretty dumb and repetitive work. And pretty often, on widely-used software, for the happy path, you'll find that it's rather bug-free. So, yes, you tick the box, but you now know that this is in order.
In other cases and on less popular platforms, we frequently find issues like e.g. changes in code size between versions (which could hint to a bug). And it's not just super-niche targets, the last version had a size regression on certain arm targets.
As we're a downstream to Rust, we're actually incentivised to push changes upstream with preference, so yes, we contribute to the general quality of the Rust compiler (also of older versions) and with that to bug-free-ness of the resulting software.
So, we're over here, ticking boxes, informing parties when one box doesn't tick.
https://thefortunate.blog/diversification-is-the-future-for-...
> Out of USD4.5MM of revenue for the PSF in 2019, around 63% of it came from PyCon. USD1.9MM was the costs of having PyCon, which means that for every dollar spent on PyCon, the PSF gets back 1.50 dollars.
https://pyfound.blogspot.com/2020/03/psfs-projected-2020-fin...
Obviously, the revenue has sharply dropped for a time because of COVID, but I'd be surprised if PyCon is run at a loss nowadays.
So you can assume none of your sponsorship money goes to running PyCon.