Linked by Mark Tolliver on Thu 13th Sep 2007 08:14 UTC
Thread beginning with comment 271062
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/25/13 0:45 UTC
Linked by Thom Holwerda on 05/24/13 23:59 UTC
Linked by Thom Holwerda on 05/24/13 22:33 UTC
Linked by Howard Fosdick on 05/24/13 21:41 UTC
Linked by Thom Holwerda on 05/24/13 14:44 UTC
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
More News »
Sponsored Links



Member since:
2006-12-28
...but not so much for system engineers and administrators. I can see the mixing of code in a proprietary project being of grave importance and appreciate the author's warning though.
I understand the problems with OSS projects no longer being updated but for me, when I install an OSS server product, it always comes with it's own form of update service.
For example, I run Sun's Java enterprise system which contains many OSS components (Apache and OpenSSH to name but two). When any one of these components get updates, I don't download the latest source code, I wait for Sun to issue it's next security patch or fix pack.
The same goes for any Solaris or Linux installation I might be running.
On the other hand, while I was working closely with our internal development team, I found the amount of OSS software used in any given project to be huge. I'm glad none of these projects are ever intended to sold as proprietary software as the sheer cost of replacing all those components would be staggering.
All in all, it's a good article with some excellent ideas about avoiding code 'cross pollination'.
Edited 2007-09-13 15:20 UTC