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
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.