"Still don't think open source hurts commercial software? Guess again"

January 18, 2012 By Paul Krill | InfoWorld

A Comment...

Open Source is becoming a radical challenge for premium software companies that depend on what are now exorbitant prices.

These companies have been built on the cornerstone of customer lock-in. Once deployed, their large, complex, expensive products are usually too unwieldy and too costy to replace except as part of a massive system architecture upgrade as we were forced to do for Y2K.

How can a company excel if it's not free to do things differently from its competition? The high cost of enhancements to one of these installations keep most somewhere near the basic package. This stifles innovation and competitiveness.

In short, these premium companies have priced themselves out of the market.

Open Source software, while free in initial price, does have costs that many a CIO has yet to appreciate. Though at least as reliable (usually more so) as its commercial counterparts, Open Source software is largely developed by and for programmers and thus requires a deeper level programming and system administration expertise to maintain. That usually means more, and more experienced, and thus more expensive staff.

Here are two simple rules of thumb in deciding between commercial and open source software...

ONE...
If you have more money than expertise, buy commercial.

If you have more expertise than money, use open source.

TWO...
If software in no way effects your competitiveness, buy commercial like everyone else.

If software can in any way effect your competitiveness, use open source for the freedom it gives you to innovate.

By Extension

December 18, 2011 by Robert C. Watson

Seeing What We Expect to See

I'm a Unix/Linux programmer. It capitalizes on my tendency to take what I see quite literally. By making few assumptions, I'm able to see the problem as the computer does.

By contrast, "normal human thinking" depends heavily on our imagination filling in many blanks. We have to make lots of assumptions. Those assumptions cause us to see what we've seen before... what we expect to see.

With almost all of my attention on Unix/Linux over the years, I've mostly just used Microsoft Windows and Office as tools and not followed their inner workings much. Long ago, I attempted to decipher the raw format of a Microsoft Word document (and failed to do so reliably). It left me with a mental image of Word documents consisting of intermixed binary values and text that only Microsoft understood.

A few years later, someone sent me a document in Microsoft Word 2007's new .docx format that I needed to convert to HTML for the web. I only had Office 2003 and was horrified by the mess Word made when exported "As a web page". So I proceeded to read the document into a text editor to see if I could just cut out the content and reformat it by hand. Knowing it was supposed to be XML, that's what I was expecting to see. What I saw instead was gibberish -- pure binary.

"Damn that Microsoft!"

Sliding back and forth through the sizable document and finding no blocks of text or other discernible patterns, I brought up Firefox and started many hours of Googling.

Now one thing I've learned over the years is that, for me at least, there's a very consistent inverse relationship between the intractability of a problem and the complexity of its solution. The longer it takes to solve it, the more simple the solution is likely to be. Assumptions and expectations lead me down an increasingly complex path of study, experimentation and failure as I exhaust "obvious" solutions. (Is "Occam's Razor" misunderstood?)

Lots of Googling have also taught me that simple, fundamental facts and concepts about a piece of software are often documented only once and thus rarely found in search results. Assumptions again.

The more intractable the problem, the more likely that the solution hinges on one of these obscure bits of information.

I finally came across somebody in a forum explaining the new format to a newbie (A Newbie! A Noob! How mortifying...) and discovered that in the world of Microsoft...

Though a .docx is named much like a .doc, looks like a .doc and is used like a doc... it's really a .zip!

"HP dumps WebOS on open source world"

December 09, 2011 By Ted Samson | InfoWorld

A Comment...

I'm glad HP took my advice, though it was kind of a no-brainer.

I've read a number of positive things about webOS from developers working with it. Unlike in the market-driven world of commercial software, webOS only needs to do something - anything, especially well to be adopted in whole or in part by the purely innovation-driven Open Source community.

Since webOS is based on the Linux 2.6.24 kernel, I would expect future webOS development to probably lean towards being another Open Source alternative to Android on small devices. Maybe Google will adopt it if there's something in it they can use.

