Recently, there’s been some discussion on Slashdot regarding MySQL in the past few months, after MySQL (the company) was bought out by Sun Microsystems.  MySQL (the company) has announced that they will be developing some proprietary add-ons to the backup capabilities of MySQL (the database) which will only be available to MySQL’s (the company’s) customers of MySQL (the database) enterprise edition, and not to MySQL (the database) community edition. 

This has been blown a bit out of proportion.  (The headline, on Slashdot, “Sun may begin close-sourcing MySQL” was misleading at best).  We e-mailed Steve Curry at MySQL (the company) and he pointed us to some information clearing up the situation.

· Anything that has been released as open-source under GPL continues to be released as open-source under GPL. Sun and MySQL (the company) are not going to start “closing” the open-source MySQL (the database,) and it seems unlikely that they will be able to legally do so even if they wished to.

· Improved backup capabilities are being planned in MySQL (the database) 6.0 for both the open-source community and open-source with proprietary add-ons enterprise version. 

· Proprietary add-ons are being added to the Enterprise version of MySQL (the database).  These add-ons are not core critical, they are essentially added-value for paying customers, which add compression, encryption, specific native drivers – things that a particular business might need but which aren’t critical to the core functioning of MySQL (the database.) 

· The decision to do so was done before MySQL (the company) was acquired by Sun Microsystems. If anything, Sun has been very open-source friendly, with Star Office forming the basis of OpenOffice.org, and Solaris and Java both open-source now.

· There is nothing preventing people from forking the MySQL (the database) source code and producing open-source versions of the proprietary capabilities.

The use of proprietary add-ons to an open-source system isn’t even all that rare.  Click N’ Run for Linux systems adds proprietary software to the open-source Linux; MacOSX is based on the BSD-licensed Darwin, a BSD-like distribution.

We also note the irony of a number of proprietary Web applications running off of LAMP stacks, where the L, the A, the M (the DB) and the P are all “free software.” 

There are a number of proprietary Web applications running with MySQL (the database) – and a move to “close source” MySQL (the database) would have messed with the business models of many companies – including NetQoS.  NetQoS uses MySQL (the database) Enterprise edition in our network monitoring and reporting products and we’re customers of MySQL (the company).  So we’re glad this whole thing is a tempest in a teapot. 

I tried to think of a prominent case where someone successfully “closed the source” of a flagship product after it was open-sourced - but couldn't until I went much, much farther afield.  There is a company “closing the source” on its major flagship product.

That company is Wizards of the Coast, a subsidiary of Hasbro.  And the flagship product is “Dungeons and Dragons.” 

Wizards (the company) makes Dungeons and Dragons, a role-playing, computer-less tabletop game where you play knights, elves, and powerful wizards (the characters) – a game that has a history of being very attractive to the technology-oriented crowd because of our love of math and power fantasies.

What makes Dungeons and Dragons particularly interesting is that a while back, Wizards (the company) released an “Open Gaming License” (OGL) which allowed third parties to develop additional content for Dunegons and Dragons, and, in fact, create entirely new games in different settings and genres using the rules established in Dungeons and Dragons 3^rd edition.  If you were a third-party company, you could publish supplements to provide traps, monsters, or new spells for wizards (the characters) to cast.  And many did.

This had numerous benefits all around; players needed to learn how to use only one system, and they had tons of D&D supplements to choose from, game companies found they had an audience in D&D players that they might not have otherwise had, Wizards (the company) found a sea of “developers” for their system which made ownership of D&D’s “core books” more valuable, and while it may not have resulted in a rebirth of the roleplaying game industry, it sure propped it up for a little while longer.

Because game players only had to learn one set of rules to play, the roleplaying game industry standardized quite a bit and the system used in Dungeons or Dragons (known as “d20”) became quite widely used, dominating the RPG field for a time. 

D&D “version 4.0” will soon be released, and many game beta testers believe the system has been radically overhauled and improved.  However, this new system will not be released under the OGL.  It will however, be released under the “Dungeons and Dragons 4^th Edition Game System License” (GSL). 

