SourceLabs is often lumped into a category that the media refers to as Open Source stack providers, a designation we find curious as it doesn't represent how customers view the world at all. Customers buy solutions. Examples of solutions include: grid infrastructure to squeeze more capacity out of existing computing investments, CRM software to make sure the ball doesn't get dropped on a customer interaction, or Java Middleware to provide a development and deployment platform for enterprise applications. A collection of Open Source projects (no matter how exhaustive) packaged together is a way to fill up disc space, not a solution.

Providing a solution means committing to understand specific customer environments and requirements in-depth. This kind of focus has lead SourceLabs to create unique services to meet the needs of enterprise customers who depend on Java middleware. Examples include our continuous feeds that track and alert customers to security issues and other software vulnerabilities, our triage process that uncovers and addresses software defects pro-actively, our certification of Open Source software with proprietary enterprise systems like IBM WebSphere and BEA Weblogic, and the stress and configuration testing that we use to shake out and repair software defects during our certification process.

Just as there is not a market for "proprietary software stack providers" there is not a market for "Open Source stack providers." What there are markets for is Open Source solutions. Customers recognize that one size does not fit all, and that software and support for mission critical computing environments is a best of breed proposition.

While software "code" may be increasingly "commodifying", the quality of software support services (as measured by timeliness and accuracy of issue resolution) presents an opportunity to address enterprise customers' long-standing dissatisfaction with software vendors. Why should a Fortune 500 company have to wait six weeks (or even six days!) for their support issues to be resolved? SourceLabs goal is to improve software support with innovative technology, and to provide the most reliable, tested infrastructure software available anywhere.

We've warned you for a decade. Now the monster has finally arrived: attacks against Open Source developers by patent holders, big and small. One is a lawsuit against Red Hat for the use of the principle of Object Relational Mapping used in Hibernate, a popular component of enterprise Java applications everywhere. The other attack is on an individual Open Source developer for his model railroad software.

These two attacks are the tip of the iceberg, thousands more are possible as software patent holders turn to enforcement as an income producer and away from the patent cross-licensing détente exercised by large companies until the mid-1990s. Open Source will not be the only victim: small and medium-sized companies make up 80% of our economy and any of those companies that develops software, either proprietary or Open Source, will be vulnerable. The American IP Law Association estimates that defense against a single software patent lawsuit will cost between 2 and 5 Million dollars. Under US law, even a company that only uses software can be sued.

The suit against Red Hat's concerns the use of software "objects" to encapsulate a database record and make it easier to access, a technology called Object Relational Mapping or The ActiveRecord Pattern. That technology is used in the Hibernate software developed by jBoss, which Red Hat recently purchased. FireStar Software claims that it invented the technology, and that it is covered by its U.S. patent number 6,101,502. However, over the past two decades there has been much prior art for object-oriented databases, including TopLink, an object relational system developed in the early 90's and now owned by Oracle, so it may be that the filers of FireStar's patent made no invention.

There's also the question of obviousness, whether the principles claimed in the patent would be obvious to a normally-skilled practitioner of the software art and thus not be an invention at all. The function of an object is to encapsulate data, and object-oriented programming has been known since the Simula language introduced it in 1967. The U.S. Supreme Court is currently reviewing another patent lawsuit in which the defense claims that there should be a much higher standard below which purported inventions would be considered obvious and thus not patentable. A higher standard of obviousness could help, but the real solution is to go back to the original intent of the Patent Office and stop granting patents on software.

Should FireStar prevail, or should Red Hat be foreced to settle, Open Source use of the object-relational paradigm, including that in Hibernate, PHP, and Ruby on Rails, might become impossible. Recently RIM Systems, maker of the ubiquitous Blackberry, settled their patent case with NTP for half a Billion dollars, after most of NTP's patent claims had been overturned by the patent office! In that case, the patent office ruled the patents invalid after the judge rendered his verdict in the lawsuit, and the judge refused to reconsider. Justice seems to be hard to find where software patents are concerned.

Red Hat will probably stick with the FireStar case rather than settle, but how many of them can it sustain? It's not possible to write a significant program today without using a principle covered by a current U.S. software patent. A study of patents possibly infringed within the Linux kernel found 283 of them in 2004. And that's just one program out of the thousands that make up a Linux distribution.

