In our last Newsletter we announced the Powered! Program and briefly explained that it serves two purposes; it allows users of the platform to show their affiliation to DotNetNuke, and it allows us to actively manage the DotNetNuke trademark guidelines. It is the latter of these two items which I would like to provide some additional insight.
Since the DotNetNuke trademark and logo guidelines were published in June 2005, we have received a variety of useful feedback in terms of areas where the policies and processes did not fully meet the needs of the community. In May 2007 we decided to revisit the guidelines and address some of the common issues which had been raised.
The original trademark guidelines had a provision which allowed third parties to use the DotNetNuke trademarks within domain names, as long as they signed a "trademark license agreement". Well this agreement never evolved past a draft form, and as a result it left people wondering what they were supposed to do about their registered domain names. The Powered! program now provides the ability for people to register their domain names with us in a simple online form, and by accepting the terms and conditions of the program it provides the legal permission to use the DotNetNuke trademark in this scenario.
The original logo guidelines were fairly restrictive in terms of how people could use the DotNetNuke logo. Specifically, the restriction that the logo could not be separated from the name "DOTNETNUKE" imposed some serious design limitations on its usage. The reason why this restriction was included in the first place is because the DotNetNuke logo was not yet recognizable enough within the industry where a person seeing the logo would be able to make the association to the DotNetNuke project. After a couple years and broader industry adoption, we decided that this restriction could be removed and we have adjusted the logo guidelines accordingly.
One of the major complaints we had regarding the trademark policy was that the community members who ensured their sites were in full compliance actually felt like victims because they could point to other community sites where the trademarks were being violated for business advantage. Unfortunately, this is not a problem which is easily solved. After speaking with our IP attorney, we were informed that it is our duty to be active in terms of protecting the integrity of the trademark in all jurisdictions. For the most part this simply involves educating the community on the terms of the policy and sending reminders to those folks were are not in compliance. We have also added a Feedback form to the Powered! program page so that the community can notify us of potential issues.
Related to the trademark policy, there are sometimes questions which come up in regards to the software itself. Based on our open source BSD license, there is actually no legal issue with third parties adding their own proprietary code to the framework and releasing it as a new application. The only restriction is that the new application can not be named DotNetNuke, as this would be a direct violation of the trademark. The reason why we need to restrict this scenario is actually very simple. If there were multiple applications with different feature sets, maintained by different management teams, or even running on different platforms, which were all released under the same name - it would cause massive confusion in the community and potentially erode much of the value which has been created in the brand over time. The same way that Toyota would not want their name or logo to be associated with vehicles manufactured by other auto makers, we do not want DotNetNuke's name to be associated with software which is not provided by us.
So as I mentioned, it is legal for a third party to release the DotNetNuke application under a different name. In open source software terminology, this is known as a "fork". At first it may seem illogical that an application which already permits unlimited freedom through its open source license, would be diverged and released under another name. However in order to comprehend this phenomenon, you need to better understand the motivations of the various participants involved. For the most part forks occur for a couple primary reasons:
1. Members of the open source development team become frustrated with either the management team or technology choices made in the project, and feel that they would be better off on their own. Obviously one option for them is to create their own version of the application for their own private use and diverge from the original project. However there is often a great deal of bitterness in these cases, and the developer may feel that the best way for them to justify their position is to release a new version of the application which addresses their specific pain points.
2. A third party may see a business opportunity based on the size of the open source community and will decide that they wish to cash in. In these cases, the motivation is purely capitalistic and they are willing to ignore or sacrifice many of the community values in order for them to achieve their revenue goals. In this case, a third party provider will try to sell usage of the application under a commercial model for their own profit. We are actually aware of a few scenarios where this is happening today. The issue is that although the practice is perfectly legal, the moral and ethical implications of this approach are highly questionable. And if the customers of the commercial version find out that they are paying for use of software which they could otherwise get for free, it creates some serious backlash against the third party provider.
Forks cause incredible stress on an open source project. This is mainly because the management team and source code of the product represent the nucleus of the entire community including add-ons, support services, and knowledge base. The same way that nuclear fission causes an explosion of energy which is challenging to control, the splitting of an open source project can have equally disruptive effects if not properly mitigated. Other than the general confusion this can cause for all of the stakeholders in the ecosystem, there are some very specific business risks which you need to be aware of surrounding this scenario.
The most disruptive consequence of a fork is related to support channels. Since it is often not made clear that the new application is different than the original, users will try to leverage the original support channels for assistance with their problems - causing mass confusion. This confusion is not limited to the main product, but also manifests itself on the vendor sites who provide platform extensions. Sorting out the incompatibilities between versions can incur major costs from both a time/effort as well as financial perspective.
One of the emotional aspects of a fork is that it is extremely disrespectful to the developers which have spent an incredible amount of effort creating and supporting features in the software application. As much as developers know that they are contributing their intellectual property to the project under a license which exposes the risk of a fork, it leaves a really bad taste in their mouths when they find out that a third party has taken their code. This is especially true in scenarios where the third party is leveraging the code and ideas for a profit.
Yet another major problem is related to intellectual property governance. Basically in a "fork", one open source project encapsulates the IP assets of another open source project. The new application will generally have its own open source license which "wraps" the license of the original open source application. Obviously, the new license needs to at least be compatible with the old license but the bigger issue is that users of the new application need to place implicit trust in the owner of the new application to ensure that it fully adheres to the conditions in the original license. If the owner of the new application violates the original license in any way, it puts every user of the new application in serious legal risk. The risk being that the owners of the original license could decide to litigate every individual instance where there license has been violated. Although the legal costs of such a large scale initiative seem prohibitive, the now infamous SCO/Linux lawsuit is based on this exact scenario and is yet to be settled in an official court of law. For DotNetNuke we have been extremely diligent over the past four years to ensure that our users are adequately shielded from risk in this area. When it comes to IP governance, all external contributions are professionally managed using industry standard intellectual property legal contracts. And in any case where we leverage code which is independently licensed, we build interfaces so that the features can easily be removed in the event of an IP dispute.
Another important aspect to consider is long-term viability of the new open source project. In a fork, the owner of the new application has no proven track record. As a result, there is no trust relationship which you can use to justify a long term technology decision for your business. This is especially true in terms of upgrade support. What often happens in project forks is that the new project does not acquire enough critical mass for its owner to justify the ongoing support and maintenance. In this case, the project is abandoned and its users are left on an evolutionary dead-end.
As a result, the main question which you need to ask yourself before adopting any fork is, "What is the primary motivation of its management team in creating the fork ?" This is often very difficult to determine, as the marketing propaganda which is initially produced may end up quickly conflicting with the business goals which are revealed later. Since DotNetNuke now has four solid years history under its belt, the strategic goals and values of its founders are very clear and are further held accountable by the active community which has embraced it.
In terms of the business ecosystem, it is also important to consider the partners which play a key role in supporting the platform. If the project fork does not have the same strategic partnerships as the original project, your opportunities and support channels are going to be severely limited. For example, DotNetNuke has long enjoyed a solid working relationship with Microsoft Corporation. This relationship has allowed us to seamlessly transition from ASP.NET 1.1 to ASP.NET 2.0 - a platform upgrade which would have imposed a significant complication and cost to our user base, had we not been able to work directly with Microsoft engineers. Adopting a fork would certainly not have provided the same level of support for your business. Similarly, DotNetNuke has a direct relationship with a wide variety of Hosting Providers which support a massive distribution network for the application as well as its extensions.
An important aspect to recognize as well is that maintainers of the diverged project will often claim that it is not a fork. The justification for this claim is often because the initial version of the forked product is still technically compatible with the original project. But in the same way that you can not have two construction crews with different blueprints working on the same house, you can not have two different management teams with different goals working on the same software project. Once an open source projects source code is released under a different name, it is for all intents and purposes a different product ( a fork is a fork ).
I am a firm believer in the open source model where freedom plays a key role in any decision. However, I believe that any choice needs to be deliberate and too often I see people gravitate towards the "shiny new toy" without any consideration of the future business risks or consequences. It is critical that you fully consider the full set of criteria before settling on a technology platform.