The GSL license has not yet been made public, but there are rumors, speculations, and concerns, fueled by online posts made by the brand manager and licensing manager for Dungeons and Dragons, and relayed by the lead writer of third-party publisher Necromancer Games that the GSL will contain a “poison pill” clause – that is, in order to use the GSL, a game company must not publish anything under the OGL.  

This would be like Microsoft saying that developers for Windows Vista are forbidden from publishing anything under the GNU public license.  And the upshot is now that developers have to choose between not developing games with the improved system or destroying their back-catalogs. 

Even if you don’t have a huge interest in D&D – in which case, I envy your normal social adjustment and relatively less awkward adolescence – it pays to keep up with this developing situation to see how a fight to close an open-source software product might actually go down.  Will Hasbro fail in its efforts to dominate the RPG industry, either shrinking their portion of market share or shrinking the size of the entire market?  Or will Hasbro succeed with this business plan, and the publishers of Monopoly (the game) end up with a de facto monopoly (the economic term) on this niche industry?

Update: On May 2, 2008, a week after this article's publication, Wizards of the Coast released an FAQ about the 4th edition licensing terms. The FAQ states:

Q. Can companies still produce 3.x products under the OGL?
A. Yes, but we anticipate that interest in the 4e GSLs will be greater.

Q. Can publishers release new products under both the OGL and 4E GSL?
A. No. Each new product will be either OGL or 4E GSL. If a new product is published under the 4e GSL, it cannot also be published as 3.x product under the OGL; and vice versa.

Q. I have multiple product lines. If I update one product line to 4th Edition, do they all have to be updated?
A. No. Publishers are able to choose on a product line by product line basis which license will work best.

Q. Will there be a different license for other lines, such as d20 Modern?
A. The d20 GSL will allow for other genres of roleplaying games.

Q. Why are there two different licenses?
A. The D&D 4e GSL is specific to the Dungeons & Dragons brand. The d20 GSL allows for non-fantasy genres. Both licenses tie to the 4th edition rule set.

Q. Do I have to give up my right to publish 3.5 OGL products in order to publish 4e compatible products?
A. No. Publishers are free to print product lines under either the OGL or 4E GSL. We would love to see our industry colleagues convert their entire product offerings to 4E, as we are doing, but we do not expect or require entire companies to convert to the new edition.

Q. Can publishers update their previous publications from older editions to the D&D 4th Edition rules?
A. Yes. Publishers participating in the Dungeons & Dragons 4th Edition GSL will be allowed, and encouraged, to convert their publications from earlier editions to the 4th Edition rules.

In a few minutes, Jim Metzler of Ashton, Metzler, and Associates, will be delivering his keynote on the Next Generation NOC at NetQoS Symposium 2008 at Barton Creek Resort in Austin. Last week, we pre-recorded a podcast with Dr. Metzler regarding the speech he is about to give and what he means by a "next generation NOC."

He talks about the changing role of the NOC and moves in enterprises towards integrating what were once seperate stovepipe functions to focus on application delivery.

The podcast is below.

Today, in this podcast, we speak to Dr. Jim Metzler at Ashton, Metzler, and Associates regarding his handbook, "The Handbook of Application Delivery 2008" and his upcoming keynote speech a NetQoS Symposium 2008.

Kevin Davis, a senior consultant at NetQoS, will be presenting a few training sessions at Symposium about SuperAgent, the end-to-end response time module of the NetQoS Performance Center. This will include a training session about how to use time-based network metrics in troubleshooting.  He talks about his upcoming training session below.

In the session, I’m going to be covering the importance of using a time-based metric in troubleshooting, because end-users complain foremost about time.  For example, they’ll say “the application is running slow,” or they believe “the network is slow.”  To users, everything is based on time, that’s what they’re complaining about.  And they’re correct.

