Licensing: "Free" != Better

Open source projects are great. Many provide elegant, refined code for free. They can save hours of development time and hassle. They’re often a jumping-off point for up-and-coming developers to share their innovation with the rest of the community, inspiring others to write better code. Of course there are also plenty of open source projects that are riddled with bugs, poorly documented, and downright dangerous to use. The web is littered with abandoned projects that once seemed promising. It’s like a clearance bin you’d find at a discount store – there may be some treasures in there, but you’ll have to dig through a lot of garbage to find them.

Over the years, I’ve seen quite a few open source tweening engines pop onto the scene, get some buzz, and then gradually stagnate and fade off the scene. Many stay in Beta for ages. Some contain known, unpatched bugs. The community usually does a good job of eventually recognizing quality solutions and gravitating towards them, but there are always people who try out the “latest and greatest” thing, only to be disappointed in the end as it stagnates or fails to mature. Don’t get me wrong – I’m NOT saying all other tweening projects have suffered this fate or are “bad” in some way. In fact, I have spoken directly with some of the authors like Grant Skinner (GTween), Zeh Fernando (Tweener), and Moses Gunesh (Fuse, GoASAP). I have the utmost respect for each of them, and this article isn’t meant to diminish anyone’s hard work or generosity in the least. From my perspective, however, there are some common frailties of open source projects in general that I have observed, and my goal has simply been to figure out a way to protect the GreenSock Tweening Platform from falling victim to them. I have learned that one of the key factors in keeping a project like TweenLite thriving is actually the licensing model.

The funny thing is that in all the feedback I get about the GreenSock platform, I don’t get many complaints about functionality, performance, bugs, documentation, or ease of use – the most common complaint (which really isn’t very common at all) has to do with the licensing model. The complainers love the frequency with which the platform is updated and enhanced, they appreciate the prompt support, they may even recognize the thousands of hours that have gone into building, refining, and supporting it, but they object to the very thing that makes all that possible – the licensing model. More specifically, they don’t like the fact that a very particular, uncommon (less than 1%) type of commercial use would require the special license that comes with a corporate Club GreenSock membership. They don’t seem to realize that Club GreenSock provides a vital funding mechanism for ongoing innovation, optimization, and support. Without it, the project simply couldn’t be where it is today.

An MIT (or similar) license is perfectly adequate for projects that don’t need much updating or support. But a tweening platform has a lot of moving parts and is absolutely essential for most modern Flash applications and web sites, so frequent updates and enhancements can be crucial. The platform must be tightly optimized, full-featured, and flexible without becoming too bloated. Documentation and examples become increasingly important as the feature set expands and companies standardize on it, needing to train new employees, etc. This takes time and energy, so the author’s active involvement will directly impact its robustness, reliability, and staying power.

An MIT license is also great for authors whose goal is to start something, then step back and let the community run with it in any direction they want, altering the code and redistributing it. But that hasn’t been my goal. In fact, I think it can lead to a lot of confusion as different flavors start popping up all over with incongruent feature sets and incompatibilities. Focus and direction are easily lost. If there’s no driver (or too many drivers), it can be a scary ride for the passengers. I wanted to protect end users from these dangers, so while the GreenSock license does allow for tweaking of the code in order to make it function as originally intended (bug fixes), it doesn’t allow for Frankenstein-like alterations that are likely to cause problems. Again, I’m not saying an MIT (or similar) license is bad or wrong – it just didn’t align with what I thought would serve the community best on this particular project.

My goal with the GreenSock licensing model has been to create a solution that makes the platform extremely accessible, completely free for 99%+ of the use cases out there including the vast majority of commercial uses, while the “power users” (less than 1% of the users) who are directly profiting by a specific type of reselling of a product that uses GreenSock code end up providing a revenue stream that drives continued innovation, support, and optimization which benefits all users. I firmly believe that it ultimately delivers a better end product for everyone. I would argue that this licensing model is a feature of the platform, not a liability, and that it should give end users more confidence, not less. In fact, many companies have chosen the GreenSock Tweening Platform because of the license, not in spite of it. They wanted to invest in a platform that had a certain level of commitment behind it, not merely an “I’ll get to it when I get to it” attitude.

My Dad always taught me that successful people don’t base their decisions on “how much does it cost?” but rather “how much does it pay?” He helped me see how silly it was to become hyperfocused on price. I started noticing lots of hidden costs in going “cheap” on certain things. There are always trade-offs. The same concept applies to 3rd party code. “Free” != Better. In fact, there can be some significant costs associated with “free” code that shockingly few developers recognize. When you look at the facts, I think you’ll see that it makes a lot of business sense to invest in the platform.

After pondering it, I realized that using an MIT (or similar) license for the tweening platform would force my user base to pay some hidden costs that I found unacceptable. Specifically, they wouldn’t get the enhancements, code refinement, or support that I felt would be necessary to serve them well. Sure, on paper the MIT license sounded desirable for end users, but when I took a step back and looked at the bigger picture, I saw why using a slightly different model would make a lot more sense for everyone involved.

Also, don’t let the licensing issues scare you into adopting either of two extreme views:

1. Some developers absolutely refuse to use 3rd party code. When it comes to a tweening engine, they either stick with the Adobe Tween class which performs horribly by comparison and is anemic in terms of its feature set, requiring tons of extra code, or they resolve to write their own engine because they’re scared of the risks involved with using a 3rd party engine and they believe their own code will be superior, not recognizing the likelihood that the 3rd party already solved a bunch of nasty challenges that await them as they embark on their “reinventing the wheel” endeavor. These developers end up wasting considerable time and missing out on a tool that could revolutionize their workflow, drastically improve efficiency, and raise the quality of their end product. If they build their own, they also must train other members of the team to use it and then worry about the maintenance, documentation, and optimization. Stubborn refusal to take advantage of refined 3rd party code can be costly indeed.
2. Some developers turn up their nose at the thought of paying anything for 3rd party code especially when they believe they could find something similar for free out on the web. “free == better, open source rules!” is their mantra. But they fail to recognize the potential hidden costs of using “free” code that has no funding mechanism. It could be poor support, slow bug fixes, lack of continued innovation, poor performance, sub-par feature set, bad documentation, etc. These developers tend to be penny wise and pound foolish, making silly sacrifices just to save a buck in the short term.

In summary, don’t buy into the idea that cheaper is always better or that an MIT license is necessarily superior or safer. Consider the hidden costs and risks associated with any licensing model. Maybe you don’t see the value in the GreenSock model and that’s okay; there are plenty of open source engines to choose from. But my goal with this post was to respectfully challenge some of the paradigms out there regarding licensing and explain the factors that informed my decision to use a rather unique model.

Comments (21)

Subscribe