The other current patent attack against Open Source faces Bob Jacobsen, the developer of the JMRI model-railroad control software. Jacobsen gives his work away, with full source code. He is faced with an invoice for over $200,000 from Michael A. Katzer and his company KAM, $19 for every copy of JMRI that Jacobsen gave away. KAM filed a patent making a broad claim covering the transmission of model-railroad control commands between multiple devices in 2002. Again, there's prior art: this technology probably goes back to the MIT Model Railroad Club in the 1960's. But Jacobsen could easily go bankrupt in defending himself or paying KAM's claim. Because the cost of a patent defense is many times the net worth of the typical Open Source developer, it's difficult to see how there can be justice for the little guy.

These patent attacks come at an interesting time, as SCO's lawsuit against IBM starts to collapse. But while SCO's case was never well-constructed, a software patent case is much more substantial. It's possible to invalidate some patent claims in court or at the patent office, but some of the potentially thousands that can be brought against significant Open Source programs will be found to be legitimate.

There is also the specter of patent shake-down operations, like Intellectual Ventures. Founded by ex-Microsoft executive Nathan Myhrvold and touted as a means to "encourage innovation", it appears to be a litigation factory in the making. Intellectual Ventures has been purchasing patents to construct a portfolio that it will then assert against someone, probably small and medium-sized businesses to start with. Most businesses, when faced with the prospect of an expensive patent infringement lawsuit, choose to pay a license fee, or shall we call it an extortion fee, rather than go to court and spend so much that even when they win, they lose. Income from license fees will fuel more attacks on more businesses. The effect of Myhrvold's business on Open Source could be crippling. But Microsoft, Intel, Apple, Google, and eBay have nothing to fear. They invested in the company, and will be excluded from attacks.

All of this could be excused if it only encouraged innovation, which is supposed to be the purpose of the patent system. Patents were created as a means to get inventors to disclose their inventions, rather than keep them secret. The disclosure of an invention was supposed to allow others to more easily build on that invention, thus creating more inventions. But the patent system has evolved into something useless for the purpose of disclosure, and engineers are now instructed to avoid looking at other companies patents because if the victim of a patent lawsuit can be shown to have known of a patent, the award to the patent holder is tripled. There have been no reliable studies that show software patenting to have encouraged innovation, and there is much evidence that they actually impede it. Computer programs are already protected by copyright, and that protection is sufficient to protect proprietary software businesses. Software is unique in that it is protected by both copyright and patents, other industries have one or the other and that is sufficient for them.

There are many other problems with software patenting, too many for me to cover in one piece. But you can see my essays The Problem of Software Patent in Standards, Software Patents vs. Free Software, and The Open Source Patent Conundrum, and my State of Open Source message.

Even the United States Patent Office thought software patents were a bad idea. It was forced to grant them by the Supreme Court, in a lawsuit brought by IBM. More recently, there has been news about Europe resisting a big-company push to make software patents enforcible, a fight that will continue when the question comes up again next month in Brussels. Large companies, including some otherwise perceived as friends of Open Source like IBM, HP, Nokia, and Philips, continue to push for increases in software patenting as a means of fighting disruptive technologies from smaller companies and Open Source incursions into their proprietary software markets. This is a big-company vs. little-guy fight. Despite the fact that the "little guy" represents most of the economy and the main sources of innovation, the big companies have the political connections and thousands of full-time lobbyists, and they are winning.

Over the past decade, Open Source has shown itself to be a better paradigm for supporting software innovation than a software patenting system ever could be. Open Source developers share both principles and the actual implementation, and allow anyone to build upon their work. The Linux kernel development, just a single example of Open Source success at innovation, has been the fastest and most broad-ranging of any operating system project ever attempted, and has achieved many capabilities that are unmatched by proprietary operating systems.

But we should not be confident that we will continue to have the right to use and develop Open Source software. A coordinated patent attack by a few companies, or even one large company, could completely destroy Open Source in the United States and cripple it in other nations. Funds and patent portfolios that have been established to help defend Open Source would not be sufficient to defend it. Only legislative changes to the patent system can fully protect Open Source and maintain it as a viable source of innovation for our future.

