Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror

Open Source In the National Interest 170

Posted by Zonk
from the penguins-for-everyone dept.
munchola writes "A new report from the Department of Defense's Advanced Systems and Concepts Office recommends that the DoD move to adopt open source software and methodologies as well as open standards in order to make the most efficient use of internal resources. According to CBR, the report states that a move to 'Open Technology Development' is not only in the U.S. national interest, but in the interests of U.S. national security. OTD incorporates open source methodologies and open standards, but also takes into account the fact that the DoD has systems that it would rather keep secret."
This discussion has been archived. No new comments can be posted.

Open Source In the National Interest

Comments Filter:
  • Yay! :) (Score:3, Funny)

    by Spy der Mann (805235) <spydermann.slashdot@NOspam.gmail.com> on Tuesday July 11, 2006 @11:16AM (#15698779) Homepage Journal
    Let's have a party! Invite Linus and Stallman! :)

    Bring the fireworks! :)
  • 2 words. (Score:3, Insightful)

    by jellomizer (103300) * on Tuesday July 11, 2006 @11:16AM (#15698784)
    About Time
  • by Recovering Hater (833107) on Tuesday July 11, 2006 @11:18AM (#15698797)
    I foresee the DoD changing its tune after Microsoft drops a few million dollars in the right direction to make this go away. Remember the Open Doc file format drama that unfolded not too long ago? ...where did I put my tinfoil hat again...
    • Yes, but this is matter of "National Security". After all the brawl on wiretapping, they can't take "National Security" that lightly. If they take it back (Open Source, i mean), the DoD is going to lose A LOT of credibility.
    • by Irvu (248207) on Tuesday July 11, 2006 @12:32PM (#15699382)
      ...your rifle was made by the lowest bidder."

      That's a relatively old joke in the Military, and a relatively sick one when you consider the problems of faulty weapons (e.g exploding in your hands). But it points to something pretty basic. When it comes to things the DOD is rewarded for going cheap. This doesn't mean that they won't but they are rewarded for trying. In this gig Microsoft is at a disadvantage as their competitors are a) Free, and b) can be taken under total control by the DOD. Remeber that in-house changes to GPL'd code need not be released. Microsoft on the other hand is likely to worry about in-house changes to their stuff (e.g. document security restrictions for Office).

      While I doubt Stallman will be welcome any time soon keep in mind that Theo De Raadt and the other BSD people have been welcomed (and financed) by the DOD before now. Ditto things like SELinux. In many ways this is only surprising because it took so long for them to say openly.
      • by liliafan (454080) * on Tuesday July 11, 2006 @02:00PM (#15700161) Homepage
        I will believe it when I see it, I just got told in no uncertain terms by our site IT security officer that:

        "Nessus is unapproved software, we only allow xxxxxx(closed source) security scans to lock down your UNIX servers"

        Yes I work for the DoD.
        • I will believe it when I see it, I just got told in no uncertain terms by our site IT security officer

          Is the IP of his personal workstation publicly routable? I'm sure a few people would like to run Nessus...um, I mean a some unapproved software against it.

          How much personal stock in your DOD-approved Vendor of the Month(tm) does your security officer own? Seriously, if there is a widely distributed 100% free tool used by people knocking at your doors Right Now, why is your (in)security officer too stupid..
          • I completely agree, when you have someone that introduces himself as ..... 'a certified ethical hacker' right after mentioning his name and job title, you realise right away this person doesn't know shit about security or the processes needed to achieve it. This guy spends 90% of his day attempting to impress people with his 133t hAx0R skills, and amazing ability to write viruses using 'a package downloaded from the internet'.

            This [independent.co.uk] really isn't a shocker to me!
      • In this gig Microsoft is at a disadvantage as their competitors are a) Free, and b) can be taken under total control by the DOD.

        Yes, with the Free in point a) directly facilitating point b). Financially, the largest cost of any such project is in the systems integration work, leaving no competitor at a particular disadvantage.

        Aside from the positive endorsement associated with this adoption by the DoD, the F/OSS community stands to gain very little: as the DoD aren't in the business of redistributing

    • by Poppler (822173) on Tuesday July 11, 2006 @02:05PM (#15700197) Journal
      I foresee the DoD changing its tune after Microsoft drops a few million dollars in the right direction


      Except a few million is peanuts to the DoD. Their budget for 2006 was well over $400 Billion. I think they're going to make whatever decision will benefit them most, regardless of the cost.
    • You may be correct. After all, the right-wing mantra is that all our problems can be solved by moving programs into the private sector. Microsoft may not even have to drop anymore money on lobbyists than they already do.

  • NEWSFLASH (Score:4, Insightful)

    by P3NIS_CLEAVER (860022) on Tuesday July 11, 2006 @11:23AM (#15698828) Journal
    Govt. IT is highly fragmented. It took 20 years for DOD to switch to all-diesel. How long to switch to open-source?
    • How long to switch to open-source?

      As long as it takes for current systems to become obsolete. There are better things to spend taxpayer money on right now than a full-scale system switch-over to OSS just because.

      As desktop computers need replacing, use Linux. As servers require replacing, use OSS as well. As for the immediate - go with what's already in place.

    • Re:NEWSFLASH (Score:3, Insightful)

      It's open-source methodologies they're switching to, entirely within the DoD itself. It will probably be a matter setting up sourceforge.dod.gov and adding a Wiki.

      The all-diesel thing is a hardware problem, and military hardware isn't cheap.

    • Govt. IT is highly fragmented. It took 20 years for DOD to switch to all-diesel. How long to switch to open-source?

      Penis Cleaver, what a cute name you have. Oh well, it's worth the time to answer your silly question.

      Intention is more important than time here. Now that the US DoD has realized and prooven the obvious, they will do it as they need to.

      The rest of us can continue the migration and have fewer problem doing it. We can now point to it whenever we run into "Get the Facts" nonsense that M$

      • Are you some kind of idiot? In a few years some other guy will be in this guys position and will have a different take. When I say fragmented, I mean 100 different domain controllers and methodologies, and ever changing management.

        You sound just as bad as the MS apologists. The fact of the matter is you can deploy decent solutions in either open source or closed source, and if you know anything about IT problems in govt you would realize that neither will cure the disease that ails it. You open source gu
      • HillyTwit strikes again!

        Between the government stating the obvious, DRM and corporate rip offs, M$ is losing most of it's fan base.

        Are they? Lots of people (outside Slashdot) are very eager to get their hands on Vista. Windows is still very widely used due to its support for games, its supporting the only fully usable office suite available and its instant accessibility to most computer user's around the world. As far as it goes, people don't care about DRM, because it doesn't actually affect them; for peop
    • Awesome, they all dress in Diesel [diesel.com]? Oh wait, never mind.
  • by LWATCDR (28044) on Tuesday July 11, 2006 @11:25AM (#15698852) Homepage Journal
    The statement that people could introduce malicus code into Linux that then makes it's way into secure systems. Of course with companies outsourcing programming jobs to other countries the same thing could happen with a closed source system.
    The solution for OSS is simple. Any OSS software that goes into a Command and Control system needs to have it's source code audited by an independent authority.
    Of course the same thing should be done with any software that goes into a military, aerospace, or any other mission critical system. In this case OSS does have a clear advantage in that the end user can select any group to perform the code audit instead of depending on the vendor.
    Of course if the military does a code audit on Linux they would have contribute back the patches so it is a win win situation.

    • by Peter Mork (951443) <Peter.Mork@gmail.com> on Tuesday July 11, 2006 @11:32AM (#15698924) Homepage

      The solution for OSS is simple. Any OSS software that goes into a Command and Control system needs to have it's source code audited by an independent authority.

      Unfortunately, it's not as simple as auditing the source code. You also need to have complete control over the compiler, as implemented in machine code. For example, see Ken Thompson's comments [acm.org] on how to imbed self-replicating code into a compiler so that every program has a back door.

      • At some point you have to trust someone, unfortunately. The only way to be completely sure, as Ken Thompson himself points out in a roundabout way, is to build a computer and all of its software (include firmware, microcode, etc.) completely from scratch, using no one else's software at all, since such malware could even be inserted into firmware or even the CPUs microcode. Let me just say that the task would be next to impossible today, even for the DOD.
      • by jZnat (793348) * on Tuesday July 11, 2006 @12:02PM (#15699143) Homepage Journal
        No matter how many times that FUD is introduced here, people forget that GCC bootstrapped itself, and I'm sure it gives you directions somewhere on how to bootstrap it yourself as well. Writing a simple C compiler in Assembly and "compiling" the Assembly by hand is very possible if you need that degree of paranoia distinguished.
        • But then you have to trust that your OS's file writing primitives haven't been tampered with. Even if you trust the OS, can you trust the CPU? The hard disk controller? OK, it's really far-fetched, but if your a government institution, you may need to worry about stuff like this.
          • But then you have to trust that your OS's file writing primitives haven't been tampered with. Even if you trust the OS, can you trust the CPU? The hard disk controller? OK, it's really far-fetched, but if your a government institution, you may need to worry about stuff like this.

            MAY need to worry about this?

            How about CERTAINLY HAVE TO worry about this.

            I sure hope the NSA and CIA are making sure no spies or other subversive elements are putting anything bad into the chips at Intel, AMD, etc.

            Due to excessive
      • by dwheeler (321049) on Tuesday July 11, 2006 @01:29PM (#15699916) Homepage Journal
        There's a technique for completely countering the "Trusting Trust" attack, called "Diverse double-compiling". See my web page on countering trusting trust through diverse double-compiling [dwheeler.com], which includes a link to a paper describing how to do it, and an example where it's been done.
    • Of course if the military does a code audit on Linux they would have contribute back the patches so it is a win win situation.

      Only if they distribute it outside their organization, which in this case could be probably construed as the US government and the military and national guard.
      • by jc42 (318812) on Tuesday July 11, 2006 @02:09PM (#15700230) Homepage Journal
        ... hey would have contribute back the patches so it is a win win situation.

        This is hardly anything new. Look into how the DoD funded the development of the Internet (aka ARPAnet).

        Actually, in most cases they didn't even develop their own patches. Rather, they told their academic and industry fundees about the problems in the latest code, let the hackers work out a solution, took the code for their own uses, and left it in the public code base for further use and development.

        Yeah, they probably did a bit of development on their own, but the evidence is that there hasn't been as much of this as you might expect. The military has found the academic hacker community to be a much better testbed for most of the code, and a lot cheaper than trying to debug changes in a military setting. As long as the crypto stuff is highly modular (and it is), it's a lot more effective to just leave the code development in the public sector, where there are lots of eyes and people happy to show off their expertise by doing the hacking that a strictly-managed power structure finds highly distateful.

        For a feel of the US government's relationship with the linux part of the open-source community, google for "secure linux" and do a bit of reading. There's a lot going on there.

      • No, we're talking about DoD contractors contributing the patches, who then "sell" the systems to the DoD.

        And yes; a lot of DoD systems do get code-reviews by independent organizations (like Mitre.org, and Aerospace Corp.).
    • Of course if the military does a code audit on Linux they would have contribute back the patches so it is a win win situation.

      I have a sneaking suspicion that "State Secrets" privledge trumps GPL, since, you know, it trumps every other law in the land.

      • If they don't wanna release the source, they just don't release the binaries. It's that simple.
      • by db32 (862117) on Tuesday July 11, 2006 @12:27PM (#15699346) Journal
        Go ask Cisco, or MS, or any of the other major vendors how many of their patches came from the DoD. DoD has found a great number of problems in a great number of products and has in turn work on a great number of patches that made it back into the consumer world.

        Coarse...for the really paranoid type...I would like to point out that the DoD has played very large roles in quite a few other critical areas that I'm sure everyone holds near and dear...vehicles, aircraft, radar, computers, oh and that intarweb thingy...DARPAnet and all.

        DoD has had a pretty good history of providing goodness to the populace as well as all the negative that people like to focus on. DoD doesn't start the fight...politicians do, remember that next time you see a service member. They bleed for the good causes, and the bad causes...its the leaders that determine what causes they are going to bleed for next.
    • by wfberg (24378) on Tuesday July 11, 2006 @11:47AM (#15699018)

      The statement that people could introduce malicus code into Linux that then makes it's way into secure systems. Of course with companies outsourcing programming jobs to other countries the same thing could happen with a closed source system.

      American programmers are just as capable of introducing (intentional) bugs as foreign programmers.


      Of course the same thing should be done with any software that goes into a military, aerospace, or any other mission critical system. In this case OSS does have a clear advantage in that the end user can select any group to perform the code audit instead of depending on the vendor.


      The US armed forces have enough spending power to convince even Microsoft to pony up the source code. And they do.

      Of course if the military does a code audit on Linux they would have contribute back the patches so it is a win win situation.

      Under the GPL, you only have to contribute patches if you distribute your modified code to third parties. The result of a code audit might also just be "don't use module X", in which case there's nothing to patch.

      The way I read it the article is more about encouraging DoD programmers to be more like the open source community in sharing programs, ideas and sourcecode with each other, rather than continually reinventing the wheel.
      • The US armed forces have enough spending power to convince even Microsoft to pony up the source code. And they do.

        I wonder how often they actually recompile the code and verify that it's byte-for-byte identical to the binaries that Microsoft sent them.

        This is, of course, usually straightforward with any unix-based software, where often all you need to do is cd to the right directory and type "make", then run diff on the output and the delivered binary. I know from experience that it's usually not straightf
    • Yes.

      >it holds the potential to reduce software purchasing and development costs.

      and to improve security. The Naval Academy has held "hacking" exercises. How about a code auditing exercise? At the end of that, the graduating officers will be much harder to hoodwink about software security.

      >Of course if the military does a code audit on Linux they would have contribute back the patches

      Only if they distribute the binaries outside their organization.
      • In this the military has much the same problems that most organizations have: the decisions about what to purchase are often not made by people who have any hands-on experience, rather it is made by people who are getting much of their information from vendor salespeople.

        Remember, it is the Generals who ultimately sign off on these large scale decisions, and not many of those come from the Engineering ranks (to get high office you usually have to serve in combat positions... generally a good idea, but might
    • Rather than an independent authority, the N.S.A. already has extensive experience with Linux due to developing SELinux, and also has a mandate to evaluate and provide secure computing solutions to the U.S. public. Just have them do it.
    • Because the exact same complaint applies to proprietary software. It is not true that anyone can introduce code into an OSS project. While everyone can make their own private modifications to the source, that is entirely different from getting your code accepted into the official repository. Every reputable project out there restricts commit permission to developers who have proven themselves usefull. All other patches have to go through one of the main developers first. Now these "trusted" developers cert
    • Of course if the military does a code audit on Linux they would have contribute back the patches so it is a win win situation.

      Show me the section of the GPL that stipulates this.
      Don't bother, it isn't in there.

      The Government (or any contractor) is under no obligation to release the results of any derivative works back to an upstream source. If a contractor like Northup Grummond did do a code audit and made patches, they'd only have to release these improvements to the customer (DoD). DoD could take or leave
      • You are correct. I should have stated that it would be logical for them to contribute it back. I was assuming auditing existing OSS software for things like the Linux Kernel. If the DOD found a security issue with the Linux Kernel, Apache, PHP, GCC... It would only be logical that they patch it so that every none critical DOD user would benefit from the added security without the DOD maintaining their own code base for common programs.
        I should have said that they would probably contribute back the patches.
        • My thinking was along the lines of someone say in a contractor working for the DoD since they don't have a lot of internal manpower for things like that. What talent they do have for efforts like that are probably tied up evaluating any custom code that they deploy widely. On the other hand, most DefCons rarely contribute fruits of labor back to OSS projects because it is viewed as some kind of intellectual hemmorage which doesn't maximize shareholder value. :-|

          Why let your competitors enjoy the fruits of y
          • I wouldn't be so sure. IBM used to be a HUGE DOD contractor. The computers in the B-1B where IBMs running IBM software. IBM donates back a lot to OSS.
            I will admit that there is some software that I just don't think needs to be released. Almost any DSP code for sonar or Radar, a large section of Aegis code should probably be kept under raps as well.
            What percentage of the code will get contributed back? Who knows?
            • IBM has many customers, Govt. and Civilian.
              Northup Grummond, Lockheed, TRW, etc. live and die by Govt. contracts and are not interested in new-fangled web-to-oh and wikiki-macalits or anything else "trendy" in the computing world. They have no relationship to maintain with the computing public at large, if you will.
              I would wager that the use of OSS internally and for the customer is due to close relationships with Uni. labs and the graduates that come into those workplaces who know the territory.

              But you kno
    • The statement that people could introduce malicus code into Linux that then makes it's way into secure systems. Of course with companies outsourcing programming jobs to other countries the same thing could happen with a closed source system.

      Forget outsourcing. Software companies that don't manage their development process closely enough (and that's most of them) often end up with unauthorized features. Usually they're added because somebody thought they were cool, but backdoors are not unknown.

      I used t

    • by thewiz (24994) * on Tuesday July 11, 2006 @12:30PM (#15699373)
      FYI: The government already has several organizations that review source code and test software before it is accepted for use. Putting something that has not been reviewed on a government computer is a good way to lose your clearance.
    • IMHO this is a logical step, in right direction.

      Security thru obscurity is like trying to hide your fortification in the bush: it hides you, but you don't know how well and you don't know if your enemy uses your cover for undetected infiltration into your perimeter, too. In other words, you may have false sense of security or put too much unnecesary effort to maintain secrecy, ending in paranoia. Therefore it is good when you have clear situation and can focus on secrecy of only those things you need secret
    • Sure, it's possible that malicious code could get into OSS and make its way into secure systems. But the exact same thing is true for proprietary software.

      US companies have people working for them that have no security clearance and could easily be a foreign agent. If anything, the commercial code is more at risk, because there's no independent review of the potentially compromised code. At least if someone's contributing to Linux you know somebody's looking over their patch. With a proprietary company, wh
    • It has also blown up several rockets and caused other havoc.

      Why is this? Because 99% of these systems were done in closed source. If they were done in open source than open source applications would be blowing up pipelines and rockets.
  • Training (Score:3, Informative)

    by mo'o ahi (633487) on Tuesday July 11, 2006 @11:44AM (#15699002)
    First, I generally agree that there are many areas where this will be of significant benefit. Unfortunately, there are so many problems across DOD right now due to insufficiently trainied operators/admins - this will make it significantly worse in the operational arena. I have been on board many installations to train people and was saddened by the lack of sound IT skills by those that are supposed to be managing the systems. Of the 100 or so IT personnel I have trained, I would say that 5-6 have the necessary mindset and skills to effectively implement OSS. Centralized control is a hallmark of DOD IT - and this flies in the face of that as well, from a cultural perspective. (not that this is a bad thing) So, this means that not only will they need to change the infrastructure - the culture will need to shift, which is a much longer term issue. Then again, this could be good for the network-centric warfare concept. It could inject a much needed does of innovation.
  • by LWGLIN (98225) on Tuesday July 11, 2006 @11:47AM (#15699014) Homepage Journal
    Granted, I'm not talking about Command and Control systems, but the DoD has been using OS Software for years now. I know because they are using iText [lowagie.com] to produce billions of PDF documents. I have been mailing with DoD developers regularly in the past (and neither I, nor my product is American). It's not as if they have changed their mind about OSS overnight. The remarkable thing is that they are now coming out with a policy about OSS, and that they are considering to use it on a larger scale. (Yes, we're talking about Operating Systems now!)
  • by MikeyTheK (873329) on Tuesday July 11, 2006 @11:57AM (#15699092)
    Here's the problem with adopting Open Source for everything: It completely homogenizes the entire process of software development, which means that it tends to quash alternative development tools, languages, and techniques.

    For example, is it good or bad that JavaScript has implicit typing? Many developers want explicit typing, and call implicit typing "lazy". I can barely have a conversation with a group of fellow geeks without getting shouted down on this topic. The problem with group-anything is that group-think will prevail. To quote one of my favorite posters from demotivators.com, "Meetings: None of us is as dumb as all of us".

    In addition, alternative lanuages and tools tend to be stifled in so-called "open" (read group) environments, because the rest of the group immediately pushes to have the alternative tool or environment removed, unless the group agrees that it is a good idea. Is that the way inventions are made? No. Inventions are made by a single person with a radical idea avoiding all the intervention/interference, naysayers, etc. and presenting that idea DESPITE the opinions of others. I can see opening source after the fact for auditing and sugestions, but not for development.

    It seems that a lot of the open source push has been a reaction to the fact that many of the development tools we use are not at a high enough level of abstraction. If you abstract away from code and languages where you are doing your own memory management, one would think that you would experience fewer memory-related programming issues. What kind of issues are most often discussed with open-source development? Exploits, buffer overflows, etc. I can see the database engine being open source, which would help with dealing with injection attacks, but the rest of the application (where the money is) can't possibly benefit from having lots of people "helping out".

    Imagine the entire cast of The Food Network making soup together at the same time. "None of us is as dumb as all of us".
    • Here's the problem with adopting Open Source for everything: It completely homogenizes the entire process of software development, which means that it tends to quash alternative development tools, languages, and techniques.

      Yes, that's why everyone in the entire Free Software community has completely standardized on -- for example -- GTK. Obviously, Motif, QT, Swing, WxWidgets, TK, etc. are all figments of your overactive imagination.

      For example, is it good or bad that JavaScript has implicit typing?

      In a

    • Open source is not homogeneous in the manner that MicroSoft as a solution is homogeneous. It is in fact the shotgun scatter approach to development that produces an organic style growth in free/open source development. Just as diversity is good for an ecosphere, the diversity of approaches (while sometimes a bitch, short term) is providing a long term advantage to open source. With all due respect, it seems to me your fears are just almost exactly 100% ass-backwards. Open source is a cure for the homoge
    • Have you thought that perhaps implicit typing is a BAD thing, not just lazy, and the people you talk with are just unable to express it very well?
      Inventions aren't always made by single people, either. Unless you think that, say, the CPU in your computer is made by a single-person enterprise. Or that things like Teflon weren't made in a research environment with other people.
      The open-source push is because it keeps the process open. Anyone can add to it if they feel like it, and yes, it is controlled b
    • In addition, alternative lanuages and tools tend to be stifled in so-called "open" (read group) environments, because the rest of the group immediately pushes to have the alternative tool or environment removed, unless the group agrees that it is a good idea.

      How on Earth is this different from working for a company on a closed-source project? In fact, such a decision to stifle an alternative tool is frequently made by non-programmers in a closed source environment or by higher-ranking programmers in an ent
    • In most corporate development environments you are limited just one language no matter what your problem is. Most often the choice of language is made by an accountant/CIO who has never written a line of code in his life.

      How is that any better?
  • by MikeRT (947531) on Tuesday July 11, 2006 @12:07PM (#15699179) Homepage
    It makes contract bidding cheaper. If you can use an OSS toolkit over a proprietary one, the cost that gets billed to the government is lower which makes it easier to win contracts. Other than that, bureaucratic inertia is the only major problem OSS faces. There is hardly any more bias against OSS than there is toward any regular commercial software.
  • by jd (1658) <<moc.oohay> <ta> <kapimi>> on Tuesday July 11, 2006 @12:12PM (#15699214) Homepage Journal
    ...is that Closed Source vendors have opposed Open Source "in the national interest" and "for reasons of security" for some time now. Regardless of whether the DoD ever actually follows through on this, there is now an official statement by the US Government no less that these claims are false. Hey, we've all known that for some time, but ringing endorsements by the DoD don't come by on a weekly basis.


    This is the time that Open Source activists and promoters need to run with the ball. Draw the attention of CEOs and business executives to the fact that the DoD advocates Open Source. Show them that we're not talking toy software. Show them that this isn't about not wanting to spend money. (Since when was the DoD afraid to spend money?) This is about an innately powerful method of developing high-grade - even military-grade - products that do what people actually need done.


    We couldn't ask for better, but only if those outside of the IT industry actually hear of it. If only those who already accept the strengths of Open Source know that someone else has also decided it is a good solution, then that decision means nothing. Particularly as the DoD is very unlikely to do anything about it. It'll just be a decision. But if the business community got shown this... That would be a whole different ball-game.

    • ...is that Closed Source vendors have opposed Open Source "in the national interest" and "for reasons of security" for some time now. Regardless of whether the DoD ever actually follows through on this, there is now an official statement by the US Government no less that these claims are false

      So you're telling me that Darl McBride was wrong? No! It can't be!!!!!
  • by spun (1352) <`moc.oohay' `ta' `yranoituloverevol'> on Tuesday July 11, 2006 @12:21PM (#15699286) Journal
    I work for the Child, Youth and Family Development department. We use Windows on the desktop, Novell as our file server and SuSE Linux for everything else. Currently we are transitioning away from HPUX to an IBM BladeCenter environment running VMWare and SuSE. We have one major application and several minor ones. The major app, a client tracking system, was developed in house and runs Sybase as a back end. Eventually we plan on porting it to use Postgres and releasing it as open source so that anyone in need of a client tracking system can use it.

    This is the real beauty of open source in government, not leveraging the work of others by running open source systems, but leveraging the large development force that most governments have to share in house apps wit less of the usual inter-agency squabbling. An agency that might be wary of using a non open source application developed by a rival agency will be less wary of using an open source app that just happens to be developed by said rival. Instead of reinventing the wheel, in house development staff can cooperate with other staff in other agencies.

    That the DoD would recommend open source is exciting, because it really is a good fit for government agencies. Believe it or not, our little state government IT department is better run and more on the ball than most IT departments that I have worked for in big corporations. Moving to Linux hosted on blades running VMWare has freed up a lot of resources to plan for the future that used to be used in just putting out fires.
    • The last thing we need is the "Child, Youth and Family Development department" being more efficient at destroying families. I suggest you learn a few things:
      • People are innocent until proven guilty, not guilty until proven innocent.
      • Maleness is not proof of guilt.
      • Anonymous tips are not probable cause.
      • Searches require warrants, no matter what your state law says to the contrary. (this was won in the 9th district with a very strongly worded opinion against the socialist workers)
      • If you'd have taken Abrah
      • Christ, you have no idea what we actually do here. And you have no frickin idea what some of these kids have gone through, so zip it. Foster care for orphans, detention centers for kids who commit crimes, aid for families in crisis, there's a lot more to CYFD than just taking abused kids away from messed up parents.

        The last point you make sounds suspiciously like the excuse an abuser would make. Sorry if you were a bad parent and someone took your kids away. Doesn't negate the good work we do.
        • A vengeful inlaw made an anonymous phone call to get even with me. She had gotten herself approved to be a foster home, but had refused to take any kids so far, thus having available space. She was trying to push me out of the family, engineering a divorce by forcing my wife to choose between me and the kids. My wife didn't go for it; we wasted $6000 on a lawyer to fight off a fucking anonymous phone call. We didn't have $6000 to spare. Many people would have no hope of paying that, so they automatically lo
          • Well, I'm sorry if you were in fact a good parent and got screwed over by the system. There certainly are problems but the system does more to protect children than harm them. For every case like yours there are fifty where the child was in real danger, and like I said, taking children from their families is not all we do.
            • I doubt you can honestly determine if a child is in danger. You certainly can't determine the quality of an investigation by anything dependant upon the investigation itself. That's a circular proof.

              You can retroactively determine danger if and only if the family is not destroyed. On occasion, this makes for bad press. There is no way to determine how many decent families have been destroyed.

              The concept of "innocent until proven guilty" does mean that a few evil people (serial killers, terrorists, rapists,
  • The WGA debacle has proven that WIndows update is a security risk. Not running Windows update is also a security risk. When non US governements will reach the conclusion that they need to move off Microsoft software? It is a matter of national security.
  • At least as a US citizen. Companies like Microsoft (Microsoft specifically) are a pretty big part of our economy. I don't think I have to even say how much money is coming into the US economy with each OEM computer bought out there putting probably $150 into our economy including MS Windows and Office.... Open Source is good for the global interest, yes, but I don't think so for the United States interest. It's easy to continue riding a wave of success (Like Microsoft has done for the past couple decade
  • I've been telling my bosses this for 2 years! Maybe now they'll listen...
  • awesome (Score:4, Funny)

    by eliot1785 (987810) on Tuesday July 11, 2006 @01:04PM (#15699654)
    To: Department of Defense, Source Distribution Department
    From: Kim Jong Il

    To Whom It May Concern,

    In accordance with the terms of the GNU General Public License, I'd like to receive a copy of the source code for your Pacific-based Ballistic Missile Defense System. I do not require it in CD form; please simply email it to me at the above address (k.il@korea-dpr.com).

    Thank you for your prompt fulfillment of your obligations under the GPL.

    Sincerely,
    Kim Jong Il
    • That requirement only matters if you distribute the software. I don't think North Korea would like the distribution method that we'd be most likely to employ.
    • Re:awesome (Score:5, Funny)

      by Scarblac (122480) <slashdot@gerlich.nl> on Tuesday July 11, 2006 @02:18PM (#15700299) Homepage

      Mind you, the DOD is under no obligation to give the source to random members of the public, only those who received binaries... So he would have to wait until he got one of those missiles distributed to him first :-)

    • You _really_ don't have the foggiest idea about the terms of the GPL, do you?

      The US government would not be required to honor this request _UNLESS_ they had already distributed the binary for same to KJI.

      See, If I make a distribution of something based on someone else's GPL code, I _only_ have to distribute the sources TO THE PEOPLE I DISTRIBUTED THE BINARIES TOO. I don't owe anybody else anything at all under the GPL.

      In fact one basic technique is to distribute the sources with the binaries and then rely
    • Dear Mr. Jong Il:

      Thank you for your interest in our Pacific-based Ballistic Missile Defense System (PBBMDS). The source code for the PBBMDS is only distributed with that system. We do not entertain requests from third parties to provide the source code. You may have been confused by reading clause 3b of the General Public License (GPL), however, we distribute the code under the terms of clause 3a of the GPL, which incurs no obligations to third parties. If you have received binaries of our code without
  • by flooey (695860) on Tuesday July 11, 2006 @01:09PM (#15699696)
    The recommendation by the DoD isn't specifically to use open source software, though that'd be one possible implementation of it. What they're recommending is that the DoD build a foundation upon which code and standards can be shared in the way that open source tends to do. The current situation in DoD is that basically every project writes its own code, so the software in a GPS satellite may well be entirely distinct from the software in a communications satellite, even though they could both be cheaper and more reliable if they were to reuse code and standards. It's the methodology, not the actual code, of the open source movement that they're interested in.
  • Actual Report (Score:3, Interesting)

    by MrCopilot (871878) on Tuesday July 11, 2006 @01:12PM (#15699735) Homepage Journal
    79 page .pdf http://www.acq.osd.mil/actd/articles/OTDRoadmapFin al.pdf [osd.mil]

    Haven't made it through the whole thing yet, but FTR:
    The business model of purchasing physical goods and services has served DoD well in the past; but it falls short when applied to software acquisition. By treating DoD-developed software code as a physical good, DoD is limiting and restricting the ability of the market to compete for the provision of new and innovative solutions and capabilities. By enabling industry to leverage an open code development model, DoD would provide the market incentives to increase the agility and competitiveness of the industrial base. Currently within DoD, there is no internal distribution policy or mechanism for DoD developed and paid for software code. By not enabling internal distribution, DoD creates an arbitrary scarcity of its own software code, which increases the development and maintenance costs of information technology across the Department. Other negative consequences include lock-in to obsolete proprietary technologies, the inability to extend existing capabilities in months vs. years, and snarls of interoperability that stem from the opacity and stove-piping of information systems.

    Absolutely.

    There are over 100,000 publicly available open source projects available spanning most functional areas.4 Many of these projects provide mature and robust solutions in their areas of focus. When possible, OSS components should be leveraged rather than funding the development of equivalent proprietary components for specific programs.

    Damn Skippy!.

    Challenges Culture and Process The primary challenges to this transition will be cultural, not technical. Over time, government acquisitions and development processes have built a bureaucracy and rewards system that encourages and supports the status quo. Careers are advanced primarily on program size, not necessarily overall efficiency. Furthermore, government contractors are measured by revenue; government program managers are measured by the size of their organization and their overall budget. The canonical government contracting process creates high entry costs for small innovative companies -- the established contractors attempt to control their positions through proprietary implementations and interfaces. The system is very good at protecting itself -- new approaches, such as OTD, will have to endure legal, security, and process challenges. The current infrastructure will attempt to delay change, claim they are adapting by trying to assume control of the innovative process.

    My Favorite Quote is in the DOD report.
    There is one thing stronger than all the armies in the world, and that is an idea whose time has come.
    -- Victor Hugo

    All in All, I'd say the guy in charge of this report knows his stuff and I for one, welcome our new OSS-using DOD overlords.

  • In fact, Mitre told them that they were already using FOSS so much that "...banning FOSS would have immediate, broad, and strongly negative impacts on many sensitive and security-focused DoD groups to defend against cyberattacks." (Quoting from the executive summary)

    You can read the whole thing here [egovos.org]. So, it's taken four years for the DoD to finally put in place an official policy encouraging the use of FOSS when the guys in the trenches have apparently been doing so routinely for about a decade. Typica

  • The military security folks have been saying for decades "Don't run any software unless you have the source code all the way down, plus the circuit diagrams. If you don't, you have no idea what might be hidden inside."

    So the DoD's decision makers are listening to their security experts?

    I guess maybe it is news.
  • OS X, the rest of the BSDs, Solaris, Linux and others will fight for contracts; and they will all offer various cost/benefit analyses while adhering to the open standards requirements. Microsoft has the most to lose.

If entropy is increasing, where is it coming from?

Working...