[PD] reconciliation of externals/ abstractions/libs

etienne deleflie et at lalila.net
Sat Feb 5 04:38:23 CET 2005


Some years ago I developped a plugin framework for the software company 
I still work for. The plugin framework was a hit because anyone who 
wanted to add functionality could easily do so, without touching the 
existing code base.

Now, 3 years down the track, it has become problematic..... it is a 
maintenance nightmare, and very confusing for users.

Rather than check if someone had already developed a plugin that 
practically fulfilled their requirements (and extending it), developers 
would just write a new one from scratch.... and add it to the pool.

Clients became confused and irritated at constantly having to sift 
through dozens of lists of plugins, many of which did the same thing in 
slightly different ways. Often, a client would find 5 or 6 plugins that 
each did 95% of what they wanted, but never one that did it all.

So we started to reconcile the plugins ..... and found that we could 
easily break down 120 plugins down to a list of less than 30 .... much 
less confusion and each plugin was actually much more powerful (because 
it satisfied a broader range of needs).

... constantly searching through lists of externals/abstractions/libs 
for the thing that does just what I want, I cant help but think that PD 
could benefit from such an effort. It is a difficult effort because 
there has to be some kind of committe which officially accepts an 
external/abstraction/lib into an official list... and then anytime 
someone develops a similar object that adds slightly to the existing 
functionality then someone else would have to roll those 
changes/extensions in. .... but it would make PD much more powerful and 
easy to use.


More information about the Pd-list mailing list