Slashdot Mirror


Michael Smith Leaves Core

Donald Burr of Borg writes "Following in the footsteps of Jordan Hubbard, Michael Smith leaves the FreeBSD core team. Reasons cited are similar to those that jkh gave, including displeasure at the bureacracy and politicking, and FreeBSD not being "fun" anymore."

3 of 61 comments (clear)

  1. Life Moves on by Anonymous Coward · · Score: 1, Insightful

    While I happen to use OpenBSD, I don't think this spells the end of FreeBSD, any more than any of the changes that come to the Tech sector spell the end of a company. What happened to the IBM PC after Estridge was killed in a plane crash? IBM went on. Maybe they didn't _own_ the market in a few years, but hey, they are still around. What about all the top guys leaving Microsoft? Paul Allen, etc. yet they still rake in the bucks.

    With the way opensource, and *BSD is spread out, the exodus of a few "core" members is not tragic. Maybe a wakeup call to get a little smoother on the politics, but that is life.

    Move along folks, there is nothing of interest here, OH WAIT! Is that the *BSD is Dying troll over there? Nah, just some bozo...

  2. Re:Text of the email by Ed+Avis · · Score: 3, Insightful

    Maybe the answer is to break FreeBSD into a 'development' team and a 'packaging' team: the developers can get on with doing cool stuff while the packagers can obsess about things and fight holy wars. Consider Linux as an example. No matter what arguments break out on the Debian mailing lists or which distribution-making companies go bankrupt, this will not cause Linus to resign from kernel development. The kernel developers are shielded from all that. Similarly the gcc, bash, XFree86 and so on developers are not all crowded into one room. The 'single integrated distribution' approach of FreeBSD may produce better quality software (so the BSDers claim), but maybe it doesn't scale so well to large numbers of developers and 'town councils'.

    --
    -- Ed Avis ed@membled.com
  3. Re:Text of the email by Metrol · · Score: 3, Insightful

    Maybe the answer is to break FreeBSD into a 'development' team and a 'packaging' team

    There is a seperation of a sort concerning this already. FreeBSD has a Release Engineering Team that handles just this kinda stuff.

    Consider Linux as an example.

    Although both FreeBSD and Linux share many similar philosophies and practices, you really can't compare the two in this kind of discussion. If Debian and Linux were the same thing, then you would have something to compare. This seems to get lost on folks who spend a lot of time working with Linux. The kernel, userland, packaging, pretty much the whole enchilada falls under the same project. This has a lot of positive benefits to us end user types. As we are starting to see, this also brings a lot of cooks into the same kitchen.

    The 'single integrated distribution' approach of FreeBSD may produce better quality software (so the BSDers claim), but maybe it doesn't scale so well to large numbers of developers and 'town councils'.

    From looking in at this from way out here on the edges I think you may be approaching the problem with the political setup. FreeBSD seems to have set up a republic of sorts without a president. Could you imagine what the US government would be like if only the congress were involved with making laws? No president, no supreme court. The entire system would be brought to a screeching halt, bogged down in committe. That, or whomever was enjoying the majority for the moment would be distorting all the laws one way or the other. It's just not a pretty picture.

    Before FreeBSD should be looking at any kind of delegating any of the sub-projects, there needs to be a hard look given to the over all political structure. There's just too many folks to keep things to purely a commitee kind of thing, but not enough for a governmental style complexity. Somewhere in the middle is where things need to be. Now to see if the core team has the courage and forethought to head down that road.

    --
    The line must be drawn here. This far. No further.