It’s very new to many people to think of performance in “time” although that may seem counterintuitive - because most people are used to reading utilization graphs.  With utilization graphs, however, we don’t know if 70 or 80 or 90 percent utilization is necessarily impacting the user experience.  I mean, we buy networking equipment, routers, switches, firewalls, servers, and we want them to be highly – or efficiently - utilized.  Seeing high utilization could indicate a problem – or it could just indicate that you haven’t over-purchased.  So you can have a link at 90% utilization or a router at ninety percent CPU utilization but you won’t know if that’s impacting the end-user without a time based metric.

It’s time-based data that tells you how the users are being impacted.  Sure, the utilization data – the interface utilization, memory utilization, I/O utilization, can often tell what is doing the impact.  But the time base shows you the degree of the impact – the real-world effect on end-users.  With a time-based instrument, such as NetQoS SuperAgent, you can find out where the delay increase is occurring, and whether it’s based in the network, server, or application. 

In fact, you can take a look at time-based data and make a determination very quickly as to which entity is creating the performance issue – the beautiful thing about SuperAgent, in particular, is that it trends by time 24/7, so not only can you determine how your important business applications are being impacted today, but you can go back and look at recurring patterns in performance issues.  You can see if today is worse than yesterday or last week or last month.

In the session, I’ll also be going over how to architect the data center for performance.  Placement of servers that participate in inter-architectures is critical for the health and performance of the application and indeed the data center.  We also talk about how different protocols, for example, Microsoft’s TCP/IP stack, can impact application performance by enhancing or degrading it. 

It’s important for servers that are serving the same application.  For example, a front-end Web server and a back-end Oracle database really should be on the same switch on the same VLAN.  That way they receive optimum service from the network.  If they do leave the switch, they’ll have to contend with bandwidth going up and down the switch links, and they’ll be switched and routed multiple times. 

Based on measurements from customer environments and from our own laboratories, when two servers are on different switches they can have up to 18 milliseconds delay between them.  If we think of that in the terms of network engineers of one millisecond per 100 miles, what in effect we’re doing when we put two different servers on different switches, or two different VLANs on the same switch, we’re making it look like those servers are 1800 miles apart – like one server is in Los Angeles and the other is in Memphis. 

Gerald Combs is the original author and lead developer of the open-source, multi-platform, Wireshark network protocol analyzer. Combs works for CACE Technologies – a company which makes products that compliment Wireshark.  Today he mostly takes care of the administrative parts of the project but still does development as well, and he controls the version numbers and release schedule.

After ten years of development, Wireshark finally reached the milestone of a 1.0 release.  We speak to Mr. Combs in an interview below: 

NPD: So what is Wireshark?

Combs: Wireshark is a network protocol analyzer.  It’s kind of a traditional analyzer in that it’s a GUI that has three panes, the top pane shows a list of the packets captured off the wire, the middle pane a detail of whatever packet you have selected, and the bottom page shows the actual hex output – the bytes in the actual output.

NPD: Why did you decided to build Wireshark?

Combs: Years ago, I worked at a small ISP in the Midwest, and unfortunately, they couldn’t get me a Sniffer, which was the standard analyzer at the time, and of the products out there that were available, none of them ran on the platforms we used at the ISP – namely Solaris and Linux.  So I decided to sit down one day and start writing my own analyzer. 

I did the first release in July of 1998, and soon after started getting a steady stream of contributions from a bunch of really smart people.  After that, we built up a pretty good following of users.  And right now, Wireshark is the world’s most popular network protocol analyzer. 

NPD: Why did you decide to open-source the project?

Combs: I’d used open source software for a long time at that point.  Before then, I worked at a university and we made a lot of use of open source software.  It just made sense to me.  I wanted to give back to the community and it just seemed like a good way to go.  As it turned out, it was a great way to go, because Wireshark is appealing for a lot of people who write code for it.

NPD: Why has it taken ten years to reach Version 1.0? 

