ZipTie: New features, new name, new license?

Introduction

It has been over a year since I last posted about an exciting open source project called ZipTie. We use ZipTie to automatically discover our network devices, backup their configurations, and perform a variety of functions related to these devices. Many things have changed with ZipTie since my last post and I want to share those with you. I'll start with the positive changes first, because I am a positive type of person.

New Features

The most obvious improvement is the slick web interface that replaces the previous Java fat client. This interface is powered by Adobe Flex, so it has a great look and feel to it. Having a web interface also simplifies deploying ZipTie, because you don't have to worry about installing a Java application and all the required dependencies. Check out the screenshots:




ZipTie has also added a great community resource called ZipForge, which is a place where anyone can publish custom tools that perform specific functions on network devices. This forge makes it easy to create these tools, without forcing the contributor to learn a lot about ZipTie internal functions.

The new release also adds the ability to gather information about end nodes on a network. This means that I can find out which port a device is plugged into simply by entering the IP address (or MAC address) into ZipTie.

I am not going to list all the improvements in this post, but I will tell you that these developers have been hard at work making ZipTie into an incredibly useful tool.

New Name: NetworkAuthority Inventory

Alterpoint has funded the development of ZipTie from day one. A handful of full-time programmers have been working on ZipTie for over two years, funded completely by Alterpoint. The ZipTie open source community has been growing steadily as this application matured, but most community contributions were in the form of beta testing and ZipForge tools. In the last year, Alterpoint began using ZipTie as the core engine inside their proprietary applications. In case you can't make the connection, these products are the ones that make the money that is used to pay for the open source developers working on ZipTie.

I have often wondered why Alterpoint decided not to advertise their products alongside the ZipTie project. Indeed, their name and commercial branding was almost non-existent on the ZipTie website. The Alterpoint folks must have been thinking the same thing as me, because they have completely overhauled the ZipTie website and changed the name of the project. ZipTie will now be called NetworkAuthority Inventory. The new website has Alterpoint branding and provides information about their commercial offerings and what features you will get if you buy them.

I strongly feel that it is appropriate for Alterpoint to push their products, given the fact that they are paying for ZipTie to be developed. It is important for people to realize that Alterpoint needs to make money if they are going to continue spending resources on this project.

Regarding the new name, I personally don't like it because has five times more syllables than "ZipTie".

New License: No longer open source?

Here is a message from the lead developer of ZipTie regarding the license change:

ZipTie has, up until 10/28/2008, been licensed under the MPL. Now that ZipTie has moved into our NetworkAuthority brand of products, we wanted to put a GPL license on it. Unfortunately, our use of EPL software prohibited us from using the GPL. To get around this, AlterPoint is licensing NetworkAuthority Inventory under the Open Technology License (OTL). It basically reads like a GPL.

This is the area that I am most concerned about. Alterpoint has changed the licensing of this project from Mozilla Public License to a custom license created by Alterpoint. I am not a lawyer, but my conclusion is that this license severely limits the rights of users. Because of this, I do not think it can be considered an open source license. Alterpoint has taken an open source project and turned it into a closed freeware application.

Now, I think I understand the reasoning behind this decision. Alterpoint needs to find ways to make money if it wants to survive. Using ZipTie as the core of their product stack is a great way to benefit from open source development and introduce users to their commercial products. However, changing ZipTie into a proprietary application is not required to accomplish this!

The business model that accomplishes what Alterpoint is trying to do has recently been named "Open-Core Licensing". This model works by building core functionality as open source software, and then adding proprietary features on top of that core. As I will discuss in a future post, a successful open source business provides many benefits to the community and the project.

What can we do about this?

What can we do to encourage Alterpoint to continue using an open source license? There is always the possibility of forking the previous version of ZipTie that was released as MPL. However, forking a community should always be considered a last resort after all other options have failed. Even if ZipTie was forked, I don't know how successful it would be because 99% of the development is being done solely by Alterpoint employees. In theory, the threat of a fork is supposed to prevent software vendors from mistreating open source communities.

I think the best thing we can is do at this point is educate Alterpoint about the benefits of using an open source license for their core product. If the community really cares about this issue, perhaps Alterpoint will re-evaluate their licence.

I think we also need to address their concern with the GPL being incompatible with the EPL. I believe that the Alterpoint wants to use the GPL license because it offers the most protection from other businesses using ZipTie code inside their products without contributing their changes to the project.

Can anyone answer that question? Both Eclipse and Wikipedia state that the licenses are incompatible. However, Ed Burnette from ZDnet points out that EPL code is found within Red Hat Linux:

