Novell need not waste time and money picking thru Unix code to open source it... The real win for the open source movement would be to make sure that Unix IP could not be used against Linux ever again. Novell could simply and easily transfer the Unix IP to a trust that they setup whose irrevocable purpose would be to sit on the Unix code, never to claim copyright or patent infringements ever again.
I've been at a software development shop that obtained ISO-9000 certification while I was there, mostly just to be able to bid on DoD/GSA (U.S. government) work.
Some ISO 9000 history: Originally, ISO 9000 was for manufacturing. Each station had a written procedure, was detailed enough for even a blue-collar, high-scool dropout, and it had few variables: make 100 ("how many") widgets that are green ("color"). So, not much variability. In 2001, ISO 9000 tried to include service industries, like software development. They did this mainly by adding processes. In ISO lingo, processes are meta-procedures, in which you can make a hierarchy of processes with procedures at the tree leaves.
So back to concrete recommendations. There are 2 key things to remember:
(1) Document your current processes, don't write up huge procedures that you don't really do. I assume that you use some sort of basic software methodology, e.g. waterfall or RUP or JAD or Agile or XP. Document, at a high, bullet-point level, the sequence of steps for requirements gathering, analysis, design, unit testing, integration testing, user-acceptance testing, etc. Don't get into how you actually code daily.
(2) Make sure that each procedure fits into the context of the plan-do-check-act cycle that ISO-9000 (and Six Sigma and PMI) loves. This fits well in the iterative software development methodologies like Agile and XP that get early and frequent customer feedback.
To get the initial certification, the auditor will check to make sure that all your procedures and processes are documented. Then for the next annual audit, he'll check that you are actually using your documented procedures/processes. Then still later, he'll look to see that you are performing the check-act feedback loop of the plan-do-check-act cycle (remember, ISO 9000 is really about Quality Improvement).
To make all this easier, I highly recommend 2 things:
(a) Find a Content Management System (CMS) package to store and management your documents, in particular one that has an approvals-based change-control workflow. There are many open source ones.
(b) Hire an ISO 9000 consultant. This will reduce confusion considerably. Make sure you get one who isn't from the old manufacturing school where procedures had to be heavyweight and inordinately detailed for the high-school-dropout blue collar workers, i.e. make sure he understands knowledge workers and service industries. Also make sure he's comfortable with using electronic document storage systems.
I read that Darwin has trouble scaling thread concurrency. Maybe Apple should just switch to Solaris, either licensed or OpenSolaris, and get ZFS with it. (Of course they would still run the MacOS personality and GUI environment on top of it.)
There are really two separate questions to allowing OSX on non-Apple PCs:
(1) Is is technically feasible? Yes, but it would be terribly expensive in both development & support costs to get OSX to run (particularly drivers) on all the same PCs that MS-Windows does. But that doesn't keep Apple from limiting the hardware it supports to only the most recent hardware (non-legacy) from a limited number of vendors.
(2) Does it make financial sense for Apple to do it? Apple makes about $60 profit from every Mac sold (5 million annually, see their latest SEC filing), but could make $90 from every copy of OSX sold (70% of 200 million annual PC sales worldwide in 2005), then Apple would make $12B/year profit instead of its current $2B/year. Even if MS still kept 50% of the OS market, Apple would still make $6B instead of $2B. The vast volume outweighs the lower margins. Seems to me like a straightforward decision for Apple.
Absolutely right. There are really only two primary points to consider in the decision whether and where to get an online degree:
(1) Are you looking for a prestige degree that will get you more money right out of the gate, or are you looking for a checkmark on your resume that will get you past the HR goons into job interviews? If the latter, an online degree will suffice.
(2) Is the school accredited? Even if a school claims to be accredited, make sure that the accrediting body is recognized as valid by the U.S. Dept of Education (check at www.ed.gov).
I always just tell a new employer that I contribute on my own time to open source projects, so I need any code I write outside of work to remain my own. That seems to make sense to managers, so a few line-outs of the offending verbage in the contract is easily accepted. Heck, I've worked two places where, when I made the same objection, they pulled out a second version of the standard contract that already incorporated the change!
Slashdot Mirror
Novell need not waste time and money picking thru Unix code to open source it ... The real win for the open source movement would be to make sure that Unix IP could not be used against Linux ever again. Novell could simply and easily transfer the Unix IP to a trust that they setup whose irrevocable purpose would be to sit on the Unix code, never to claim copyright or patent infringements ever again.
I've been at a software development shop that obtained ISO-9000 certification while I was there, mostly just to be able to bid on DoD/GSA (U.S. government) work.
Some ISO 9000 history: Originally, ISO 9000 was for manufacturing. Each station had a written procedure, was detailed enough for even a blue-collar, high-scool dropout, and it had few variables: make 100 ("how many") widgets that are green ("color"). So, not much variability. In 2001, ISO 9000 tried to include service industries, like software development. They did this mainly by adding processes. In ISO lingo, processes are meta-procedures, in which you can make a hierarchy of processes with procedures at the tree leaves.
So back to concrete recommendations. There are 2 key things to remember:
(1) Document your current processes, don't write up huge procedures that you don't really do. I assume that you use some sort of basic software methodology, e.g. waterfall or RUP or JAD or Agile or XP. Document, at a high, bullet-point level, the sequence of steps for requirements gathering, analysis, design, unit testing, integration testing, user-acceptance testing, etc. Don't get into how you actually code daily.
(2) Make sure that each procedure fits into the context of the plan-do-check-act cycle that ISO-9000 (and Six Sigma and PMI) loves. This fits well in the iterative software development methodologies like Agile and XP that get early and frequent customer feedback.
To get the initial certification, the auditor will check to make sure that all your procedures and processes are documented. Then for the next annual audit, he'll check that you are actually using your documented procedures/processes. Then still later, he'll look to see that you are performing the check-act feedback loop of the plan-do-check-act cycle (remember, ISO 9000 is really about Quality Improvement).
To make all this easier, I highly recommend 2 things:
(a) Find a Content Management System (CMS) package to store and management your documents, in particular one that has an approvals-based change-control workflow. There are many open source ones.
(b) Hire an ISO 9000 consultant. This will reduce confusion considerably. Make sure you get one who isn't from the old manufacturing school where procedures had to be heavyweight and inordinately detailed for the high-school-dropout blue collar workers, i.e. make sure he understands knowledge workers and service industries. Also make sure he's comfortable with using electronic document storage systems.
I read that Darwin has trouble scaling thread concurrency. Maybe Apple should just switch to Solaris, either licensed or OpenSolaris, and get ZFS with it. (Of course they would still run the MacOS personality and GUI environment on top of it.)
There are really two separate questions to allowing OSX on non-Apple PCs:
(1) Is is technically feasible? Yes, but it would be terribly expensive in both development & support costs to get OSX to run (particularly drivers) on all the same PCs that MS-Windows does. But that doesn't keep Apple from limiting the hardware it supports to only the most recent hardware (non-legacy) from a limited number of vendors.
(2) Does it make financial sense for Apple to do it? Apple makes about $60 profit from every Mac sold (5 million annually, see their latest SEC filing), but could make $90 from every copy of OSX sold (70% of 200 million annual PC sales worldwide in 2005), then Apple would make $12B/year profit instead of its current $2B/year. Even if MS still kept 50% of the OS market, Apple would still make $6B instead of $2B. The vast volume outweighs the lower margins. Seems to me like a straightforward decision for Apple.
Absolutely right. There are really only two primary points to consider in the decision whether and where to get an online degree:
(1) Are you looking for a prestige degree that will get you more money right out of the gate, or are you looking for a checkmark on your resume that will get you past the HR goons into job interviews? If the latter, an online degree will suffice.
(2) Is the school accredited? Even if a school claims to be accredited, make sure that the accrediting body is recognized as valid by the U.S. Dept of Education (check at www.ed.gov).
I always just tell a new employer that I contribute on my own time to open source projects, so I need any code I write outside of work to remain my own. That seems to make sense to managers, so a few line-outs of the offending verbage in the contract is easily accepted. Heck, I've worked two places where, when I made the same objection, they pulled out a second version of the standard contract that already incorporated the change!