Slashdot Mirror


FreeBSD Foundation Needs Cash For 501(c)3 Status

ashpool7 writes "In an *extremely* late announcement, the FreeBSD foundation has posted in their quarterly newsletter that they're $30,400 short on donations in order to prove that they're a non-profit charity (501(c)3 as they say). If your organization relies upon FreeBSD, it might be a good idea to see if you can scrounge up the $8,000 maximum donation."

4 of 101 comments (clear)

  1. Re:Uh by Anonymous Coward · · Score: 3, Insightful

    Portage might sound good in theory. The childish smileys and colours nothwithstanding, the fact that they do almost zero QA means that portage ebuilds break all the time. The ports system is handled by people who actually know what they're doing. NetBSD's pkgsrc is even better.

  2. Donated... by cymen · · Score: 2, Insightful

    After I read the comments here, I didn't feel so bad not having much to donate. I encourage everyone to support FreeBSD by making a donation. As the other posters have pointed out, every donation is important to keeping the ratio in check so it doesn't matter if you can only give $10 or $20.

  3. Re:I just donated $300.00 by NekkidBob · · Score: 2, Insightful

    That's for linux, BSD does not fall under SCO's bullshit lawsuits

  4. Re:Uh by Anonymous Coward · · Score: 3, Insightful
    Perhaps the main reason for FreeBSD's current problems was a wrongheaded attempt to fill out "feature checklists". If operating system "L" had a certain feature, then reflexively certain FreeBSD individuals would whine "I gotta get me one of them too". It didn't matter if said feature was useful or relevant to FreeBSD. The fallout is that the FreeBSD kernel became more fragile, more brittle, as various add-on hacks were inserted here and there. That was the thorn in Matt Dillon's side which caused him to start his own project, and move away from FreeBSD.

    At the moment it wouldn't hurt FreeBSD if it underwent a major re-write on a new independent branch. Put a feature freeze on 5.x, and continue to try to fix all the bugs in the 5.x branch. The rewrite could take place in a new branch, oh call it 7.x say. It could start by using a lot of the work done in DragonFly. Sadly, other than PHK, only one or two others have a full understanding of the FreeBSD internals anymore. The documentation is way out of date for certain crucial parts of the kernel. The rewrite should take place with a concurrent documentation team which tracked and explained each change and design feature.

    FreeBSD needs to get back to doing it right. There's a lesson to be had from the success of NetBSD too. NetBSD has struck a reasonable balance between the ultra-conservatism of OpenBSD, and the newer wing-dings of FreeBSD. Whatever criticism one might have of NetBSD, you can't fault its clean architecture.