Combs: I just wasn’t comfortable until recently putting out the 1.0 release.  I’ve known for years - shortly after we made the initial release, people started using it in production environments.  And some people had trepidation because it wasn’t 1.0 yet.  But for the most part, people just didn’t care about the version number and they used it wherever they wanted to and wherever they needed to. 

But for me there were a number of features that were crucial and missing until recently that prevented me from putting a 1.0 stamp on it.  Probably the last one, one of the main ones, was privileged operation on Linux – getting it so that you could capture as root but run the GUI as non-root user. 

NPD: Have people come up to you and told you about how Wireshark helped them out?

Combs: I get e-mails from time to time from people, saying that I’ve helped them out.  I have some former coworkers that have mentioned that.  It’s actually pretty encouraging. 

We get a huge amount of code each month.  Between each release, we have 200,000 and a million lines of changes.  That’s just changes.  The actual source code is about 1.5 million lines now.  That’s a bigger job than I can do individually.  And luckily there are a bunch of smart and talented people that can help me with that.

NPD: What was the greatest challenge in developing Wireshark?

Combs: The greatest challenge is just the day-to-day maintenance, keeping the project going.  But several years ago, we had an initial push of fixing security bugs a while back and it was a huge undertaking. I just remember spending several months doing nothing but fixing these security bugs, and it was a big chore.   We have a huge codebase now, and unfortunately we just don’t have the resources to audit that.  But we have a lot of automated processes in place like fuzzing and static analysis that help us find those bugs. 

I can’t say this enough: Thank you to all the Wireshark developers out there and the user team – this has just been a great journey and it’s one that I hope to continue. 

by Patrick Ancipink
Director of Product Marketing, NetQoS

There’s been a lot of growth (and attendant hype) in technology areas like WAN optimization and application acceleration over the past few years, and for good reason. Anything that helps companies speed up and reduce the risk of strategic IT initiatives like consolidating data centers, turning up new branches or serving an increasingly mobile and scattered user community will be popular.

To help with cope with the increasing reliance on the WAN and keep latency in check, there are a dizzying array of vendors and products out there – but if you’re trying to determine precisely which techniques and technologies to implement for your specific needs, the array of vendors quickly goes from “dizzying” to “disorienting” and finally “nauseating.” 

Cisco’s been in this Tilt-a-Whirl™ of a market for a while (and NetQoS has been right there with them) and they’ve taken some big steps recently to provide a more holistic approach that centers on building an “application aware” network, rather than trying to highlight one type of implementation against another for a narrow set of capabilities.

NetQoS started working exclusively with Cisco closely to help customers evaluate, measure, and prove the effectiveness of WAN optimization and application acceleration deployments. As customers are moving from pilot phases into full production, the before/after measurements and comprehensive monitoring are critical to ensure customers are getting the benefits they intended and doing what they need to deliver application performance. 

To help get the word out, Cisco just launched a new section of their web site today that contains a wealth of information about, as they call it, “WAN and Application Optimization.” The downloadable presentation, Cisco WAN and Application Optimization Technical Overview Presentation, puts Cisco technologies (and complimentary ones, NetQoS included) into a useful context with a methodical approach and framework built around four steps: Profile and Baseline, Optimize, Evolve, and Operate. A whole Campbell’s Factory of Cisco alphabet soup technologies are included—WAAS, ACE, NBAR, Netflow, CBQoS, IP SLA, PfR—to show how they work in concert and what role they play in the bigger picture.

There’s also the Cisco WAN and Application Optimization Solution Guide , a very in-depth publication—like 227 pages deep—that is targeted for “technical personnel involved in the specification, design, and implementation of specific WAN and application optimization solutions.” We, here at NetQoS, are proud to have contributed several sections to book regarding the methodology and implementation of network performance monitoring for WAN optimization and application acceleration. 

(If you are looking for some lighter fare, the video on the site tells a nice story in about 6 minutes including an airshow, snowmobiles, windsurfers, and skydiving—interesting choices for demonstrating the criticality of serving video over the WAN.  Then again, some company somewhere has to make the recreational products, I suppose.)

