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