Short Coder Essay: Plugins are Not For Users

[mouser]

Short Coder Essay: Plugins are Not For Users
by donationcoder member mouser, December 17, 2008

This is a really short essay about the significance of adding a plugin system to your software, from the standpoint of developer happiness.  It's something i've been meaning to write for a while.

Plugins/Extensions/Add-ons

Plugins, sometimes referred to as extensions or add-ons, have probably been most popularized by the FireFox browser, which has gone a long way to bringing the concept into mainstream consciousness.

There can be little debate about the usefulness of such a facility for end users of popular programs.  The number and variety of the FireFox extensions are impressive, and they have opened up all kinds of possibilities for the program.


Low-popularity Programs

For a high-popularity program like firefox, there are enough active users and developers that extensions emerge rapidly and continuously.

For less popular programs, extensions may be very slow in coming, of mixed quality, and of arguable nescesity. A small developer may be wary of spending the time to code support for a plugin api, and even more resistant to dealing with all of the other things that go along with that (such as documenting the interface, providing examples, helping coders get familiar with the code, etc.).

There is no immediate benefit to end users from a plugin system -- there is only a benefit for them when people start creating useful plugins.  A programmer may be resistant to going through all of the trouble to develop and document a system without knowing ahead of time that there is sufficient interest by fellow programmers in developing such extensions.


Plugin Systems For End Users

When I added a plugin system to a six-year-old program of mine called Find and Run Robot in February of 2007, I wasn't sure what to expect.  It was the first real project I had worked on that i went through the trouble of adding such a plugin API to.  Actually adding the plugin API wasn't that much work, but there is a lot of ancillary work that goes along with such a process, and in the beginning i was the only one writing plugins for it.  It seemed like a lot of work with little benefits.

My hope was that eventually people would write some plugins that other end users would like, and that this would save me from having to add these feature requests into the main program.  My main motivation in coding the plugin system was so that i could say to someone who made a feature request: "maybe someone will make a plugin for that feature", and feel ok about not implementing it.

But I didn't write the plugin system for myself -- I wrote it for the end users.  So that they could get features they wanted without me having to do as much work.


Plugin Systems to Reinvigorate the Developer

But then something unexpected happened in the last year or so with the plugins for my program.. A very cool coder started doing some unexpectedly fancy things that made me sit up and take notice [Emmanuel Caradec on the DonationCoder forums].  He basically wrote a plugin dll wrapper that made it possible to write javascript plugins for the application which was written in C++ (something i wasn't even sure was possible!).  A few skilled javascript coders [users czb and ewemoa in particular] then took this concept and ran with it, pushing the boundaries with the kinds of things that such plugins could do, and eventually writing a kind of meta-plugin system and other strange and delightful hacks.

As I talked with these coders about the things they were doing we inevitably got to talking about new features they needed to do new things they wanted to be able to do, and new ideas for the program that could be used as building blocks for new plugin ideas.  Suddenly I found myself reinvigorated by these fellow coders, and newly excited about working on this six year old program.

I always love interacting with end users and adding new features, but interacting with plugin writers is uniquely satisfying from a developer's perspective.  The clean separation of code means that you get the teamwork and facilitation, without any of the pain of version control conflicts that you have when working with a team on shared code.

There are other benefits to the developer from adding a plugin system to your program; moving as much of the features out from the core of the system to a plugin system makes it easier for you to maintain and extend, and keeps the program lean and flexible.  But for me the real surprise has been how much fun it is as a developer to interact with plugin writers, and how much it has added to my enjoyment of working on the program.

If you are a small/independent developer, I encourage you to make the time and effort to implement a plugin system for your software -- not for your end users -- but for yourself; you may be surprised at how much more you enjoy working on your own programs again.

-mouser
 12/17/08

[vjcamarena]

I absolutely loved it, and I can't even program!

[f0dder]

Whether a plugin system makes sense depends a lot on your project - for instance, it would be insane to add plugins or scripting to fSekrit. But as you already sorta mentioned, adding plugins/scripting can be worthwhile even if you don't expect anybody else to write plugins, since you can keep a stable core and play around with plugins - if you use a scripting language, it becomes possible to prototype stuff really fast.

[ewemoa]

Specifically regarding the essay:

My hope was that eventually people would write some plugins that other end users would like, and that this would save me from having to add these feature requests into the main program.  My main motivation in coding the plugin system was so that i could say to someone who made a feature request: "maybe someone will make a plugin for that feature", and feel ok about not implementing it.

-mouser (December 17, 2008, 12:14 PM)

The delegation / parcel-off task angle is very important IMO.  All other things being the same, without a plugin system the number of potentially code-contributing folks seems like it might often end up being smaller.  Even under conditions where source is available for all to see, getting one's head around a whole application or even a subsystem may be troublesome -- questions such as: what subsystem to start w/?  are there any subsystems?  will any potential changes I make be merged in?  how can I make some changes in a good / non-intrusive way?  come to mind.  From the application author's perspective, I imagine that even if source is available for anyone to read, there may be quite a bit of reluctance to accept changes (e.g. understanding the changes takes time, deciding whether they are a good idea takes time, etc.) -- but w/ a decent plugin system, it seems like this concern can be greatly mitigated if not eliminated at least for some parts of the application.

I guess the end bit there is hinted at by:

The clean separation of code means that you get the teamwork and facilitation, without any of the pain of version control conflicts that you have when working with a team on shared code.

I can relate to:

There are other benefits to the developer from adding a plugin system to your program; moving as much of the features out from the core of the system to a plugin system makes it easier for you to maintain and extend, and keeps the program lean and flexible.

I might add that it seems likely to me that a smaller application may be easier to test and since it is smaller it seems like it should be easier to think about (than something bigger) so it might often be easier to productively work on the application (which is a huge win IMO - thought precedes action?).

But for me the real surprise has been how much fun it is as a developer to interact with plugin writers, and how much it has added to my enjoyment of working on the program.

Until you pointed this out, this never occurred to me -- I think it's a great observation 

I have found working on plugins for FARR to be quite enjoyable 

FWIW, I had previously written plugins for another similar system, but what I appreciate about the FARR situation specifically so far (in no particular order...really):

• an especially responsive developer
• a lot of sample code -- both JavaScript and not (thanks to czb and others)
• not having to write an intermediate system to write plugins using something like JavaScript (thanks to ecaradec)
• DC participants, its forums, IRC channel, and other related resources
• not having to restart the application to test
• not having to examine the running host process to learn how the system behaved
• existence of app-bundled documentation
• an opportunity to learn some JavaScript
• an opportunity to learn more about FARR (some of this knowledge might be applied in an end-user context)

Some additional things I imagine might be nice include:

• An easier way to test plugins -- perhaps a "simulated" or "mock" FARR system (or mode) that plugins can run automated tests with somehow (GUI-testing blech!)
• Community-updated plugin-API documentation - with links to sample code

I guess that's likely to be more (or less?) than my two local currencies worth.

[czb]

Very nice topic. 

Community-updated plugin-API documentation - with links to sample code

-ewemoa (December 18, 2008, 01:32 AM)

Yes, I think this is the first thing we should do after we finish fsubscript system

[ecaradec]

I am really pleased that plugins developer give you more interest in improving FARR. This is probably the software that I use the most with Visual Studio and VIM. FARR is a great thing.
Someone said on the forum that you are a great motivator too. That is so true.