We've recently covered Bell Canada throttling P2P service. Today, in this podcast, we speak to Professor Michael Geist, Canada Research Chair in Internet and E-commerce Law at the University of Ottawa, regarding the controversial move by Bell Canada to use traffic shaping on wholesale service providers.

A transcript of this podcast will be provided at the earliest opportunity.

For open source projects, v1.0 is generally a major milestone; one that is usually well earned.  After all, in open-source software, changes between versions are incremental and it can be a long time before hitting the 1.0 milestone.  For example, Mozilla – the original, before Firefox eclipsed it and it became SeaMonkey - spent four years as “beta” versions before finally getting the 1.0 designation – and it is notable that most of those beta versions were quite usable, Like much open-source software, it kept improving but just didn’t meet the developers exacting standards for a 1.0 release until it passed a threshold.

This 1.0 barrier was just reached for WireShark, the open-source packet sniffer. 

Is it a milestone?  Perhaps it’s just the ticking of the odometer over into the 1.0 area – the changes from the previous pre-1.0 version were minor – a new experimental version on MacOSX Intel, and some security related vulnerabilities patched.  However, WireShark remains a invaluable tool for anyone working in the network space.  Bill Alderson uses Wireshark for monitoring application performance, TCP behavior, retransmission symptoms, and protocol incongruities in situations in collaboration with NetQoS’s products – or where NetQoS’s products would be considered overkill.

Wireshark v1.0 is especially important because of its free-as-in-beer-ness.  Wireshark opened up network and application troubleshooting to rank-and-file IT staff – as anyone could download and use it, rather than having to wait for the network engineer to show up on-site or waiting for a third party.  Anything that helps the IT group solve problems faster is a good idea. 

Right now, Joel Trammell, our CEO, is at Sharkfest 08 (the first Sharkfest) at Foothill College, where in addition to Gerald Combs, the original developer of Wireshark, Dr. Vinton Cerf will be delivering a keynote. 

Additionally, with April Fools Day coming up tomorrow, you have to appreciate any program that allows you to play harmless practical jokes – and details exactly how on the official wiki. 

by Brian Boyko
Editor, Network Performance Daily

Baseline magazine recently put out an article warning IT departments of under-30 "risk takers." Of course. Why not? Everyone knows that the youth are stuck up, and don't fit into corporate culture.

Being 29 years old a week from tomorrow, I was keenly interested (if giddily bemused) in what pejorative things they had to say about us brash young kids who are Ruining-It-For-Everybody™.

"Millenial workers are nearly twice as likely to use personal devices such as cell phones, PDAs and laptops in the workplace as their older counterparts."

Yes, from a security standpoint, an infected laptop or smartphone could provide trouble for the security of the network. But that also means the under-30s are more connected.

Let's look at this from a holistic standpoint. Yes, network security is important. But if personal computers and handhelds provide a more efficient way to get information, they enhance the power of the network. IT is about application delivery - and mobile devices might just be the most efficient way for Young Turks to get to the application. Yes, they can cause problems, but a NOC with automatic reporting can identify the problems quickly enough that the benefits of the always-connected employee outweigh the risks.

"Millenial workers are more than likely to use their work and personal computers for professional and personal use."

I admit that I do this. Sometimes, I need to use my personal Mac to edit video for work, or I need the computer at work to execute a Windows program. But again, this makes me more efficient. I often (after hours or on my lunch break, of course) use my work computer to send personal e-mail, and in fact, is one of the reasons I use Google Mail. Conversely, I log into Exchange to check, and send, work related e-mail from my personal computer at home if something needs my attention.

"Millenial workers believe they should have the right to use software of their choice on their work computers, regardless of its source."

NetQoS has a policy of allowing everyone to install whatever (legal) software they deem necessary to complete the work (as long as it doesn't affect other's network performance). As research for articles I write, I've got a variety of freeware programs, including GIMP, VirtualBox (virtualization software), various video editing programs and, the big one, Firefox, which I downloaded on day one. (I will never understand companies that make you use Internet Explorer in the name of "security")