Take, for example, Red Hat Enterprise Linux. RHEL contains both free and non-free programs. It contains programs covered by GPL, EPL, Apache, BSD, and every other conceivable license. The last paragraph in section 5 says this is OK even though they’re conveyed as a single aggregate.

Is there another OSI license that would be a good fit for this project, and still be compatible with the EPL?

The evolution of open source software

Introduction

If you have followed this blog for a while, you will know about my passion for open source software. I have always predicted that open source software would revolutionize the software industry, but I didn't quite understand how this would happen. My initial views expected that open source would disrupt traditional software companies so much that it would eventually put them out of business. I am now realizing that the future of open source software looks much different than I first expected.

Proprietary software will be quietly built on open source software

One of the primary benefits of open source software is that it reduces the cost to produce software. Gartner agrees with this point; open source software is the most efficient method to create software. Traditional proprietary software vendors are realizing this fact, and are beginning to quietly build their closed software products using lots of open source software.

I say "quietly" because these companies are not going to announce that they are using open source software. In fact, they will prefer if this fact is not known by their customers. There will even be some software companies who choose to use open source in violation of its license, and it is important for us to detect and prosecute this exploitation. However, most companies will abide by the open source licenses.

Gartner has predicted this trend of building closed software with open source elements:

By 2012, 80 percent of all commercial software will include elements of open-source technology. Many open-source technologies are mature, stable and well supported. They provide significant opportunities for vendors and users to lower their total cost of ownership and increase returns on investment.

Ignoring this will put companies at a serious competitive disadvantage. Embedded open source strategies will become the minimal level of investment that most large software vendors will find necessary to maintain competitive advantages during the next five years.

Re-using code is not a completly new idea to software companies. These companies have developed internal libraries of software that they can use in multiple products without having to re-write the entire application from scratch. Open source simply expands on this concept. Rather than being limited to an internal software library, open source software provides an enormous global library of software that is worth $25 billion dollars!

Another way to look this is with the example of building a car. Open source software can provide the wheels, frame and engine of a car. This allows a proprietary software vendor to simply add the final touches that make the car unique to them. This development method greatly reduces the cost to build the car, because the software vendor does not have to "re-invent the wheel".

I see open source software being used all the time when I look at closed products on the market today. Let's look at the example of a DNS appliance. You can bet that over 90% of the code used to create the appliance is likely to be open source code. The operating system is Linux, the DNS server application is Bind, and a variety of subsystems are probably open source. The DNS appliance vendor adds their 10% of value and then sells it to you as it they created the entire thing! This is not necessarily a bad thing, I just want you to realize what is happening.

Open source software vendors will become more closed

There are many open source companies who have formed to meet the need of supporting open source software. These companies are experimenting with various business models that take advantage of the large user base of open source software. Most of these models started by simply offering support services, and the software project remained 100% open source. As the global economy goes through hard times, I believe that these types of business models are not sustainable.

What we are going to see are open source vendors who continue to contribute to a 100% open source project, but they will also add some special value that is only available to paying customers. This is already being done successfully by companies like Digium, the creators of Asterisk. Their Switchvox appliances are based on the open source Asterisk PBX, but it adds proprietary features that give customers a reason to buy the product.

Both Savio Rodrigues and Matt Asay have predicted this evolutionary trend of offering proprietary elements to an open source project. Savio Rodrigues has even gone as far as saying "that proprietary is going to be the savior of the OSS business model".

Before you get upset about proprietary software tarnishing open source, please look at the bigger picture. Open source vendors have paid for enormous amounts of new development to open source projects that would have taken many years of volunteer work. These resources were paid by venture capitalists who invested funds to develop open source businesses. If these business do not succeed, they will no longer be able to employ full-time programmers to work on open source projects. Hopefully you can see how this would have a negative impact on open source.

In my opinion, open source vendors and open source communities provide mutual benefit to each other. The community gets free development resources, while the open source vendor gets money from the subset of paying users. This relationship needs to thrive to realize the maximum benefit to both parties.

So, is this change good or bad?

My prediction is that proprietary vendors will use more open source, and open source vendors will become more closed. The line between these categories is going to become very blurred as they converge around a common middle-ground.

While this evolution of open source is not what I had predicted, I feel positive about these changes. If you are an open source advocate, you should be excited. In the future, not only will you have the same access to open source software that you do now, but successful companies will hire full-time programmers to daily improve upon that software.

If you are a proprietary software user, you should also be excited. This is because open source software will reduce the overall cost of developing software. In the long-run, competition will force these cost savings to be passed to the consumer.

What do you think?

Do you agree with my predictions? Do you agree that this is a positive change? Either way, please let me know with a comment below.