Bruce Perens may be best known as the creator of the Open Source Definition, the manifesto of Open Source and the canonical rule set for Open Source licensing. He is currently a vice president of Sourcelabs. He is series editor of Bruce Perens' Open Source Series with Prentice Hall PTR Publishers, which has published 24 books with all of their text under an Open Source license. He is a visiting lecturer at Agder University College in Norway, and has been a scientist with George Washington University's Cyber Security Policy Research Institute. He was formerly a director of Open Source Risk Management, a company that was involved in protecting against intellectual property risk of Open Source software, and was HP's Senior Global Strategist for Linux and Open Source. He was CEO of Linux Capital Group. He is a husband, and the father of a wonderful six-year-old whom he hopes will live in freedom when he grows up. And that's why he's working so hard on issues like this today.

It’s been a lot of fun discussing the Continuous Support System with folks over the past few days, and with customers over the past year, as its technology SourceLabs has invested in heavily – and quietly – since the day we were founded. It’s always nice when a new innovation finally enters the public world. And it’s been hard to keep quiet for the the past two years while we developed and refined the system to meet the demands of our large enterprise customers.

The first time we really started talking about the system was before SourceLabs was founded. I drove down to South Seattle to meet Will Pugh, an extremely talented engineer who had recently left BEA Systems, where he had worked with me. I was excited about the opportunity for Will to join me in a venture I was summarizing at the time as “Dell for Software”. Will picked one of his favorite lunch spots in his neighborhood, and we met up, and I pitched him the idea for what I was then calling “Stratocaster” – a reference to the guitar I had recently learned to play, and the inspiration that Napster had given me for thinking about the open source community.

As Will and I began talking, he very quickly got the idea – and something else. I told him how nobody had really focused on being great at support and maintenance for enterprise server software, which is a bit odd since it’s a $10 Billion-plus market. I said that at the new company, the smart people would focus on doing a great job at support and maintenance, rather than building new features for software that was already commoditized. As Will listened, I could tell that the lights were going off in his head.

Will immediately began talking about ideas he had for what those “smart people” would work on building. Technology that would actually gather information about the operation and failures of open source software as it ran, so that support could be faster and more effective. I deferred completely to Will on this because it wasn’t an area of my expertise, and he had a lot of experience in building debuggers.

As we kept talking, it became clear that we’d be able to gather a lot of useful information. What could we do with this information? We started to brainstorm about developing a repository of all the information we had gathered, so that each time a customer encountered an issue, they could benefit from the experiences of the past customer, and as a result often find their problems more quickly resolved not just because we had the technology, but because had the information required to enable support engineers to do their jobs better.

Later I started chatting with Cornelius Willis, who had run developer marketing at BEA, and knew it would be great to have him on board to found the new company. We’d get together at a cafe near my house, Zoka, and chat about strategy. Cornelius was super skeptical at first for how SourceLabs could be different from pure “services” businesses, and how it could be competitive with some of the largest companies around. We started to brainstorm about what sort of technology we could build to accomplish that, and after more than a few coffees together Cornelius agreed to co-found the company with Will and I.

It seemed like we had come a long way, but the hard parts – actually designing and building the technology – were still ahead of us.

* What would be an efficient way to represent, search, and query the huge amounts of data we were generating?
* How could we design and implement probes that communicated securely with the outside world, and that had minimal impact on the production system being probed?
* What would be the “right” user interface for interacting with and subscribing to all this information?
* How would we handle the diverse formats of data throughout the Internet, and the fact that those formats change (and the data can become unavailable) unpredictably?
* How would we make sure that the probes enabled customers to protect the privacy of their information as much as they desire, without creating a huge amount of overhead work or diminishing the effectiveness of the probes?
* How could the probes be implemented so that they could be dynamically reconfigured “on the fly”?
* How could we make sure that our database and our daily notifications could scale properly to ensure the quality of service our customers expect?
* How could we make the notification services completely customizable as well as scalable?
* Etc.!

Internet providers are trying to figure out how to survive when their users are streaming gigabytes worth of media and making IP phone calls instead of viewing the web pages that their account pricing structure expected. Congress people are trying to find an incentive for network providers to build more infrastructure in a market that looks to be wildly more costly than present as bandwidth demand rises. Some suggest a tiered internet, making the big content companies pay the internet provider. But where does that leave the little guy with a political message that should be heard, the new startup with a disruptive technology, and the internet provider's competitor?

The solution to escalating bandwidth demands isn't a tiered internet, it's selling quality-of-service.