I've worked at places where we were severely limited in the programs we could have. There's a reason I'm not working at those places anymore - the lack of trust in the ability for a person to choose their own software - their own tools - shows a lack of trust in the ability of the person. And it paints IT as productivity preventer rather than enabler.

This is not to suggest that there should be complete anarchy on the network. But when the IT department locks down everything, it creates more of a productivity hassle than any damage that a virus or hacker can do. There are unsecure apps out there, and the good judgment of the majority does not make up for the poor judgment of the minority. But with that said, why punish the majority for the transgressions of the minority.

It is not, after all, the downloading of malicious apps which affects the network - it is the traffic that those malicious apps produce. Instead of trying to control the application on the desktop (and relying on security on the user/desktop level is futility at best) it's better to control access to the network. You can put computers with out-of-date antivirus or unauthorized apps on an alternative network. You can use anomaly detection to find malicious traffic before it does damage. But there are a whole host of options between application anarchy and resorting to the draconian measures of a culture of complete control.

"While Millenial workers are more likely to visit unauthorized Web sites and install unauthorized applications, they are also more aware of security risks then their Gen X counterparts."

"Millenial workers are slightly more aware of what it takes to secure their apps and devices."

These could easily translate as: "Don't worry. We know what we're doing." And while those have been famous last words a number of times, in this case, I don't think it's ironic. But more importantly, security should never be left to the end-user. We've tried it countless times, it doesn't work. If you rely on defenses at the edge, your network is only as secure as your least security savvy employee.

This next one is very important:

"While all workers want access to technology and devices, each group reports little to no productivity gains as a result. Millenials, however, are more likely to perceive productivity gains from collaboration and Web-based apps." [Emphasis added]

When you think of Web based apps, you immediately consider the network. This is a generation raised on MySpace and Facebook, and Google Maps, and Google Mail, and Google Analytics, and Yahoo Answers, and Wikipedia - this is the generation of the Web based app. These are the tools that the upcoming generation is comfortable with. And the people who develop tools know this. This is why application performance - especially for Web based apps, is so crucial.

In the end, Baseline put out a separate article a few days later, pointing out that under-30s in IT had benefits as well as drawbacks. But why should we believe them? Everyone knows that you can't trust anyone over thirty.

The ultimate function of the IT department is to provide delivery of the business critical applications in a speedy and reliable manner to the users who need them. Virtualization doesn't change that. It merely changes everything else.

The funny thing about a virtual server is that it is the living embodiment of the idea that the silos in IT have to break down and once different technical fields now have to work together.

Virtual servers are part of virtual networks - that is, there are multiple virtual servers on one actual piece of hardware, and they connect to each other - on the same hardware - using the same networking protocols that they would use if it was communicating with a server halfway around the world. But it's all on the same server, so here's the question: Who fixes it when it breaks? Who owns it?

After all, there's no actual fiber/copper/tin-can-and-string wiring going on, it's all entirely on the server. So is it the server team that is responsible for "intra-box" networking connections? Or is the network team responsible? Gumming this all up - virtual servers are software. Does that mean the application team should be the one responsible?

With virtualization, you really can't have a segregated IT department and continue to operate efficiently. Traditional models of which part of the IT department "owns" which part of the "application path" from server to user are now irrelevant.

We've been talking about the idea that server, application development, and networking teams have to merge into an application delivery team for quite a while now - we invited Jim Metzler to speak at NetQoS Symposium 2007 to talk about it, and he'll be back for NetQoS Symposium 2008, (which starts a month from today, actually).

I think virtualization has thrown everyone who works in the enterprise space - from network engineers to CIOs to vendors like us here at NetQoS. Everyone knew it was going to be big; I don't think anyone realized how quickly it would catch on. March's issue of CIO Magazine reports that 85 percent of CIOs are happy with the return on investment of virtualization - even though it can be hard to quantify exactly what the return on investment is with current tools.