Commercial software has become so dominated by market forces to the exclusion of functionality, quality, reliability and value, that the industry seems to be coalescing into two camps -- Open Source, where most of the R&D innovation occurs; and Commercial, where they assemble those innovations into commercially viable packages and market them.

Businesses and individuals that want finished products and have more money than time or computing skill, buy commercial software and support. Businesses that need specialized mission-critical software that gives them a competitive edge over their competition or companies and individuals with more time and/or computing skill than money, choose Open Source for some or all of their operations.

Linux (and perhaps webOS) is the Lowes or Home Depot of software whereas Microsoft is the Ethan-Allen Home Furnishings.

How much you want to bet Ethan-Allen's manufacturers have long-standing accounts at Lowes and Home Depot?
  

"Watch out for FOSS advertising"

October 17, 2011 By Susan Perschke | Network World

A Comment...

Most FOSS (Free and Open Source Software) is D-I-Y (Do It Yourself) software.

It is written by programmers, for programmers.

Programmers, government agencies and competitive companies choose FOSS when they need innovation. They choose FOSS for the same reasons they send their staff to Lowes, Home Depot, Staples, and FedEx Office (formerly Kinko's)... to get things from which they can inexpensively fashion unique solutions that make them more efficient.

Why do it yourself?
Like the 1920's, the "roaring" 1990's overheated the economy as everyone clamored for the latest computer technology. While the cost to produce the technology itself dropped like a rock, insatiable demand for related services drove the human costs through the roof. The tech bubble inevitably burst.

The ubiquity of cheap computing power and laissez-faire economic policies had spawned financial instruments too complex for reliable risk analysis. So a few years later, the financial bubble burst as well, putting us in our current "Great Recession".

"The 1%" financial titans still have much more money than time so they continue to buy highly polished commercial software, layoff most of their tech staff, and pay companies like Microsoft, Oracle and SAP enormous amounts for licensing and support. What choice do they have? A major failure could put them out of business very quickly.

But "the 99%" of people, governments and companies, just as in The Great Depression, can no longer afford those high-priced finished products. With layoffs, virtually frozen wages, and less disposable income, Americans now have more time than money. Survival depends on finding new, more efficient and cost-effective ways of doing things.

Is FOSS Secure?
Any retailer with a glass storefront will tell you that police strongly recommend the glass be kept clear of obstructions and the store interior be kept lit after hours so anyone can see in. Transparency is the best deterrent to crime as well as the best way to spot crimes in progress.

That's the principle FOSS security is based on -- transparency.

If you were a careless or malicious programmer, which kind software would you prefer to put your dangerous code in? Closed, where few if any can find it, or Open where anyone can find it and you don't know who or how many will?

It's as simple as that.

The same reasoning combines with speed of development to account for the explosion in scripting languages where the source code couldn't be more accessible.

The explosion of freely available information makes the ubiquitous concept of "security by obscurity" a complete fantasy promoted to sell software.

Then how do you separate the wheat from the chaff?
FOSS is like an open bazaar or swap-meet with free or virtually free stalls. Anyone with programming skill can distribute their work.

In today's economy, the unemployed can learn how to program with countless free resources on the web. They then can create things others will want and distribute them to thousands. They build up a "portfolio" of work on their blogs and web pages. If they're good, they gain a reputation that gets them hired or allows them to build their own company selling software and/or services.

Here's how to find the best of the best...

• The less you know about programming, the more discriminating you should be. Look for mature, widely used software like Firefox, Ubuntu Linux, and the LibreOffice suite.
• Search the internet widely for reviews, comparisons, bug reports and questions on forums. The later will give you a feel for how widely used the software is as well as the kinds of bugs it has and how easy they are to fix or work around.
• A NOTE OF CAUTION!
  Judge bugs by their quality, not their quantity!
  All software has bugs! Because expensive commercial software is not open, its bugs are not as widely documented as those in free and open source software. You'll find a lot more bug reports for FOSS. If you study them, you'll find many are duplicates as many websites republish bugs listed elsewhere. 
• If you're not an experienced programmer and are worried about a program that does what you want but is new or not that widely used, find an experienced programmer friend, staffer or consultant who can read the language and get them to scan the code.
• Is it well organized or is it confusing?
• Are there suspicious looking sections?
• Prefer software with the most downloads.
• Quality ratings are not as reliable as number of downloads.
• New software will usually have higher ratings due to its small number of downloads and reviewers.
• A high number of downloads/day factors in to longevity.
• New or obsolete software will tend to have lower counts.
• If two programs have similar numbers of downloads and downloads/day, then check the ratings but don't put much stock in small differences. Look for low vs high.

"Ex-Amazonian urges Google to sample Amazon's secret sauce"

October 12, 2011 | by Ted Samson | InfoWorld
A Comment...

Amazon could be more innovative like Google and Google could be more organized like Amazon.

Sounds like they both need to make in-depth information about their respective products easier to find by their developers and support staff. Google is the undisputed master of keyword search so they have half the problem solved. The other half is continuing to perfect their structured data where the right answer can be located much more quickly than exploring a lot of hits from keyword searches.

Because new hires learning the products are actively engaged in assimilating new information, their pattern-matching skills are in overdrive. That makes them great at recognizing similarities that can be recoded into a single routine and put in libraries to be reused.

Just because it's in a library though, doesn't mean it will be used. As much, and often more, effort is thus put into cataloging, thorough hyperlinking and other mechanisms to make all that information a few clicks away.

To be reusable, code must be 100% reliable, 200% documented and 300% easier to use. If it's not, developers will write their own.

Amazon's "platform oriented culture" has (hopefully) created a new profit center for them to keep paying the bills since they don't have Google's massive advertising revenues and their founding product -- book sales -- has a bleak future.

Google's "product oriented culture" keeps them innovative while, so far at least, advertising pays the bills. Most of their eggs are in that advertising basket though. Leveraging their massive infrastructure, creative talent and socially responsible policies to provide large-scale computing resources provides another source of revenue (and makes the world a better place at the same time).
  

"ARM's 64-bit ambitions spell more trouble for Intel and AMD"

October 27, 2011 | by Ted Samson | InfoWorld

A Comment...

I have to wonder if the 64-bit ARMv8 architecture announcement is a case of overreaching. Announcing technology that is 2 years away sounds like "me-too-ism" or just FUD.

Their recent successes may have investors or principals seeing dollar signs and the chance to play with the big boys, but they should take care that they don't promise more than they can deliver.

Will this race into 64-bit force ARM to sacrifice their "crown jewels" of energy-efficiency, quality and programmability in order to release new chips on schedule?

That's why people are buying ARM. If ARM lets Intel and AMD push them into playing by their rules, ARM can't compete.

ARM can only compete by producing a better product than Intel and AMD.

Remember that the Apple-II 8-bit 6502 CPU ran at 1MHz when its principle competitor, the Z80, was partially 16-bit and ran at 2.5 to 8 times faster. People couldn't tell the difference between them in normal use though because the 6502 provided a more efficient instruction set. That it was a small fraction of the price didn't hurt either.

An inexpensive 32-bit ARM processor that allows manufacturers to build smartphones, tablets, laptops, PCs and even servers that can run on battery for 7 or 8 hours will probably have a much larger market than a 10 Gazillion-Hz CPU that has to be housed at the North Pole next to its nuclear reactor power supply.

They sell a lot more SUVs than they do Formula-1 racers.
  

"Fed. Government Pays IT Contractors Nearly Twice As Much As Its Own IT Workers"

By Stephanie Overby, CIO, Wed, September 14, 2011

A Comment...

Finally! Somebody crunched the numbers and put them in a form everyone can understand. Now that their small pilot project of the Federal government has proven it can be done, POGO should move on to where the real waste, fraud and abuse is -- State Governments.

Let's summarize...

• Public employees, in all fields, have always been, and probably always will be, paid less than private industry employees doing the same work, with the same experience, and the same level of quality. The trade off used to be better job security, but that is rapidly disappearing with no increase in pay.
  
• For the typical government contractor, its salaries are higher, it has additional staff and resources dedicated to nothing but obtaining and managing contracts, and it has to make a profit.

Where in all that is there room for any cost savings?

Blasphemy Warning!

The mantra that "Anything government can do, private business can do better" is a fraud. It is pure marketing. There is no factual basis for it whatsoever.

Government, like business, has its share of slackers, "creative advancement strategists" and "funding siphoners".

Unlike business, it usually can't keep them hidden for long.

If businesses were required to be as open as government, people would vote to vastly expand government because it does everything far cheaper and most importantly... far more beneficially to you and me.

The Founding Fathers wisely realized (after much heated argument) that our success as a country depended on always maintaining a healthy balance between competing interests. In this case -- government and business.

Business interests on the other hand, have spent the last 235 years dismantling that principal. They've spent the last 30 years constantly screaming "government is too big", though it is far smaller than it needs to be. In doing so, the gargantuan business community has succeded in taking over the country and virtually enslaving (albeit, lavishly) our elected officials.

If all outsourcing were eliminated tomorrow, within 2 years I think we could pay off the national debt and buy Canada (Okay, maybe only British Columbia and the Yukon - so we're contiguous with Alaska.)

But the way things are going, it may be Canada that buys us. (Works for me!)

I don't doubt for a minute that American business would sell if the price were right!

"The cloud hazard no one talks about"

September 19, 2011 By Paul Venezia | InfoWorld

A Comment...

Information management is like transportation.

Mass-transit only works well in very populous areas and with lots of redundancy in the system. That's why most people drive cars.

Cloud computing is "mass-transit" for information.

Local processing is like having your own car.

Cloud computing is a solution desperately in search of a problem. Its marketing appeals to the near-sighted, the cheapskates, the people who never think about disaster planning and have to be rescued, at great risk to others, when it happens.

Reliable systems are built by minimizing variables and risks.

Functionality should be implemented as close to the user as technology allows. Anything above first level (i.e. desktop, laptop, phone, etc.) should be asynchronous with alternatives if all the redundant links are down.

Cloud computing's usefulness is not in reducing costs.

Cloud computing's usefulness is in improved reliability through redundancy.
 

Reliable Software

We've known for decades how to prevent software bugs...

1. Design from the top down and build from the bottom up.
   Only reuse modules that are completely debugged and reliable. Code built on unreliable code will be unreliable no mater how perfect it is.
   (Here I use "module" generically to mean any identifiable block of code... variously called "subroutine", "method", "procedure", "function", "macro", etc.)
   
   
2. Don't allow any module to have side effects.
   Side effects cannot be documented sufficiently to make them fully known for future work. They are thus inherently unreliable.
   
   
3. Software development is non-linear. Plan For It!
   An "80/20" rule is far closer to reality than the linear projections forced upon most software projects. To produce reasonably reliable software (we're not even going for "bug-free" nirvana here), about 80% of the development time will be spent on the 20% of the code at the bottom -- the lowest level -- the first modules upon which everything else is built.
   
   
4. Large groups cannot produce good software.
   Practically perfect software can only be produced by a team of... one. No one can wait long enough for one person to build the huge systems used today though so we have to sacrifice some perfection for the timeliness that teams can achieve. Teams of up to around 10, where each member excels in a different discipline and is responsible for a well-defined component of the project (i.e. GUI, business logic, database, testing, cat herding, etc.) can work well. Cat herders (leaders) unthreatened by more technically skilled team members can be hard to find though. We need to cultivate more of them.
   

Software development as it exists today, with its total obsession with speed of development, is untenable.

In business, software is the embodiment of a company's competitive strengths. How can a company that does everything just like their competitors hope to best them?

Government and non-profits are highly dynamic and diverse in their missions. Every software project is thus unique. How can they afford to pay the premium of profits on inferior products with their comparatively modest budgets?

Commercial software products today are much like America's luxurious but highly unreliable cars of the mid-twentieth century.... no longer affordable.

Open source projects and in-house development build on a much greater depth of knowledge of the processes being automated and thus produce more reliable and more productive systems.

Can we afford not to change?