Slashdot Mirror
US Needs Secure Coding Office
Trailrunner7 writes "If the United States wants to remain competitive in the global economy and prevent widespread penetrations of its strategic, corporate, and commercial networks, enterprises and government agencies should stop relying on commercial software and go back to writing more of their own custom code. 'If we're going to maintain our place in the world, software is not a strategic problem, it is the strategic problem going forward,' security expert Marcus Ranum said in a speech Tuesday. 'Covert penetration becomes something that you think about on a five, 10, or 20-year scale. Why don't we have a government coding office? We have a government printing office. Why don't we have a strategic software reserve? Our own software is probably a greater threat to us than anything other people can do to us.'"
Hire the OpenBSD boys. They have a proven track record.
Why don't we have a government tinfoil hat office? Clearly we're under great threat of alien mindrays.
Visual Basic.
Yours In Astrakhan,
Kilgore Trout
In Soviet Amerika, coding office secure YOU !
Ballmer scrambling the jets now.
From the midwest.
Mod me down, my New Earth Global Warmingist friends!
In house software for government jobs is the way to go.
1) You own the code
2) You're goal is to have software that works for a long time. You vendor does not share that goal. They want you to rebuy software every 5 years.
3) It's a lot cheaper to maintain.
4) It's written to get a job done. Once that's done, you don't have to worry about some revising the requires new hardware.
The Kruger Dunning explains most post on
We have a US Dept of Agriculture (USDA) because agriculture is a essential part of our nation's prosperity and well being. In this day and age so is software.
Having said that, I'm a little skeptical that the gov't could be as effective at being a source of knowledge, studies, research and tools in the realm of software.
1. Why indeed, Marcus, "coding" and "printing" are so similar.
2. And the shelf-life of that software "reserve" is...
It must have been something you assimilated. . . .
"Why don't we have a government coding office? We have a government printing office."
That comparison is ridiculous. A proper comparison would be "We engineer our own government printing presses and copiers, why don't we engineer our own software?" But of course the government doesn't engineer printing presses...
Better known as 318230.
Writing code is fundamentally error-prone, and expensive! Programmers, young and experienced, make mistakes. Young programmers in particular overestimate their abilities, and wildly under-test, and pretty much totally fail to think about compatibility or vulnerability. Proper management to enforce testing, reviews, documentation, security, etc. is very expensive. And once you've written the code, the marginal cost of sharing it widely is very low ... which is why I believe that this proposal will fail: it will always be cheaper to use either commercial code, or open source.
We have Halliburton.
That worked so well, I mean it's just ubiquitous now with overwhelming support right?
"TV, a medium as it is neither rare nor well done." Ernie Kovacs
Don't forget about hardware.
Oh, wait...
they already don't have government developers in some kind of underground facility?
However, if they don't, then I couldn't agree more. Many of the issues that people worry about today will most likely be solved with future technology. Stable software networks and the security fight, however, are only the tip of the iceberg of the problems we will face in years to come. Research and development should be our number one priority, which would not only give us a head start on security, but would show high economic returns if we fund it now.
Having worked in government IT, and worked for government military contractors I dont think that the software is the issue.
I would start by upgrading all the equipment that went EOL (End Of Life) more than 5 years ago! (90%+ of the hardware they run) /var/log directory.
Then move to the equipment that is EOL now.
I would then work on implementing a proper patching and patch management plan.
Documentation would be useful as well, Stop expecting the new IT staff to understand how AIX v3 works on the H50's you are running. Especially when the old IT staff thought it was good security to replace the login with one that used a password file stored in the
Security through obscurity is all that would happen if the government tried to make all systems code come from an internal group. I am sure we all know how well that works!
I say mandate that the government groups run only opensource software. Then hire select coders to quick patch any problems or security issues that are found and make the parches available to everyone. That way the government can be secure as well as any other company or person that runs the same software.
As long as it justifies more money passing through the business of government, you can guarantee the elite at the top of the pyramid will approve of it.
There's a reason why every year government expands in terms of both power and reveune, and it's sure as hell isn't because government is getting better. It's because the bigger the business of government, the more lucrative it is for those who control it.
A better idea would be to have an office that analyzes the code of existing software for security issues, develops solutions, and hands them over to the software owner.
Owner doesn't want to share the code? Don't use their software for government work.
But redeveloping from scratch at this point does not make fiscal sense any more. We stand on the shoulders of 30 year tall giants. There is no need to rewrite the TCP IP stack from scratch, to write a word processor from scratch, to write a web server from scratch, etc.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
US Needs Secure Coding Office
Why don't we just put some armed guards and security cameras on each floor and around the building?
It's a great idea, I know. You can pay me by paypal for it.
Why don't we have a government coding office? We have a government printing office. Why don't we have a strategic software reserve?
We do. It's called open source. And it's run by a militia just like the one that started this country.
Who is John Galt?
Seriously. WTF. How can anyone ask that question and expect to not be laughed at.
I can just hear the moaning of how unfair this would be to private software corporations right about ... now. After all it's bad enough that they actually have to compete in some form against "free" OSS projects, but teh gubbermint too? Oh noes!
*off-the-shelf vendors are not contractors (but can be). Most contractors have no products, and only produce what the government needs when they need it.
*Contractors go through the same clearance processes as government employees.
*For all intents and purposes, most defense IT contractors work as part of the agencies employing them. The big difference is they assume the risk that if they suck, they will get canned much much faster than a government employee. Flip side is they get payed more because of that risk.
*Printing isn't a good comparison to programming. The GPO puts paper in the machine, makes sure it is running, and delivers the results. Programming is like inventing a new way to make paper, and then a new way to make ink, and then a new machine, and then printing the results. It requires more creativity.
*Programming is more like art than it is science. Because of that, programmers generally like freedom and flexibility in their workplaces. Do you think the best programmers would want to work for the government?
*The majority of security vulnerabilities are caused by lousy programmers. One good programmer is more valuable than 100 lousy programmers in terms of security. Pay the one good programmer.
*Classified code does exist. Perhaps there should be more of it for security purposes. Perhaps a classified operating system (if there isn't one already).
*The contractor system should be reworked so contractors inherently place less emphasis on sales. I personally believe that creating an easier, more automated proposal process would help.
*Big defense contractors are the gluttons of the industry. I believe focusing even more on helping small businesses have an easier time selling their services would help drive productivity.
We've had this. It was called Magic Lantern. Really, I think we can do without any more of it.
Space game using normal deck of cards: http://BattleCards.org
I concede the point that government and industry are awash in misconfigured, insecure, and buggy code. However, I fail to see how developing more code in-house will result in code that is more secure and less buggy. Where will the expertise in secure coding come from? From TFA:
So, if that is true, how exactly will it coding in-house help? There's no one in-house who can do it right and that's the whole problem!
Ranum's thesis seems to be "contractors suck" but buried in his article is the kernel of the real issue in my opinion: project managers don't understand security and aren't accountable for making their products secure. If they did and they were, we would get more secure code regardless of whether the development were in-house or outsourced.
So Ranum seems to think that the solution is to create more government jobs (maybe he wants one or something), but really I see this as a management challenge. If large institutions can set a priority on security and develop expertise in their managers, then I think the picture will start to look better. Until that happens, I don't think playing musical chairs with the development team is going to help.
What Ranum is proposing is simply yet another fake silver bullet.
[Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
Contractors are favored by the federal government mainly because they can be hired and fired more easily than employees. Big commercial contractors are favored because they are the ones most capable of jumping through the flaming hurdles that the feds put up to keep up the appearance of saving tax money. The solution is simple: change the damn laws and regulations so that they can be easily hired and fired, and any 1099 can big on a small project without being an expert in government processes.
Here's the link: http://www.nsa.gov
You would all win the prize for twenty of the dumbest comments on slashdot, not a brain cell between you all, and a big advert for Sarah Palin right next to the article, is this what slashdot is reduced to ..
Sarah for 2012
I know! Let's call it the National Security Agency... and they could do things like work on securing our systems. Take Linux for example... maybe they could create a more secure environment... and call it SE Linux...
Nah... that's silly...
Dumb idea. You now have isolated code custom built for each group. Someone would have an easier time exploiting it without detection because there would be a smaller user pool. At least with commercial software there is a larger audience to find and fix security holes and if one is exploited there is an accountable party to hold responsible for fixing it.
There are some big reasons why this might be a good idea:
1. Vendors have every incentive to pull the rug out from under you support-wise and make you buy their product again every few years.
2. Having people in-house who _actually know_ everything about how a system works really helps with debugging. Oracle, for example, is the king of finger-pointing when it comes to blaming some other part of the system for crashing a database.
3. Custom code would still have holes, but at least they wouldn't be the exact same ones being exploited in the private sector.
There's also some really good reasons not to do it:
1. You will still need to source an OS from somewhere. Whether $LinuxDistribution, IBM, Sun/Oracle, HP or Microsoft, ti wouldn't make sense to build a single purpose OS unless you were working on embedded systems. This OS would still have the same problem of limited-time support, publically available security exploits, and crappy support when you do get it.
2. Government organizations are very bad with communication. At the state level, practically every department sets their own standards. How could you get agencies with very different priorities to sign on to something that centralized?
3. Quality of code (see below.)
I work in systems integration, and have done so for many large companies. This is the place where we take applications, figure out how they can fit together, and merge them into a platform of clients/servers/network connections/databases. Software written by in-house IT is often the biggest bug-filled, resource hogging mess to get working. This goes double if the dev work is outsourced to a provider that doesn's know about the environment the app will run in. Think about the in-house apps you use -- the order entry client that requires a dual core processor and 2 GB of RAM, or the app that crashes with no explanation or a dialog box that says "You should never see this message." It's not all that bad, and some apps actually work really well. But developer training and skill levels are all over the map. At the very least, a vendor is responsible for their code, and can be persuaded/paid to fix bugs instead of letting them fester. A vendor specializes in building software meant to be used outside of their little corner of the world, so some companies do take time to make sure bugs are fixed.
This would work well when the field of software development matures a little more, and best practices aren't dictated by companies trying to sell you something. That's why IT has a very hard time being recognized as a branch of engineering - there's very few standard ways of doing anything. On the OS front, you have major vendors, hundreds of Linux distributions and other small players. On the database front, you have a few huge vendors that take totally different approaches.
Its actually not: printing and software development are both services that most government agencies regularly need, but that in general most don't need the same subtype of the broader service enough to justify retaining the capacity to meet all their needs in-house without outsourcing, but where the needs of the government as a whole would be more able to justify maintaining resources centrally and then making them available to individual agencies.
The fact that the necessary resources in the case of printing involve a mix that is heavier on physical capital than human capital, while the resources in the case of software development is a mix that is heavier on human capital than physical capital is a difference, but its not a difference that is particularly relevant to the point of the analogy.
You'd probably have a better case if you argued that the "strategic software reserve" was a bad comparison. Software isn't an physical resource with an interruptible supply that you can horde in advance against a future crisis. OTOH, I can see a useful "strategic software reserve" in one sense -- not a reserve of software but of software-related IP. If you accept as a baseline the current US system of fairly strong software-related creator IP rights (copyright and patent, most particularly), it might make sense for the government to strategically exercise the power to acquire property for the public use by eminent domain with a payment of the fair market value to "buy out" existing IP rights where there is a substantial public good to be served by doing so. This might -- structured properly -- be a system that serves the public interest and the Constitutional purpose of IP protections better than either maintaining the status quo without such a system, or just weakening IP protections generally.
The government's primary problems in this area are an excess of bureaucracy holding back stable software development. A very good first step is removing contractors from the equation, since that's an enormous layer of bureaucracy. We need to be funding real power-plays, not keeping the system as is.
"Government" has a terrible track record the same way "corporations" or "people" have a terrible track record. It only gets better if you look for improvements.
Yes, let's create a Secure Coding Office, and call it SCO :)
IMO the place to start if you want to fix computer security is with the culture of software use rather than the software itself.
There are plenty of places where security can be made better technically, and it is our nature as "software guys" to focus on those, but most significant break-ins come from the way people treat software and password information.
are all bigger problems than
Not because the latter aren't issues that need work, but because those are issues that get recognized and fixed quickly. As far as I know, there is no widely accepted way of fixing the social problems that plague computer security.
Something about not reinventing the wheel.
This is absurd.
I hate the word 'coding' it completely sets the wrong impression and totally degrades and devalues the work that a software engineer actually does.
Its as insulting as describing hardware design engineers as welders.
I'm in Canada, so things are a bit different. Generally I've found that things that are "utilities" (that is, basically necessary for normal living) are provided quite efficiently by the government.
My car insurance is via the provincial insurance company and the rates are some of the best around.
My phone and internet service is via the provincial telco. The rates are competitive and there is no usage cap.
Electrical and natural gas rates are via the provincial corporations and their rates are among the lower ones in the country.
"the government" is responsible to us, the people. There's no excuse for letting government be inefficient--hold them to account.
"You now have isolated code custom built for each group"
How would having many small software piece that is open and used throughout the country lead to that?
"At least with commercial software there is a larger audience
false.
" to find and fix security holes "
ohn yeah, corporation are real well know for jumping on security holes~
" exploited there is an accountable party to hold responsible for fixing it."
yeah, try holding a private company to that. good luck.
With a government body there is a specific person you can go to and hold responsible. You don't just have to be a shareholder or someone spending thousands of dollars. You just need to be a citizen.
The Kruger Dunning explains most post on
Not invented here: the old saying in IBM et al, in the previous millennium!-?
I assume that a cook in the CIA cafeteria should at least be a colonel, with 20 years
experience.
Marcus is something of a muckracker. At one time, he was in charge of whitehouse.gov website security, and has at times been incredibly critical of the US Gov - see his book The Myth of Homeland Security in which I think he rips every major division of federal government (but especially the DHS) a new asshole.
As such, many beltway types have tuned Marcus out. He's almost always right, but he goes about telling us the problems in the most confrontational manner possible.
Sorry, but the COTS battle started in the 80s and has been over for a while. Nobody builds when they can buy anymore. If you believe your business is utterly unique and needs custom-written software... well, you are wrong. And nobody outside of a few folks just emerging from college really believe that way.
Would it be better if the government (and businesses) paid for software development rather than paying for packaged software? Maybe, but it would cost more - it certainly did in the 70s and 80s. The difference for nearly everyone today is they are buying a package for $500 instead of paying a year or two salary for a programmer. Sure, when the project was done there would be something else to do - this is a basic maxim that work expands to fill available staff. But today just about everyone has figured out that COTS is the only way to go. The buyer is isolated from personality quirks of the developers and isolated from the development process itself. The buyer also never has to worry about being held hostage by some lone wolf developer.
Yes, there can be the dreaded upgrade cycle where support for really old creaky software is discontinued no matter what the desires of the customers. And it does mean that the package you bought in 1993 for Windows 3.1 absolutely does not work on Windows 7 x64. But the world does not stand still and there generally needs to be some movement on the upgrade front.
Secure coding initiatives can only buy you so much. Most attackers are going to utilize client side attacks (think PDF, SWF, etc) rather than coming in through the "certified secure" front door. Also, operational security is more likely to burn you than your code (bad patching, misconfiguration and other miscellaneous bits of human error).
The Duke Nukem Forever crewe knows how to keep code under wraps.
The government already funds software development and the past results of that funding predict the would-be future success of a government coding office; It would be a massive, expensive failure. The Census Bureau IRS, FBI and FAA have records of incredible, mind-boggling, massive failure in producing software. Not to mention state funded universities, the University of Wisconsin being the most recent travesty.
The unstated assumption that government involvement in software production would improve, and not degrade, the quality of software is ludicrous in light of evidence from past results.
But it would not only fail. As with other government agencies, it would be subverted by special interests for nefarious causes. Patents and Trademarks, established to promote creative works, are abused by patent trolls to threaten innovation and by politicians who extort campaign donations in return for incremental, perpetual copyright extension. The Department of Agricultural, now a wholly owned subsidiary of ADM, runs welfare-for-millionairs programs. Oh, and have you heard of Fannie Mae and Freddie Mac?
Government coding office? What could possibly go wrong with that?
Ceci n'est pas une signature.
Obvious jokes aside, the government doesn't innovate very well. It has clear limits to its power under the Constitution, and this would just be another example of it stepping outside of those bounds... Kind of like this little red star. All in the name of security? Yeah right.
We need a few special-purpose boxes that are highly secure, as examples. The components exist. There are hypervisors certified to EAL-7. They show up in industrial systems, DoD systems, and avionics. They should be showing up in routers, firewalls, DNS servers, and ATMs.
A push by Homeland Security to increase the security level of critical infrastructure would not be out of place.
Take a look at Reflections on Trusting Trust, where Ken Thomson basically admitted to introducing a backdoor into a commercial operating system by hacking the compiler. The conclusion of the paper, in his own words, was not to trust commercial software to be secure -- the only secure code is code you control from the ground up. That paper was published in 1983.
Palm trees and 8
Basically the article is saying that the government is incompetent and then comes to the logical conclusion that adding a new layer to the government will fix the incompetence. It's completely rational!
-- $G
Here's the problem with the "solution" of having government write its own code. 1. Insiders are an arguably pre-eminent cause (arguably, because insider problems are often not reported because of embarrassment) of so-called "penetrations" 2. Just because an insider is trustworthy and stable on the day they were hired, does not mean that they are trustworthy and stable on every day thereafter. 3. Software code runs on hardware. The corollary of having the government write its own code is to have the government design and manufacture every component that goes into hardware. 4. See points 1 and 2. I could go on, but gawd am I ever bored of pony-tailed security consultants telling us to isolate ourselves to be secure.
"Our own software is probably a greater threat to us than anything other people can do to us.'"
No.
The greatest threat of all was that our own business leaders would decide to ship millions of engineering jobs to China and India.
What if the compiler was hacked, the way Ken Thomson described in Reflections on Trusting Trust? You could have a perfect codebase that the compiler inserts backdoors into.
No, the highest security systems must be based on a codebase that is controlled by the government from the ground up, and implemented in languages that are not as susceptible to bugs and mistakes as C++ is.
Palm trees and 8
or they could answer their own question. Three reasons:
1) Government already writes much of its own code. I see gigs posted all the time. Thing is, each office/department/etc tends to be a silo, so there is no "central" coding department. Can you imagine the bureaucracy around change processes then? Sheesh...
2) On average, public sector pays less. The idea here is to improve the quality of code, right? Not really possible if you can't attract the best and brightest.
3) Using external (this can be commercial or open source) products is key. Who makes the computers? Who makes the IDE's? How can we guarantee compiled code is fully secure if you aren't controlling every step of the process? Not possible. Even the government's most important asset, the President, is transported around in products made by commercial interests (albeit, with some customizations after the fact).
The best thing about a boolean is even if you are wrong, you are only off by a bit.
Whats the best mix of local effort vs large scale coordination by government or contractors is really a management and logistics question that varies based on the specifics of each situation.
What the government really needs is a global logistics office (ie Google SRE) that will on a granular level identify areas of duplication between all departments and provide the proper mix of approaches rather than everyone working in a vacuume and constantly re-inventing wheels.
German embassies around the world use open source infrastructure to communicate with the home network. They've realized a long time ago that relying on closed source software that may contain backdoors accessible by foreign countries is a really dumb idea, so now they build their own based on open source solution, and occasionally contribute back to the community.
The goal is security. Centralizing software development, whether closed source or not, will change the landscape but not solve the problem. Yes, closed source and hard-to-get binaries may impede small hackers, but not government-level cyber-espionage. They'll infiltrate or socially hack your now centralized, easy pickings, offices. The biggest problem with Microsoft's dominance is not code quality, business practices, or other [insert rant here]; it's the ubiquity of their code. Once a security hole is found by someone, it can be exploited fricking everywhere. I've felt for years that all banks should do in-house only development from the hardware up; no outside operating systems, not just applications. What SHOULD be public is communications standards and other APIs, but what is under the hood should be new and different. Anyone who wants to be a cyber-criminal would have to specialize pretty hard on just a small niche, and would therefore be both easier to trace and catch and would have a much smaller chance of "making it big." Even viruses would be less able to spread.
On the one hand you take life too seriously, and on the other, you do not take playful existence seriously enough. Seth
FOSS works. The government can still hire people to write those "super secret" things they need. But the vast majority of government needs could be easily satisfied with FOSS. In fact, their use of commercial software constitutes fraud, waste, and abuse.
I work as a defense contractor, and most of the stuff we work on these days has a software component (whether commercial off-the-shelf, commercial/custom, or gov't developed). I'm pretty sure I don't want my missiles being launched by gnuFireControl or KLauncher. For one thing, there aren't all that many people with expertise in military software development outside of the existing M-I complex. And yes, military software is considerably different from other business software - for one thing, there are very complex safety requirements that have to be met, and if you don't know what they are, you won't be able to do it. More importantly, a lot of the military software in use today is classified - if you could look at the source, you'd get a lot of information about our own forces' capabilities and limitations, plus you'd be able to infer intel data on what we know about adversary systems. Not the kind of thing I want available to Boris and Natasha (or whoever our favorite bad guys are this week).
So you'd have to establish at least some exceptions to the all open-source rule. And once you start allowing exceptions, it can be hard to know where to stop.
So because I'm horrifically underpaid I'm not trustworthy now? Well that fucking hurts.
Maybe this dude who made $400k/year at Goldman Sachs is more trustworthy.
... but it's certainly possible to go too far in the other direction too, particularly with off-the-shelf software. The DOD recently bought a system from a defense contractor in a friendly foreign country (keeping the details vague here on purpose) that included a bunch of software controls. Our outfit was tasked with doing a safety analysis of the system. So we contact company X, asking for, among other things, a code listing. They flat out refused. "Well, you've analyzed it, right?"... "Oh, of course". "So can we see the analysis?" Nope. Not very smart on the part of company X, as it's hurting their chances of getting more business in the future, but in the meantime... we've bought this damn thing and we're having to treat the control system as a black box for the purposes of safety analysis. So it's not like this issue doesn't exist... it's a real problem. I'm not sure open source is really the answer, though.
Let's expand it some more.
Please, do some thinking rather than repeat the "government can't do anything right" propaganda meme that you got from the Republicans.
I used to work with medical software. The Veterans Health Information Systems and Technology Architecture (VistA) http://en.wikipedia.org/wiki/VistA is one of the best systems out there, as good as or better than any commercial medical information system. And it's open source.
If there's one thing the U.S. government has done well, it's develop software. I'd be interested to know what other informed people thinkl, but that's what I've seen. (As I recall, NASA employees wrote the first dBASE-style database, which was why it was so widely adopted.)
IAADC (I am a defense contractor). Actually, there are plenty of gov't contracts that are small business set-asides, which include any number of one man shops. And all the contracting shops include small-business liaison types whose job it is to make any flaming hurdles go away for small businesses. And even full & open competitions (those that are open to large businesses as well as small) frequently have small business participation goals, so the large business prime would have to go recruit some small business and give them some of the work
I really don't understand why you'd want to make it easier to hire and fire gov't employees. The gov't side is where you need more continuity. The reason you have contractors is because 1) they're frequently cheaper, and 2) they are, in fact, easier to hire & fire. The reason you need gov't employees is that contractors don't necessarily have the taxpayers best interests at heart. Not that they're lying scumbags (usually), but the incentives are different.
Sure, there are plenty of situations in which OTS software will get the job done just fine. But in the defense market... suffice it to say that you can't buy My Missile Launch Program for Windows 7... and you wouldn't want to. Prefab software is great if there's a package made for what you need to have done... but there's a whole world of software requirements out there that don't correspond to anything you can go out and buy.
For every example of software failures discussed above, you can come up with a fine example of a government system that worked great. I'm not going to spend a lot of time digging up examples, but here's one: the Navy's Aegis Combat System. Aegis is just Skynet's littler (and nicer) brother - it's vastly complex, and under certain circumstances is capable of conducting difficult anti-air battles more-or-less autonomously. It detects, tracks, and engages subsurface, surface, air, and ballistic missile threats. And yes, this was a program run by the government.
As the parent points out, the common thread in massive software implementation failures isn't that the customers were government agencies - it's that they didn't have their requirements nailed down before they started shoveling money at their problems. There's plenty of that going on in the private sector as well.
Contractors writing code for Federal Agencies is a costly problem.
Hiring government coders to work directly for Agencies that are trying to meet their missions is the correct solution--turn coders into subject matter specialists
Putting all coders into one central agency may make the sw more secure but it certainly won't make the coders more responsive to the individual Agencies and Programs.
Who won?
The dudes caught up in the endless upgrade cycle?
The dudes Terrified of upgrading the main server from XP to whatever dog and pony show is IN FASHION right now? Go COTS!! What about that Outlook express.
Every business is unique. It fills some niche. Otherwise, why would it exist? Where is the unique selling propostion? Where can I download the source for a Facebook?
Every company has ONE application the NEEDS to be custom.
One area of the business ALWAYS generates a 95% of the paperwork.
Custom software deals with this unique situation with the fewest keystrokes, the least training, and the least downtime and the most long term stability. If it doesn't, somebody did not run the project correctly.
Get your head out of the 1960's.
Custom software can be produced for about 1/100 of the cost it was back then.
Programmers are faster, better cheaper. We have the technology. We can rebuild it.
Management has not kept up. Management has sent IT out of the building and off the continent. Management is clueless. Don't worry. The Indians and the Chinese and the RUssians will set things right when then invade your sorry clueless asses.
Next time you are banging a thousand invoices and have to skip over a hundred one size fits all unused feilds, get back to me about the COTS. Oh, the software is not setup right? So your spending dollars on setup instead of programming? Now you have limited your techie pool to VERY expensive techies. That is not a win.
Who's to say that outside consultant working on your COTS isn't dumping your server out over the ethernet RIGHT NOW to your competitor?
Cutting edge tech does not have COTS.
Google is not COTS. Facebook is not COTS. iPhone is not COTS.
Enough dots yet? Need a crayon?
COMMODITY
Definition 4: a good or service whose wide availability typically leads to smaller profit margins and diminishes the importance of factors (as brand name) other than price
I am sure the russians will give 'such a deal(tm)' on missle guidance software.
This is slashdot.
The party line is that we need more programmers, more techies.
You must be from management to be spouting off such heresy.
Who let this guy in here?
Once again. The party line is 'We need more techies"
Where's your solidarity?
Have you laid sod lately? That's a lot of work!
'Cause if you ain't coding, your gonna be laying sod!
Is that what you want??
Me, I am going to be coding.
You get to lay sod.
Dummy.
Traitor.
Manager.
nearly everyone today is they are buying a package for $500
The government is not buying one package for $500, they are frequently buying a million identical packages for $500,000,000. Less some virtually useless feel-good discount.
That pays for an awful lot of in-house development or open-source tweaking.
---
Any large public or private organization paying recurring, per-seat licensing for software is being economically stupid.
Yyyyyyesss! Jobs!
There's a third issue: salaries. Programming talent is used to silicon valley pay grades, not military pay grades. How many employees would be willing to leave their current position and take a 50% pay cut to work for the government? Would you be willing to trust the code of someone working for $40K/year?
For starters, there are people in the commercial sector working for that amount, either as contractors who make a meager $60K/year with no benefits (and no O/T) or as employees doing $40-50K/year with some meager benefits (and both working 45-55hr/weeks.) It is not the norm, but it ain't that rare either.
Second, most developers (specially those graduating since the dot-com bubble) remain junior in terms of skills, and yet make salaries that are inflated wrt to their skills... and they expect they deserve it! This is more common that the previous case. Do you trust their code?
Third, consider a job with, say, the NSA. They certainly pay you below the industrial average (say $60-70K/year tops). But 1) they train you, 2) they pay your post-grad education, 3) give you benefits that are phenomenal, and 4) they give you a goal or end product (whether good or bad) that is far more stimulating than doing the same e-commerce shit all the time.
This is the problem with so many software developers nowadays. They equate quality with high salaries despite the fact that software is usually written like shit and those who write it get paid far more than in other engineering disciplines. And to add insult to injury, they equate quality of work with base salaries (without taking into consideration all the other benefits like medical coverage, fat retirement plans, and generous vacations according to seniority.)
Furthermore, how many people working out there in the software industry get paid to go get their masters as it is usually done with public/private defense-related jobs? That's one big fat amount of money being received as a benefit.
Base salaries are just part of the story, and the trustworthiness of software has more to do with processes than with individual salaries.
It's clear you've never seen the government at work. There's two issues with the govenrment writing it's own software.
1) Each individual part of the government only needs custom made software once every 5 years or so 2) Every government in the known history of mankind has been utterly incompetent in cross-department communication
Since you can't reasonably expect the government to hire teams of programmers to write software one year and sit on their asses for 4 years while there's on demand and that traditionally trying to centralize the work leads to horror stories, you can see why most governments (even the socialists) have opted for contractors.
The gist of the article is that the government (or defense contractors working on its behalf) should not rely on commercial off-the-shell software. Unless I'm missing something, the article is not about having all software *that matters* developed by developers directly under the government payroll.
Using defense contractors (which are commercial entities) for developing custom software over COTS is pretty much in tandem with the gist of the article.
Specifically, Eric S Raymond.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
Just improve the rule:
- fine vendors 10% of their annual revenues for any extra vulnerability after 5 have been found during the same year.
Then, the world would save a lot of time and money because 'security' tools, as well as patching would mostly be pointless.
Of course, this policy would only be efficient if the rule of law was applied to those who can afford to buy governments (and routinely do it).
Another day in wonderland...
If you call it something that doesn't result in an acronym of "SCO", you'll find the idea to be much more popular.
A very good first step is removing contractors from the equation
Just one thing most people forget. By and large, most technical things you all think of as "government developed" are actually developed by contractors (even if the gov't owns the code), with federal employees only existing on the management/contracting/paperwork/requirements* side of things.
* except when they contract out the requirements work, which also happens
Sorry, I thought you were advocating all-out community development of military software... my apologies. I agree that not being able to see the source code at all is a serious issue. Luckily, it's not one that we face all that often.
Hmm.
Reflecting on this more, I think you're right. Realistically, I don't think the actual GPL does anything for you that you couldn't get with a well written contract, and it introduces the scare factor into the acquisition community ("what! we can't have everyone looking at the software!"... same mistake I made). But in any case, I think we're all in violent agreement about the need for the gov't customer to be able to look at the source code.
What the Republicans don't like to say is that they can't do any better than the Dems.