Streaming media and VoIP depend on quality-of-service, a very different quantity from raw bandwidth. Sure, your internet provider says you get six megabytes per second, but when, and how steadily? Those are the questions that quality-of-service guarantees answer.

Quality-of-service is frequently abbreviated as QoS. A VoIP phone call depends on real-time quality-of-service if it is to approach the routine quality standard of conventional telephone service. A certain number of bytes must be transmitted between each end of a connection every tenth of a second, and dropped packets will be noticed. If your internet provider pauses sending packets for a second, your phone call is cut off for that second.

But if you are viewing web pages instead of chatting on the phone, you might not even notice that one-second gap. While downloading a music file to be played later, you notice the speed at which the entire file is transferred, not whether the transfer is steady or goes in leaps and bounds.

Streaming media is different too. Usually, a streaming media viewer buffers many seconds of programming ahead of what you're seeing or listening to. Twenty seconds of buffer isn't unusual, and if a basketball game is delayed one minute from the real event, you'll probably be none the wiser. However many seconds your viewer has buffered, it can cover up that long a gap in transmission. So, the internet provider might slow down your connection for a minute during that basketball game, and you wouldn't notice. The quality-of-service required for streaming media includes the ability to deliver a certain number of bytes over time, but allows leaps, bounds, and gaps that would be intolerable for a VoIP call.

So, you can see that four different types of web usage each require a different quality of service. It's probable that your internet contract doesn't guarantee the quality of service required for VoIP or streaming media at all. That might have been OK when only alpha-Geeks used VoIP and streaming media, and they were like motorcyclists cutting between lanes of plodding cars. Now that so many more people are using facilities that demand a high quality-of-service, internet providers might not be able to provide it any longer. And they aren't obligated to do so.

Internet providers should be able to sell quality-of-service now. If you want VoIP, you should pay for VoIP quality-of-service. And of course the same for streaming media. If you don't pay for that, your account should still be fine for viewing web pages and downloading files that you view later. And it might still work for VoIP and streaming media, especially at times when there are fewer customers online.

Since customers won't generally want to read a quality-of-service specification, a technical thing of bandwidth and timing numbers, there's room for standards organizations to provide simple names for different sorts of quality-of-service guarantees that can be compared between different internet providers.

Operating systems and applications have a role in quality-of-service as well. Internet protocols include quality-of-service indicators that can be set for different sorts of use. Programs that view streaming media should set different indicators than ones that make VoIP calls, and programs that download files for later viewing should indicate that it's OK to let VoIP or streaming cut in front of them if necessary. Unfortunately, recent Microsoft operating systems always set the indicators to ask for the maximum possible quality-of-service at all times. Some non-Microsoft software does that too. I guess it makes benchmarks run faster, but at the cost of making it impossible to deliver a high quality-of-service where it's really needed. When software fibs about the quality-of-service it needs, your internet provider's router doesn't have the information it needs to give reliable service to a phone call at the cost of delaying a download for a second.

Providing the right quality-of-service indicators is a responsibility that all software vendors must now take seriously. And customers are going to have to take interest in the quality-of-service guarantees that come with their internet connection.

The issues with bloatware are pretty severe when you’re talking about a large-scale deployment (100s or 1000s of servers) for large applications. “Feature frenzy” means its harder to develop on a platform (too much to learn just to do basic things), harder to test out what you’ve built (dev environments and production environments tend to be very different), harder to manage, and harder to support. Add up all those additional costs, and chances are it far outweighs the benefit of the “latest and greatest” features – even if you do happen to be using them.

Open source tends to be different. Take open source Java, for example – a topic near and dear to SourceLabs’ heart. You can get up and running on Tomcat in under an hour, and build simple web applications (it’s some work to download, install the database and configure it correctly, alas…) Compare this to many commercial J2EE application servers. Some of them come on 10s of disks, and can take days to install. I recently encountered one Proof of Concept where it took over 5 system engineers from a vendor ONE WEEK just to install their application server and get it running. Want to do something more complicated? Add the SourceLabs SASH stack to the mix, and you have a platform capable of most things – save distributed transactions. more advanced management capabilities and messaging – than you get from a “full blown” J2EE application server. We have yet to compare the TCO for the two alternatives, but we have several customers who have estimated 20-40% less costs than with a “proprietary” alternative.