| Follow @monsterjavaguns
Atlanta, GA
Jason van Gumster mostly makes stuff up. He writes, animates, and occasionally teaches, all using open source tools. He's run a small, independent animation studio, wrote Blender For Dummies and GIMP Bible, and continues to blurt out his experiences during a [sometimes] weekly podcast, the Open Source Creative Podcast. Adventures (and lies) at @monsterjavaguns.
Authored Comments
I actually use Redmine for managing creative projects. The ability to define custom workflows and set scheduling (plus the SCM integration) make it really nice for both code and non-code projects.
I'm not necessarily 100% convinced that this is an always-applicable as a something that could be considered a Good Thing(TM). I might consider the following as exceptions:
* Inherently complex applications. In the spirit of Atom (and Emacs, and a variety of other programs), yes, you *could* extend a text editor into being a full IDE. However, if your primary focus is to develop the full IDE (NIHS, blah blah) or a full-featured word processor, then the simple core concept starts to degrade.
* When you develop a highly extensible application, you also create another class of user that you need to support (the extension developer). If you're already struggling to provide regular user documentation, adding that additional tier of user is a non-trivial maintenance cost that needs to be accounted for. It also adds a level of complexity to the code... making it *less* simple.
* I'm going to put on my paranoid hat here a bit, but extensibility also opens the door to commercial hijackery. There are a class of applications that endeavor to provide a user with all of the tools necessary to complete a task (or set of associated tasks). However, when users are forced to be reliant on third-party extensions to get their work done, then the original application is failing at its mission (especially if those extensions end up being closed-source). There are times when you need to decide if you're writing a user application or if you're writing a library/framework. You can't always do both.
* But even if everything stays open, there's userland complexity brought on by this extensibility. You have support questions that start off with, "Why can't I do _____?" and the answer ends up being, "You could if you use these extensions." And, invariably, the follow-up is, "How in the world was I ever supposed to know that?" Extensibility doesn't work without some kind of discoverability engine. A packaging system helps, but that's another layer of complexity (plus this may introduce concepts that compete with the native packaging system of the operating system or distribution in use).
OK... so I wrote a lot in this response (more than the formatting probably supports comfortably), but for me I suppose you could boil this down to, "No. It's not *always* better." It *can* be better if you build your project around that concept and get all of your scaffolding in place to support it... but I'd be wary of (for example) recommending that the majority of existing projects start shifting in that direction.