Author Profile - Steve Goodman is CEO of PacketTrap Networks. Steve was previously Vice President of the Storage and Business Continuity Business Unit at SonicWALL (NASDAQ: SNWL), a leading provider of network security and IT infrastructure solutions. Steve successfully built the Storage Business Unit from zero to over a $20 MM run rate in less than two years. Previous to SonicWALL, Steve was founder and CEO of Lasso Logic, a continuous data protection (CDP) appliance company focused on IT disaster recovery solutions. Steve has a M.S. in Computer Science from The George Washington University. Steve's addiction to high stakes poker matches has had no impact on his ability to lead PacketTrap Networks.
Why We Must Embrace the Open Source Community & IT Departments that use Open Source Products
The use of open source software has become increasingly popular in production environments, as well as in research and software development. One obvious attraction is the low cost of acquisition. Commercial software has a higher initial cost, though it usually has advantages such as support and training. A number of commercial vendors today use open source software as a central component of their product or service, but layer on proprietary components to add value. These companies are called Proprietary Open Source Software (POSS) providers.
There’s general agreement that software initiatives fit into one of three categories: open source projects (i.e., mySQL, various Linux projects, Nagios, OpenNMS), traditional software vendors (i.e. PacketTrap), and, as mentioned, POSS vendors (i.e. Hyperic, GroundWorkOpen). While each of these models has its advantages and disadvantages, it’s common for commercial software vendors to disparage open source efforts as a collection of loosely connected, poorly controlled volunteers with cavalier attitudes. Also, these commercial vendors suggest that open source is poorly supported and that the soft labor cost of implementation and maintenance is overlooked. Perhaps they’re right, perhaps they’re wrong, but it is important to recognize there are a significant percentage of IT departments that believe in open source either because it’s free, or because it’s highly extensible and flexible.
This paper explores positions that open source solutions are essential for IT departments in their mission to support their users. Specifically, it speaks to:
- Why we must believe that open source is an extremely important and many times essential component of network management approaches;
- How we can integrate open source products such as Nagios, MRTG, and Cacti into its approach, and;
- Why IT departments should be skeptical of POSS vendors because shareholder profit motive overrides community and, for this reason, the long term viability of these companies is questionable.
While we believe that many will follow, PacketTrap is one of the first traditional software vendors to fully support the open source community without tampering with the underlying benefits and mechanics of open source development generally. As evidence, PacketTrap products include an interface that is conducive to easy integration of open source solutions. PacketTrap believes that the commercialization of open source by the POSS vendors such as Hyperic and GroundWork Open, however, skillfully undermines the original goal of open source projects - to develop strong software solutions without the negative effects of commercial vendor profit motive.
This position begs several questions. First, why would a traditional software vendor adopt a supportive approach to open source network management when doing so may take away market share? Second, what’s the intent behind a traditional software vendor‘s claim that the commercialization of open source by these so-called POSS vendors is inherently bad? These statements seem to be inherently inconsistent.
Open Source is Essential in the IT Departments of Small, Medium, and Large Companies.
Before discussing the tremendous value of open source software, let’s put aside one of the most common drivers of open source use – it’s free. There are many reasons to implement open source technologies, and there are many reasons to implement commercial approaches. One argument that can be easily dismissed however is the cost difference between the two. After evaluating numerous business models for open source software and commercial / open source hybridization, one observation becomes clear: There is no such thing as free open source software. Sure, you're free to download the software and you're free to modify it, but it's important to remember that both volunteers and employees have contributed their time to make available and /or modify the source code to the unique specifications of the IT environment. It is true that an organization could use open source software and support itself by hiring technical staff with the necessary skills to:
- Evaluate and select the most suitable open source software or software distribution;
Customize the source code to meet specific business requirements; - Integrate and embed the open source software into internal systems;
- Fix any critical defects that are found;
- Decide which patches and releases to migrate to and ensure migrations between versions are free from problems;
- Participate in the communities to ensure the direction that the software is taking suits the organization; and
- Train any users or new technical staff.
However, the above points are not ‘free’. Organizations have the freedom to do all these things but they should not consider fulfilling these needs to be of zero cost. If you accept that open source software is not a zero cost solution you must then accept that these costs can occur in the form of time (internal man hours), money (given to some external organization) or both.
That being said the benefits of open source outweigh the drawbacks. Open source network management software provides a stable and in many cases strong alternative to traditional network management systems. Commercial products typically favor visible features over harder to measure qualities such as stability, security and similar less glamorous attributes. For many open source developers, peer review and acclaim is important, so it's likely that they will prefer to build software that is admired by the volunteer community. Highly prized factors in open source projects are clean design, reliability and maintainability, with adherence to standards and shared community values preeminent, but not necessarily new features. For this reason, the most successful open source projects typically lag commercial vendors in releasing new features to support new and expanding business requirements.
Mostly though, if you have implemented an open source product from a sizable volunteer project that has staying power, you’re sure to be in good hands. In fact, open source is here to stay for the following reasons:
- The worst effects of vendors pushing premature features to market can be mitigated. The way that open source products tend to conform closely to standards efforts has an inertial effect since standards change but slowly and interchange formats are often particularly stable. As a result, incompatible file formats and upgrade migrations can be less of an issue. If the project is standards-based then it typically isn’t an issue at all, and if there are formats unique to the software product — proprietary formats in a sense - then they cannot be undocumented since the source code that uses them is itself published. In practice the track record of open source projects is usually good; when incompatible formats are used it is commonplace for a Perl or similar converter program to be shipped with them which will upgrade data to the new format.
- The open source process is inherently social. Group leaders spend as much time on ‘project matter’ and conflict resolution as on technical issues. This result is a very strong peer review process, something that many commercial applications lose in favor of time to market and business expense considerations.
- Freedom from a single vendor: Commercial vendors can arbitrarily decide to modify their roadmap, development schedule, pricing, and licensing agreements. Open-source software allows you to retain not just the right to use the software you already have, but the ability to continue to modify it as your needs change.
- Scale at your convenience. There’s nothing more annoying than a sales person trying to sling their product into your IT environment. Actually, there’s one thing more annoying. That same sales person calling you every day for weeks or months to get their ‘evaluation’ unit into your environment.
- Freedom to modify your software: You aren't limited to what one company believes you need. Proprietary software vendors cater to many customers (most times the lowest common denominator), and to themselves. Open-source software can be tailored for the way you do business if you have the financial resources to hire the required skillset.
- The number of features, drivers, and other hardware support tends to grow with time. As the number of users increases, so does the number of developers. Because of this successful open source projects tend to have a strong quality component, often including alternative implementations.
Of course there are other benefits to open source such as the ability to evaluate the product based on its source code instead of set of an instructions distributed by a vendor. From PacketTrap’s perspective, if you’re using a successful open source project’s solution, or you have the budget and skills to constantly monitor, enhance, and implement open source software, then you should not change. What you should demand from your traditional software vendors is that their products work closely with and/or integrate open source products into their solutions.
How We Integrate Open Source
Projects such as Nagios (previously NetSaint), OpenNMS, and others provide a substantial amount of functionality out of the box. If these systems are working, why upgrade or fix them? The wiser move is to ensure that traditional software vendors play nicely with their open source counterparts and that they provide either a simple integration module and API set, or a software development kit (SDK) to pipe in the functionality of the open source solution.
Therefore, if you have already implemented the open source network management products mentioned above or others, including Cacti and MRTG or one of a dozen or so others, it’s first important to determine whether the people investment can be activated. That is, is the IT department getting the full benefit of the system? If the system is working just fine and it’s solving a real pain and the ROI is there (include people time in the calculation), then there is no real reason to upgrade or migrate to a commercial vendor’s solution.
The best network management systems, whether commercial or open source, are flexible and extensible, and easily integrate with already installed and working software. There’s nothing worse than a company being told that a system they’ve recently implemented needs to be replaced with a better mousetrap. A better approach is to implement a solution that compliments the current installation in features, functionality, and most importantly, ROI. PacketTrap’s pt360 Tool Suite was built to do just that. For example, an IT department can integrate MRTG into PacketTrap pt360 Tool Suite dashboard, which includes a host of essential diagnostic tools that compliment MRGT (see figure below).
Figure 1: PacketTrap’s free pt360 Tool Suite. Pipe in MRTG (or any other open source browser based solution) and monitor your network alongside diagnostics tools such as a TFTP Server, and Ping, SNMP, and WMI scans all in one interface.
The point of the dashboard is to provide an interface to browser-based solutions where the end user can finally have the option of using solely commercial, solely open source, or combining the two (the majority of IT departments are in this category) via PacketTrap’s pt360 tool suite.
Our Commitment to Open Source
Commercial Vendors including Microsoft have talked about cooperation with open source projects for years but the reality is that profit motive and Wall Street always rules. However, this doesn’t have to be the case. The network management market is large enough to support growth for commercial outfits like PacketTrap, as well as open source solutions. So how can a commercial vendor integrate open source products without exploiting volunteer developers?
First, as position statement, there are benefits to working with a commercial vendor. Whereas open source software is often developed in a distributed environment, commercial software development is usually under centralized control within a company. This makes it easier to develop a roadmap for the product, control the architecture in a design phase, and possibly maintain an achievable schedule. Commercial groups experience greater pressure to provide features requested by their customers and to set their priorities accordingly. Because commercial developers control staffing instead of relying on volunteers, they can match projects and schedules to the available staff. This makes it easier to handle large or pervasive changes. More central control also provides some level of accountability to the customers for the design, quality, and usability of the software, as well as legal accountability for the intellectual property rights to the software. To say it simply, open source projects tend to focus on quality first, while commercial vendors tend to focus on market requirements first (i.e. new features).
For this reason, the fusion of open source and commercial applications in an IT environment is potentially perfect harmony. PacketTrap believes that both commercial and open source solutions living and breathing in the same space only benefit the IT department of end users. In essence, combining commercial and open source applications results in a best-of-breed network management system. PacketTrap is unique because it is committed to simple and easy integration of open source solutions into its products. In contrast, many commercial or traditional software vendors make it difficult, if not impossible. This is a foundation of PacketTrap’s business.
The Commercialization of Open Source
Recently, companies rushed to make a business out of open source software. The model is rather simple: fund communities of developer volunteers who exchange ideas and code, then bundle on and sell advanced features and support. Over the last three years, more than $200 MM has been invested in these hybrid POSS companies. Examples include:
| ActiveGrid (LAMP Stack): $10M | Logicalware (Email Management): $.5M |
| Alfresco (Content Management): $2M | OpenLogic (Stack Certification): $4M |
| BitTorrent (P2P Network): $8.75M | Pentaho (Business Intelligence): $5M |
| Black Duck (Compliance Management): $12M | rPath (Linux Software Management): $6.4M |
| Centeris (Linux Systems Management): $5M | Simula Labs (Open Source “Incubator”): $10-15M |
| EnterpriseDB (Database): $7M | SpikeSource (Stack Certification): $12M |
| Flock (Web Browser): $2M | SugarCRM (Customer Relationship Management): $18.77M |
| Funambol (Mobile Synchronization): $5M | Ubuntu (Linux Distribution): $10M |
| GroundWork (IT Management): $8.5M | Univa (Grid Infrastructure): $8M |
| Hyperic (IT Management): $11M | Zimbra (Email Management): $16M |
| Laszlo (Rich Internet Applications): $6.25M |
Making a business of open source software can be difficult. Sure, there have been tremendous successes including RedHat Linux. But, for the most part, these initiatives have mostly failed. Why?
- They are dependent on the open source community to release products that they layer many services on top of, yet the open source volunteers are motivated by quality, not quantity.
- Because their product schedule is dependent on a community that is not focused on and motivated by delivery dates.
- It is extremely difficult to coordinate volunteer development assets. As such, there are periods of feast or famine that affect sales, marketing and development.
The agenda of commercial companies is almost diametrically opposed to the spirit and motivation of open source communities. Commercial POSS companies such as Zenoss, Hyperic and GroundWork Open and others mentioned above, are guided by shareholder return. First and foremost, they need to make a buck – and most times they need to make a buck quickly. Commercial companies are either public and therefore strive to meet revenue guidance provided to Wall Street on a quarterly basis or are private and financed by a venture capitalist who needs liquidity within five to seven years. This means that market requirements are quickly pushed from the sales and marketing function to product management to engineering, who in turn is constantly under the gun to produce new features. Almost always, these features are based on a roadmap with commercial ($$$$) impact.
This is in contrast to the agenda of open source communities, which focuses on quality and peer review. There are no commercial pressures. Developers tend to focus on quality, stability, and accolades from peers. Also, the sheer inefficiency of loosely connected groups of volunteer developers makes focus on deadlines, product release schedules, and new features less manageable.
Proprietary Open Source Software companies believe they can live and thrive between these two agendas. This, in PacketTrap’s opinion, is tough. It’s one thing for an open source project to commercialize itself after years of work such as MySQL. It’s another thing to start fresh, and build a commercial enterprise based on the work of volunteer community that hasn’t been developed yet. As mentioned before one reason this doesn’t work is competing agendas. The other reason it doesn’t work is the model itself (see figure below):
Figure 2: Commercializing Open Source Projects
First and foremost, a new POSS company must build a vibrant and active community of volunteer developers. This worked for RedHat and the recent commercialization for MySQL, but in the reverse. That is, the community was already out there. Linux development was around for years before the good people at Red Hat built a business. Therefore, they leveraged an existing community and, more importantly, a movement. The movement was driven by the the insatiable appetite in the software and IT community for solutions without the name Microsoft on them. The market and the community of developers not tied to Microsoft wanted lower cost alternatives to the Microsoft Windows operating systems monopoly (Same holds true of MySQL versus Microsoft SQL Server and Oracle). Second, Linux is a wide impacting solution that crosses almost every facet of computing – from servers in large data centers to PCs to handhelds to cell phones. All systems need an OS, and to pay Redmond for every unit sold is excruciating. Linux affects everything and is, to use and industry term, disruptive. In order to build a community from scratch, there needs to be a surfacing demand within the volunteer community to develop a specific solution. As of this writing, with the exception of Redhat’s Linux, and a few database applications such as MySQL, the commercialization of open source has been riddled by this challenge. The community has not surfaced in revolt.
Assuming a community can be developed (as opposed to a community developing on its own through a movement against some threatening evil or requirement not being addressed), the POSS vendor will still be challenge by the Community Lag Effect (CLE). The CLE is the amount of resources in the form of dollars, people, and time it takes to built, foster, educate, and sometimes placate the community. Coupling the resource commitment with the fact that the community is a living breathing group of likeminded unmanageable volunteers who are motivated by peer review and not commercial interest, there will consistently and commonly be scheduling, feature, and labor allocation challenges. That is, can an engineering function within a commercial business realistically rely on a community with a different set of interests than its own? Can it control product schedule, roadmaps, and the ongoing requirements of their sales, marketing, and product management organizations? A commercial company leveraging an open source community will always be, to some degree, dependant on that community. That dependence causes a lag effect on the commercial enterprise that undoubtedly creates havoc at random intervals on the company’s ability to make money consistently. For this reason, the viability of the POSS business over time is sketchy at best.
The POSS hybrid approach from companies such as Zenoss, Hyperic, and Groundwork are challenged by constituents pulling in opposite directions. The better approach is to work with traditional commercial software companies that have their own product roadmap as determined by market demand, but that provide an extensible open source SDK or interface to open source projects.
Conclusion
It’s imperative to the future of the software industry that open source projects succeed and flourish because it provides a high quality and sometimes more flexible solution to traditional approaches. PacketTrap is one of the first commercial vendors to develop a solution that integrates open source products, and will push the commercial industry to release software development kits (SDKs) and APIs that ensure volunteer developers can integrate seamlessly with its solutions. This is best for the volunteer community, PacketTrap, and, most of all, end user IT departments. Today, PacketTrap’s products provide capability to integrate browser-based open source solutions into its pt360 dashboard interface. Tomorrow we will release interface components to the open source community. Each new feature, functionality point, and product to be released by PacketTrap will be developed with an eye towards open source integration.
Continue reading other LoveMyTool posts on PacketTrap Networks »
Recent Comments