Uber coders also know when to trash old code rather than update it to new standards. The culling of the herd to fit the available resources if often more important than keeping the sickly and poorly written code alive. It optimizes resource use for everybody: the code is smaller, less of it has to be maintained, etc. These skills are often overlooked as well since they are devlishly hard to measure.

This is absolutely critical for small companies to have. Otherwise the code grows faster than their ability to keep it up to date. They need more people doing more work than is necessary. This can push the small company over the edge of profitability (either there are too few people to do the work needed so sales suffer, or there's too few sales to support all the mouths needed to keep this extra code around).

Another trait of uber-coders is they have a global view. This global view often allows then do things much more efficiently because they know exactly the right level to do it. They don't have to do a lot of extra work "just in case" at the wrong layers. Poor programmers do the extra work and justify it as being careful, when they are only being wasteful to the project.

Large companies could benefit from these traits, but the way management is setup makes it difficult to properly measure these skills, reward the teams that practice them and to save the company money (which, in theory should be split between the company and the uber-coders). Sometimes the skills are recognized outside of the normal set of metrics, but often times they are not.

finally, if you think you are an uber-coder, it would be in your best interest to also be an uber-communicator. Not that you have to communicate a lot, but often times the right communications at the right times help more than huge reports that nobody does more than glance at anyway. The best prose for me often times is cut down by 1/2 from my initial drafts and 3/4 rewritten, but everybody is different. The uber-communication skills is what will get you noticed, promoted and have raises go your way. This is especially true if you can make other people more productive by merging the uber-coding and uber-communicating roles.

Even this article points out that btrfs isn't ready for production, while ZFS is in production systems today. How does that make brtfs better? Does it have a better license? Does it have more potential? Maybe. But that alone doesn't make it better today.

It all depends on what FreeNAS' target market is going to be. Is it going to be old desktop machines that people recycle into NAS boxes, or will it be the large variety of NAS boxes that are found in the wild today. If the former, then the switch to Linux buys you nothing. Really, FreeBSD and Linux run the same on x86 hardware (sometimes one is faster, or the other, or there's an issue that keeps one or the other from running, but in general both just work damn well). If the target is the latter, then Linux might have a small edge, but only because the FreeBSD project hasn't focused on the proper packaging of FreeBSD for an embedded system that has the tight memory constraints that the non-intel NAS boxes have. Many companies have climbed this hill, but there's nothing that's been standardized enough to be ready to include in FreeBSD (although both NanoBSD and TinyBSD could be made to work). M0m0wall and FreeNAS innovated in other areas, and this area would be easy to innovate in as well, since the problem is well understood and most of the tools necessary to make it work are already extant in the tree.

Forking FreeNAS may or may not be the right thing to do. It might be better to provide a FreeNAS 0.7 -> NewFreeNAS project that is rewritten from scratch for FreeBSD 8.0 that doesn't suffer from the php interface that replaces /etc/rc.d. That's the main barrier to porting from 7.x -> 8.x for FreeNAS (and m0m0wall). It would likely be faster and simpler to go that route and fix whatever issues come up. This would allow one to migrate to better http technology that puts less in the server and more on the client in javascript/ajaxish/etc things anyway. This would allow users to continue to use FreeBSD's solid ZFS base as well as have a solution that's here today rather than waiting for Linux to catch up with its reimplementation of zfs :)

Warner

I've been involved in an open source project (FreeBSD) for a long time. There have been a number of complaints about GPL violations in the past. These complaints are usually made in private. That helps a lot. Often times the compaints are wrong (The GPL code that was alleged to have been taken and improperly included in FreeBSD turned out to have been taken from BSD 4.4lite and incorporated into the GPL code was the worst example). There have also been cases where the same code appeared in drivers in multiple places. Again, that wasn't a GPL violation because both places took the code from a common data sheet. Sometimes supposed violations are cleaned up out of an abundance of caution: it isn't clear the code is improperly included, but the code in question is easy to rewrite and/or icky to start with.

There are also times where GPL code is improperly imported code from BSD as well. Even when these are found it isn't always worth it to complain. Sometimes the gain from complaining is so small that it is easier to just let the folks use the code and not worry too much about it. Sometimes having the code out there and improperly licensed is better than getting it removed from the code base.

In general, I've found that most people that aren't lawyers don't know the law or the provenance of the code very well. By complaining in private, you get a chance to learn a bit about both. You also give people a chance to make it right. With large open source projects, the chances for accidental mistakes are high. The projects are generally keen to avoid the mistakes in the first place, and even keener on making sure that they get ironed out after the facts. Turns out most companies have a similar view and will do the right thing when asked (but sometimes it takes a little time, which is OK: the GPL never said instantly on demand).

Of course, this begs the question about the validity of the License to use GPL software after a violation has occurred, the scope to which license is lost, how to get it back, etc. GPLv2 is silent on the issue, while GPLv3 gives you one shot to fix it (but that's likely insufficient for large companies that have multiple product lines done by disjoint sets of people all of whom aren't educated on the finer points of incorporating GPL software into their products).

The GPL has been held to be valid a number of times in a court of law in different countries. This is true. However, the lawyers didn't say it was invalid, so it is also irrelevant.

They said that it was unclear what is meant by derived work, and therefore it was unclear what could be licensed with a different license when combined with GPLv2 software, and what had to have a GPLv2 license. It all hinges, according to them, on if one takes an expansive view or a narrow view reading of the independent work clause. This is something that's very much up in the air right now, with many people playing fast and loose with the rules. You have a continuum of behavior here. Everything from "I wrote this file, therefore I don't have to license it under the GPL, even though it is linked into the kernel" to "I GPL'd the shims to my proprietary driver, but not the driver itself." The authors point out it is unclear how much of this behavior is safe and how much isn't. The ambiguity and shifting attitudes about what is and is not a derived work creates risk and uncertainty when using this license.

They claim GPLv3 doesn't suffer from these weaknesses.

Nowhere to do they claim the GPLv2 is not legally valid. Just that ambiguity exists,

This assumes that those binaries are recompiled.

assert(sizeof(foo) == sizeof(bar)) (or the compile time variations) is just as effective...

I had a Libretto 50CT, which pre-dated the 70CT. I loved the size (it was almost exactly the same size as a VCR tape) for portability. Had a slow Pentium processor in it. I dropped mine and the warrantee couldn't fix it so it was replaced by a Sony that I didn't like as much.

The keyboard was small, and kinda hard to type on. But I got used to it. I did a lot of development on FreeBSD PC Card and CardBus stacks on that little box. I do miss it, except when I need to see a lot of data on the screen. Then I like my newer laptops better...

There was also this crazy libretto mailing list for hacking the suckers. People posted how to overclock them by soldering and removing 0 ohm resistors, how to build car power supplies (I built one and learned a lot), how to add brightness enhancing films, how to hook up better microphones, etc. These things found their way into lots of small environments before the Soekris boxes became popular for such things.

But having used it, I do know what the limitations of the new crop of netbooks have. They are kinda cool, and all run FreeBSD very well, but I haven't jumped in yet... My life has changed a lot since I had the Libretto and I'm no longer sure it is a good fit. I like the bigger text on my "newer" laptop, but miss all the quirkiness of the Libretto....