What seems really dangerous here is that it's not known that one of the creditors doesn't ~already~ own the source code "just in case". In which case you just have an illegal copy of someone else's property.
I'm sorta new here, so this may have been discussed before...
There seems to be a lot of "RTFA" traffic not only about this article, but also on this site as a whole.
Would it be too much of a burden on the article submitters to submit with their writeups a list of 3-5 multiple choice questions on the salient points of the topic? Would it be too hard to block posters who haven't "passed the test"? Sure, people could get around it by guessing or reading just parts of the article, but at least some wouldn't. I think most wouldn't, but I don't have real proof of that.
This could be used to prevent people from posting AND (just as important) moderating ignorantly.
People could read the article and the postings, but they couldn't make it harder for me to enjoy an informed discussion without being informed themselves.
I've interviewed people for some time now and I think that: 1) Targeted technical grilling helps. Someone who has C++ on their resume doesn't need to know what CONST does, but I'd prefer someone who does. This person might be someone who learns every obscure fact about a language, or they might be someone who learns what it takes to make their code safe. They might be someone who pontificates about sorting algorithms or they might be someone who brings this information to bear effectively. I'll depend on the other parts of the interview to decide how much of each they are.
2) Forcing candidates to explain projects can be very enlightening if you work at it. Ask them to explain in gory detail something they've worked on. It takes patience and technical acumen to do this, but this is a chance to see how they perform at a task they'll need to do over and over again when working with you: explain something to an audience that knows much less about the topic than they do. Give them all the tools they would normally have: whiteboard, pen and paper, etc. When in a comfort zone like this, you'll be suprised how much of their true character comes out. Drill down to the absolute extent of their knowledge about the project. You'll see how much they understand about the project and in making educated guesses about parts you'll see how educated their guesses really are. And you can see if they use "I don't know" when appropriate.
3) You must check references yourself. Or make sure that some you trust with your sanity does it.
4) You must be prepared (as a team) to put a lot of energy into the interview. You have a very short amount of time to get a lot of information at many different levels. Make sure that everyone involved realizes the gravity of the situation and is up for the challenge. I've had to pull people off of interview assignments because of deadline-induced sleep depravation. It's almost definitely the most important thing you'll do that week so make sure you act like it is.
Slashdot Mirror
What seems really dangerous here is that it's not known that one of the creditors doesn't ~already~ own the source code "just in case". In which case you just have an illegal copy of someone else's property.
I'm sorta new here, so this may have been discussed before...
There seems to be a lot of "RTFA" traffic not only about this article, but also on this site as a whole.
Would it be too much of a burden on the article submitters to submit with their writeups a list of 3-5 multiple choice questions on the salient points of the topic? Would it be too hard to block posters who haven't "passed the test"? Sure, people could get around it by guessing or reading just parts of the article, but at least some wouldn't. I think most wouldn't, but I don't have real proof of that.
This could be used to prevent people from posting AND (just as important) moderating ignorantly.
People could read the article and the postings, but they couldn't make it harder for me to enjoy an informed discussion without being informed themselves.
I've interviewed people for some time now and I think that:
1) Targeted technical grilling helps. Someone who has C++ on their resume doesn't need to know what CONST does, but I'd prefer someone who does. This person might be someone who learns every obscure fact about a language, or they might be someone who learns what it takes to make their code safe. They might be someone who pontificates about sorting algorithms or they might be someone who brings this information to bear effectively. I'll depend on the other parts of the interview to decide how much of each they are.
2) Forcing candidates to explain projects can be very enlightening if you work at it. Ask them to explain in gory detail something they've worked on. It takes patience and technical acumen to do this, but this is a chance to see how they perform at a task they'll need to do over and over again when working with you: explain something to an audience that knows much less about the topic than they do. Give them all the tools they would normally have: whiteboard, pen and paper, etc. When in a comfort zone like this, you'll be suprised how much of their true character comes out. Drill down to the absolute extent of their knowledge about the project. You'll see how much they understand about the project and in making educated guesses about parts you'll see how educated their guesses really are. And you can see if they use "I don't know" when appropriate.
3) You must check references yourself. Or make sure that some you trust with your sanity does it.
4) You must be prepared (as a team) to put a lot of energy into the interview. You have a very short amount of time to get a lot of information at many different levels. Make sure that everyone involved realizes the gravity of the situation and is up for the challenge. I've had to pull people off of interview assignments because of deadline-induced sleep depravation. It's almost definitely the most important thing you'll do that week so make sure you act like it is.