a little madness

For many years, step 2 has eluded the slashdot community:

1: Start your project.
2: …
3. Profit!

Now, however, Ext, the company behind the popular ExtJS Javascript library, seem to believe they have pinned down this step. In the latest 2.1 release, Ext has switched from a dual LGPL/commercial license model to a dual GPL/commercial license model. Despite claims from the company that this was done due to community concerns about ExtJS not being fully open-source, the majority have seen what this really is:

1: Start your project under a LGPL/commercial license model.
2: Switch to a GPL/commercial license model.
3: Profit!

The model works because step 1 allows you to build a community around the more liberal LGPL license. In particular, as the LGPL is commercial-friendly, the community will include many people building commercial applications. Once the community is suckered in and committed, the license is changed, leaving them high and dry. Well, not quite: they can continue to use new versions of the library by buying a commercial license. Hence the profit!

Not surprisingly, this sudden license switch has caused a large community backlash. People don’t like to feel that they have been baited in this way. The defense from Ext runs along a couple of lines:

1. They are just applying the “Quid-Pro-Quo” principle: i.e. if you get something out of Ext, you should give back. This is fine: Ext have created a great library and have every right to charge for it if they wish. But it isn’t the use of a commercial model that is wrong here: it is the sudden switching of models. Ext have massively benefitted themselves from liberal licenses, both in terms of the libraries Ext was originally built around (e.g. YUI which is BSD licensed) and the community that appeared around Ext itself, submitting bug reports, patches and extensions. What are they now giving back to these communities they have used?
2. The previous licensing was confusing and criticised for not being “open” enough. Simplifying the licensing scheme is fine, but there was no need to change to the GPL to do this. In fact, switching to the GPL has caused more problems for open source projects built around Ext than it has solved. Because of the viral nature of the GPL, those projects must now reconsider their own licenses to be able to upgrade to the latest version of ExtJS. The Ext team surely realise this, so trying to give this reason for the license switch is misleading on their part.

The backlash has been all the greater because of how the switch has been handled:

1. The community was given no warning or consultation, despite this change being ostensibly for their benefit.
2. Ext were not forthright with the real motive for the change.
3. Ext are claiming that a fork of the existing 2.0 version is not legal, due to the way they applied the LGPL. This is likely to be incorrect, and if correct then their use of the name LGPL was grossly misleading.
4. There is still confusion around the licensing. For example, the commercial license does not clearly spell out what happens when upgrading. Debates continue around the applicability of the GPL to hosted applications and those that generate code. Ext have been far from responsive on these matters.
5. This is not the first major license change for ExtJS, leaving many anticipating similar upheaval in the future.

The saddest part about this is that the Ext team really have built a fantastic library, and a vibrant community around it. The library had all the hallmarks of an open source success story. Now, however, Ext have committed the cardinal sin of an open source project: they have undermined the trust of their own community. I can see the strategy making a short term profit, and perhaps even a long term business. I cannot, however, see the community returning to full strength. In the long run, although Ext may have a successful commercial offering, they will lose a large part of their current and potential community to competing and still-open projects. The power of the community will see those competitors flourish.

A major focus of agile development is fast feedback - of many kinds. As this idea is taken to its extreme, it is worthwhile asking if feedback can be too fast. That is, is there a point at which shrinking the feedback loop becomes counterproductive?

The benefit of feedback is knowing if you are heading in the right direction. The faster the feedback, the less time you spend heading towards dead ends. So the benefit increases as feedback gets faster. But what of the cost? It is useful to split the cost into two categories:

1. Setup cost: how hard is it to create the system to produce the feedback? Is it more difficult to create faster feedback?
2. Ongoing cost: what does it cost to receive the feedback? Do you pay this every time?

Setup cost is not usually a big issue except in extreme cases, as it can be paid off over time. More interesting is the ongoing cost of receiving and processing feedback. Naturally receiving, understanding and acting on feedback takes time. The important part is distinguishing when this time is productive versus wasted. Processing feedback can be wasteful in various ways:

1. False alarms: if the feedback is incorrect, at best it is an irritation. At worst, significant time is wasted chasing a wild goose.
2. Distraction: if feedback arrives when you are in the middle of something, it can interrupt your flow. Even if the feedback is useful, its benefit can be outweighed by the cost of losing your train of thought.
3. Repetition: if feedback tells you nothing new, then it has no benefit. Any time spent acknowledging it is wasted.

How do these problems relate to the speed of feedback? The cost of false alarms is roughly inversely proportional to the length of the feedback cycle. As the relationship is linear, false alarms are not compounded by making feedback faster. In any case, accuracy of feedback is always paramount: false alarms must be eliminated.

More interesting is the relationship between feedback speed and the other two potential problems: distraction and repetition. In both these cases, shrinking the feedback cycle may produce a disproportionate increase in the occurrence of problems. Thus, when shrinking the feedback cycle, care must be taken to address both of these areas.

Distraction can be addressed in multiple ways. Firstly, receipt of feedback should be optional. Users must be able to pause the feedback mechanism (or possibly switch it off altogether). Then when a user needs to for deep thought, they can ensure that they are not interrupted. Secondly, the method of feedback needs to be in keeping with both the importance and frequency of the message to convey. For example, an emergency that requires immediate attention may use a bold and hard to ignore mechanism, whereas a small status update should be less intrusive. Continuous feedback must be modeless — as an example think of the real time spell-checking functionality in many word processors. Lastly, feedback should be categorised to allow smart filtering. Different users often require different levels of feedback — what is important for some is a trivial detail to others.

Repetition is usually simpler to address: feedback can be suppressed when there is no change. Note that in some cases a change for one user may not represent a change for another user. Thus, as above, filtering that is based on individual users may be necessary.

Conclusion

The value of feedback, and indeed fast feedback, is unquestioned. Taking this principle to the extreme, it follows that faster feedback is better. I feel this is true provided that the crucial issues of distraction and repetition are addressed.