In regards to your first concern, I'd like to point out a couple of reasons why cetification may be a good thing.
First, as Linux's popularity (hopefully) increases, bringing with it the demand for employees, the tendency for less-than-ethical job seekers will be to inflate their knowledge. While this may not seem like a hard thing to defeat for someone in a Unix shop, for a company without any current Unix knowledge, there isn't a real easy way to figure this out. So the guy gets hired and their first Linux server doesn't work so well. The sad fact of life is that many (perhaps even most) of the people hiring technical people these days don't have the skills to verify knowledge in an interview.
Second, corporate employers have a hard time understanding the idea of "playing with the technology". For them, if you can't point to an actual job where you used technology "X", they assume you don't know it. Telling them that you've been putting two hours a night for the last few years will be met with blank stares. So certification allows those of us not so lucky as to have Linux jobs right now to get some sort of credit for the knowledge.
Unless you are sure that all your coders are doing the former and not the later, any metrics are not worth much. While obviously this is an exagerated example, I have certainly seen stuff nearly that bad in my career. Hell, I once encountered an API (written by a highly paid consultant) used to wrap a set of ISAM routines whose performance was crap and whose functionality was far more limited than the original routines. I was able to improve performance dramatically simply be removing a five thousand line piece of unnecessary crap.
The frightening thing was that it took me two weeks to figure out that it didn't actually do anything worthwhile. Bad code isn't always obviously bad code.
Until a metric can tell the difference between good code and bad code, they are pretty much worthless, IMO.
Obviously the guy has set him self up to ridicule with his Internet comment and yes, obviously his definition of "open source" is, shall we say, a little stretched, however, ask yourself this question:
Do you think that any of the candidates would give you anything other than a blank stare if you used the words "open source" in their presence?
So give the guy an "A" for effort and a "C-" for execution.
The difference is that the GUID makes it easier to prove that he did it to a jury. It is harder to fake a GUID in a word document than it is to forge a usenet header.
It seems to me that the implicity assumption with a lot of that is that there is a "Free Software World" and a "Pay Software World" and never the twain shall meet. This seems to me to be at odds with what I at least perceive to be the goals of the free software movement, which is to, well, make software free. If we work to restrict "free" software to the gurus then it seems to me that it is no longer a movement to make software free and instead is merely a bunch of guys passing around neat programs.
I think that if it ever wants to get beyond that, then people will need to admit that the vast bulk of the population is has no talent for writing programs, does not want to write programs, and just wants to get software to make their lives easier.
The other thing that needs to be admitted is that the vast majority of programmers are going to spend the bulk of their time programming for those nonprogramming users, and when they do so, the systems they use are going to be programming are largely driven by the choices those users make. In other words, a world where only techies use Linux is a world where most of the programming effort is spent on Windows. We can't all program for each other and still make a living.
So me, being a selfish bastard, want lots of nonprogrammers on Linux, as this means that I don't have to spend the bulk of my day writing fucking Windows code.
I think a lot of people are falling for the same bipolar line that Microsoft uses so well to fend off its competition. The Microsoft line is essentially that while Linux (or whatever other OS they are talking about) is more stable, it has less support, and you must be some sort of techie to get it to work, as if stability and user-friendliness are mutually exclusive. They are not. I'd go so far as to say that most of the facets of software that people are throwing around here, "user-friendliness", "configurability", "stability" are not really particularly related at all. It is not particularly hard to add an "expert" mode.
I also think there is a tendency for people to attach themselves to a particular technological system and then view any changes as dangers. But the implication to this is that the system is perfect. There are no perfect systems, however. Linux is not a perfect system. It can be improved. And improving one area, like user friendliness, can be done without hurting another area, like configurability.
One of the things that I like about Linux is its flexability. If I want to make my machine run a Windows-like GUI, or an Amiga like GUI, or whatever, I can do it. I don't have to worry about someone else, who doesn't like GUIs, making that decision for me. And if someone else wants to add packages to make it more configurable, or more friendly, or more whatever, well, more power to them! I don't have to use it...
Which is the whole point, I thought. Not having to put up other people's ideas about what's best.
Slashdot Mirror
Microsoft thinks of nothing but standards. They make their fortune by creating or (more often) stealing other people's standards.
In regards to your first concern, I'd like to point out a couple of reasons why cetification may be a good thing.
First, as Linux's popularity (hopefully) increases, bringing with it the demand for employees, the tendency for less-than-ethical job seekers will be to inflate their knowledge. While this may not seem like a hard thing to defeat for someone in a Unix shop, for a company without any current Unix knowledge, there isn't a real easy way to figure this out. So the guy gets hired and their first Linux server doesn't work so well. The sad fact of life is that many (perhaps even most) of the people hiring technical people these days don't have the skills to verify knowledge in an interview.
Second, corporate employers have a hard time understanding the idea of "playing with the technology". For them, if you can't point to an actual job where you used technology "X", they assume you don't know it. Telling them that you've been putting two hours a night for the last few years will be met with blank stares. So certification allows those of us not so lucky as to have Linux jobs right now to get some sort of credit for the knowledge.
Isn't it amazing how a programmer's productivity goes to shit when you move him from the applications group to the device driver group?
A person's LOC output isn't even going to be consistant from project to project.
The "unit" isn't any good if the unit isn't constant.
The trouble with LOC is that it implies that
strcpy(char*cp1,char*cp2)
{
while(*cp1++=*cp2++);
}
is somehow inferior to
strcpy(char*cp1,char*cp2)
{
if( cp2[0] ){
cp1[0] = cp2[0]
if( cp2[1] ){
cp2[1] = cp2[1]
.
.
.
if( cp2[31] ){
cp2[31] = cp1[31];
}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}
}
Unless you are sure that all your coders are doing the former and not the later, any metrics are not worth much. While obviously this is an exagerated example, I have certainly seen stuff nearly that bad in my career. Hell, I once encountered an API (written by a highly paid consultant) used to wrap a set of ISAM routines whose performance was crap and whose functionality was far more limited than the original routines. I was able to improve performance dramatically simply be removing a five thousand line piece of unnecessary crap.
The frightening thing was that it took me two weeks to figure out that it didn't actually do anything worthwhile. Bad code isn't always obviously bad code.
Until a metric can tell the difference between good code and bad code, they are pretty much worthless, IMO.
The way I undestand it, Apple's imminant Mac OS X is simply NextStep buried deep under a Mac Windowing system.
There is no technical reason that this could not be done for Linux.
I once wrote a thousand line program in one day. About the same period in my life, I wrote a 10,000 line program over a period of about three months.
Guess which one was the one-off piece of crap that I hope no one ever sees and which one was the elegant solution of which I am proud to this day?
was better than
Now I have objective proof! My way is 33% more productive!
Obviously the guy has set him self up to ridicule with his Internet comment and yes, obviously his definition of "open source" is, shall we say, a little stretched, however, ask yourself this question:
Do you think that any of the candidates would give you anything other than a blank stare if you used the words "open source" in their presence?
So give the guy an "A" for effort and a "C-" for execution.
The difference is that the GUID makes it easier to prove that he did it to a jury. It is harder to fake a GUID in a word document than it is to forge a usenet header.
It seems to me that the implicity assumption with a lot of that is that there is a "Free Software World" and a "Pay Software World" and never the twain shall meet. This seems to me to be at odds with what I at least perceive to be the goals of the free software movement, which is to, well, make software free. If we work to restrict "free" software to the gurus then it seems to me that it is no longer a movement to make software free and instead is merely a bunch of guys passing around neat programs.
I think that if it ever wants to get beyond that, then people will need to admit that the vast bulk of the population is has no talent for writing programs, does not want to write programs, and just wants to get software to make their lives easier.
The other thing that needs to be admitted is that the vast majority of programmers are going to spend the bulk of their time programming for those nonprogramming users, and when they do so, the systems they use are going to be programming are largely driven by the choices those users make. In other words, a world where only techies use Linux is a world where most of the programming effort is spent on Windows. We can't all program for each other and still make a living.
So me, being a selfish bastard, want lots of nonprogrammers on Linux, as this means that I don't have to spend the bulk of my day writing fucking Windows code.
I think a lot of people are falling for the same bipolar line that Microsoft uses so well to fend off its competition. The Microsoft line is essentially that while Linux (or whatever other OS they are talking about) is more stable, it has less support, and you must be some sort of techie to get it to work, as if stability and user-friendliness are mutually exclusive. They are not. I'd go so far as to say that most of the facets of software that people are throwing around here, "user-friendliness", "configurability", "stability" are not really particularly related at all. It is not particularly hard to add an "expert" mode.
I also think there is a tendency for people to attach themselves to a particular technological system and then view any changes as dangers. But the implication to this is that the system is perfect. There are no perfect systems, however. Linux is not a perfect system. It can be improved. And improving one area, like user friendliness, can be done without hurting another area, like configurability.
One of the things that I like about Linux is its flexability. If I want to make my machine run a Windows-like GUI, or an Amiga like GUI, or whatever, I can do it. I don't have to worry about someone else, who doesn't like GUIs, making that decision for me. And if someone else wants to add packages to make it more configurable, or more friendly, or more whatever, well, more power to them! I don't have to use it...
Which is the whole point, I thought. Not having to put up other people's ideas about what's best.