April 17, 2008
What to do when developers take code snippets with them
Every good carpenter has a box of tools he carries from job to job: a hammer of just the right weight, a selection of drill bits, and so on. As he gains experience, his toolbox gets heavier with new, and sometimes specialized, equipment. Similarly, programmers accumulate their own tools as they move from job to job, but these tools are digital and often include snippets of code written over the years.
And that can create a problem, says Vishwanath Venugopalan, an enterprise software analyst with the 451 Group. These snippets are often reused unintentionally in a simple cut-and-paste operation without full knowledge of their former or current company's intellectual property (IP) policies. What's more, "the ubiquitous availability of code snippets in blogs and online tutorials poses a bigger risk to intellectual-property hygiene in a company," Venugopalan says.
Although the problem of IP pollution is probably greater in the open source world, the growing popularity of modular, reusable code (think about Salesforce.com's AppExchange) creates headaches for users and developers of commercial software as well. And that, in turn, is creating a business opportunity for a handful of specialized software companies, including Black Duck Software, Palamida, and most recently Protecode, a startup based in Ottawa, Canada.
Interestingly, none of the three major players in this niche are open source.
Protecode is a plug-in to the Eclipse IDE that detects and logs the content entering a software project, and then checks it against an online database called the Global Intellectual Property Server, or GIPS. That's much easier and more accurate than relying on memory and manual record keeping. Companies can set policies to restrict the code that can be brought into the project based on the license type (such as to restrict GPL code usage). If a programmer uses code that isn't yet licensed by the employer, Protecode will create a bill of materials needed to comply with licensing provisions.
Because Java, C, and C++ code can be developed in Eclipse, the product's integration into Eclipse lends its support for these programming languages. Protecode has indicated that Visual Basic support might be in the cards as well, says Venugopalan.
IP purity is gaining the attention of developers who work with the Department of Defense, which is using more and more open source software, despite some bureaucratic misgivings. One roadblock: the lack of a highly developed and widely recognized governance regime for open source, said Brigadier General Nickolas Justice, in a recent interview with Military Information Technology.
The Multinational Information Sharing Initiative (MISI), for example, is part of a DoD effort to share counterterrorist information among the nine countries of trans-Saharan Africa. MISI, which will also have many nonmilitary uses, was deliberately built around open source to make it easy to deploy by organizations within those countries that might balk at the hefty licenses fees charged by commercial software vendors, says Bernard Golden, CEO of Navica, which developed a governance framework for the project.
"To work with open source, you have to adhere to the letter and the spirit of the license," Golden says. Sure, that seems obvious, but MISI has to keep track of 60 or so open source products while being careful not to let unlicensed software slip into the code base. Unknown code also creates a support problem, Golden adds. After all, without knowing the provenance of the code, how can a support engineer identify and fix a problem?
Because Protecode and its competitors are privately held, it's not clear how much, if any, money they are making. A point in their favor is the relatively high bar for entering the market. The real value is in the database, which takes years to accumulate. The code itself is not that difficult to assemble, says Venugopalan.
Also unclear is the effect that HP's code analysis tool will have on the trio. It's available for download at the FOSSology Web site. What is clear, though, is the continuing development of the open source ecosystem. The stronger it gets, the more likely it is that the remaining doubters in the Pentagon and mainstream business will come aboard.
I welcome your comments, tips, and suggestions. Reach me at bill_snyder@infoworld.com.
Posted by Bill Snyder on April 17, 2008 03:00 AM
March 27, 2008
Multi-core to leave developers in dust?
Multi-core chip rivals AMD and Intel have been beating their chests as of late, but to what end, I wonder, as developers labor to keep up.
AMD, for one, has fixed the embarrassing flaw that delayed the quad-core Barcelona chip. As Terry Malloy put it in On the Waterfront, so what?
Meanwhile, Intel and Microsoft pat themselves on the back because they've donated $20 million to UC Berkley and the University of Illinois to found the Universal Parallel Computing Research Centers. Well, it's about time.
Why so negative? The dirty little secret (and it's not all that secret) is that the gap between hardware and software has never been greater. Today's software can barely (if at all) take advantage of quad-core processors, but Intel and AMD seem to be giddy with rivalry, rushing to push out chips with even more cores. Intel has already demonstrated an 80-core processor, and you can expect x86 servers with as many as 64 processor cores in 2009 and desktops with that many by 2012, says Forrester analyst James Staten.
That's not to say that the IT industry is scoffing at the potential benefits of multi-core processing. But the mountain between IT and some future multi-core promise land -- namely, the task of developing parallelized apps that keep pace with continual core advances -- is huge, says David Patterson, the Pardee Professor of Computing Science at UC Berkeley and director of the parallel computing lab. "It's the biggest challenge in 50 years of computing. If we do this, it's a chance to reset the foundation of computing."
In the short run, Patterson says, we can parallelize legacy software and gamble on getting value out of eight cores. But that would be only an interim solution, as such apps would not scale to 32 or 64 cores, he adds.
What is frustrating is that this problem didn't exactly sneak up on the industry. Chip development cycles are very long, and key software developers are well aware of what's moving through the pipeline. Sure, software always lags hardware. Many of us complained that we didn't have software that would take advantage of 500MHz back in the '90s. But what Patterson and others call the multi-core revolution poses problems for developers that are qualitatively different than the problems of the past. Why wait so long to get serious about solving them?
Making sense of the multi-core muddle
The cynical explanation for this growing gap is that Intel and AMD are running on a treadmill that requires selling more and more transistors to support the cost of developing and building fabs. As long as buyers are willing to spend the money for cool new hardware, who cares if they don't really need it?
Ray DePaul, president and CEO of RapidMind, which sells a multi-core software development platform, has a different take.
"The first multi-core chips were dual core, and that lulled everyone into thinking this is OK," DePaul says.
Taking advantage of the second core was relatively easy with existing software. But four cores is another story.
"It's the classic disruptive technology," DePaul says. "If the Microsofts and the Intels always got it right, you'd never see a Google or an AMD."
RapidMind hopes to avoid following in the wake of companies such as Thinking Machines and nCUBE, which attempted to build businesses around solving the parallel computing problem without success. I'm not qualified to say whether the RapidMind solution, which includes an embedded API to allow legacy software to take advantage of multiple cores, is viable. But I agree with DePaul when he says, "The business opportunity is far more mainstream than it was because every desktop is shipped with a multi-core processor."
RapidMind spun out of the University of Waterloo in Ontario, where co-founder Michael McCool studied the problems of parallel computing for years. A one-time competitor called PeakStream was purchased by Google last year. It's unclear what the search giant intends to do with the technology, though it may well use it internally to bolster its already enormous computing resources.
In addition to the business opportunity, there's an employment opportunity here as well. Developers who can handle parallel processing or concurrent processing are going to be in great demand. Indeed, UC's Patterson says: "We feel a sense of allegiance to our undergrads but don't know what to teach them. Course work is all focused on sequential [programming] problems."
I don't feel like doing the math, but I'll bet Intel and Microsoft earn $20 million in a matter of hours. So, yeah, I congratulate them for funding some research, but they and other industry heavyweights need to do a lot more. If not, maybe we'll wise up and stop buying what they're selling.
I welcome your comments, tips and suggestions. Reach me at bill_snyder@infoworld.com
Posted by Bill Snyder on March 27, 2008 03:00 AM
