About the file systems, hammer was ready in a few months. Since there are flaws with it and hammer2 is the only way to go from that point on, why do people want hammer2 ready in hammer1’s time?

As I understand it (it predates my involvement in the project), the incident was mostly in private emails.

Is it normal for a file system to take 6 years to develop?

https://www.dragonflybsd.org/hammer/

What’s you’re describing sounds similar to how LuaJIT ran.

It was an open source project that took donations to add specific features , in an effort to keep Mike Pall fully employees through sponsorship.

http://luajit.org/sponsors.html

I read this somewhere, and it’s true: if you want to give to an open source project, money is fine, but developers need time more than they need money. This is perhaps why you sometimes see project that ask for funding to give people time away from normal paid work to produce more open source code – turning cash into time. Not saying that we could use that here, though, cause that requires a developer in just the right circumstances.

On CI benchmark & comparison article on current state of FreeBSD vs DragonFly

I’d donate money to be used towards someone setting up a CI environment to run performance test.

Even though it wasn’t what I was talking about when I said I’d like to see a detailed paper on how FreeBSD and DBSD have diverged … I can see how there would be termodous value in this.

As such, how best can I donate so that my donation goes towards exactly this performance CI effort?

https://www.dragonflybsd.org/performance/

In a perfect world, we’d have that sort of testing running near-continuously, for all the BSDs, so we’d have a performance benchmark to work with. I don’t know anyone who has that much time and spare hardware laying about, but dreaming is free.

No good will come from re-hashing the Dillon incident from over a decade ago.

But I do believe a lot can be learn in the technical decisions and outcomes of 2 codes based that were the same and have since gradually diverged.

Maybe I’m crazy, but it’s so rare to be able to study “identical twin” scenarios in life.

And given that DSBD & FreeBSD initially shared the exact same code base – I would find it an absolutely fascinating read to compare the two OSes today on feature, functionality, etc.

That would help. But, I’d argue that it’s an institutional problem, where the tendency for a small group to make nonpublic decisions makes it harder for tough actions (like the source control change) to be made, and for people to handle those changes. Whether that’s a lot wrong or not a lot wrong is probably not the point.

My informal experience with volunteer organizations is that you have to be public (or to overuse the phrase, ‘open’) with decisions, and the decision-making process. If you undercut people’s desire to contribute, you undercut the engine that makes a volunteer project run. I don’t know – does FreeBSD Core still maintain a secret mailing list? Do they have private meetings, or is there an agenda or minutes published? I think there’s a lot of value in these things, and working that way would possibly have avoided some of the following problems that were described.

At first I thought the lwn describes that pdf paper, from that recent bsd conf, that talks about why freebsd is way behind linux. But it turns into some useless recall of controversial events that took place in the not so organized freebsd of the past (it reminds me about the talks inside gentoo, regarding their organization, of the past few years, talks that are still very actual, ps : sorry, I was never interested into this part of the oses I use excepting when these organizational models are strong arguments when it comes to problems that I have to fight in order to be able to keep using certain software packages) instead.