Plugin problems
So for those that don't know, I spend a large part of my free time working with the Trac project. It is a FOSS project management tool, and comes with a very nice plugin interface and framework. Recently a somewhat large dispute has arisen over how best to implement certainly functionality. Some people want to see all but the rarest subsystems end up in Trac core, while others (including myself) would rather see Trac stay a very reduced system that just does a few things well and leave the rest to plugins. This is largely the model that Firefox has used. The base browser is very simple, it browses the web and little else, but it does this very well. It has hooks to let plugins do all the fancy stuff though, and there are plugins for almost everything you can imagine, probably two or three. During the course of this discussion I have found two major issues that I think are being strawman'd.
1. People want Trac to be a turn-key system that does everything and the kitchen sink so they can just go and do their project.
While I understand the desire for this, I think it is fundamentally not what Trac is or should be. There are a number of projects (buildix, oforge) that take Trac and a number of supporting tools and plugins, and combine them all into a that kind of single turn-key application. I think this is fine, if you want that kind of system, install one. I don't think that means that Trac needs to start growing features like crazy.
I think a better solution is to lower the friction to installing plugins. It is currently a somewhat annoying process, but I think we can make tools to vastly improve that.
2. People equate "plugin" with "poorly written bit of code that will eat my data if I look at it crossly".
This I just don't understand. I work hard on the plugins I write. Some are hackish, but I am usually pretty clear in my documentation if I think a plugin has a danger of being unstable. Just because I don't want to see some of my things integrated into core doesn't mean they are not good solutions. I just don't think the right place right now is in core. Really this is somewhat offensive to me that people are so quick to dismiss all the work I do just because I label them as 3rd-party. Maybe its just a PR issue, maybe people have had bad experiences with some other system, but whatever it is I think this will need to be fixed before the discussion can move on.
Related to this is the problem that many plugins for Trac are unmaintained crap IMO. I suppose I have higher standards than most for Python code quality, but still. The PeerReview plugin is on its 4th set of maintainers I think, after the initial authors vanished into the night. The only ideas I have to fix this are better community rating systems (voting/ranking on both plugins and authors) and showing kwalitee metrics for plugins via cheesecake.
I believe very firmly that plugin-based ecosystems are the only sane way to develop complex software as time goes on, and I think we should nip this on in the bud sooner rather than later. Trac should focus on developing framework-level features and fixing/polishing what we have now, and really very little else.
1. People want Trac to be a turn-key system that does everything and the kitchen sink so they can just go and do their project.
While I understand the desire for this, I think it is fundamentally not what Trac is or should be. There are a number of projects (buildix, oforge) that take Trac and a number of supporting tools and plugins, and combine them all into a that kind of single turn-key application. I think this is fine, if you want that kind of system, install one. I don't think that means that Trac needs to start growing features like crazy.
I think a better solution is to lower the friction to installing plugins. It is currently a somewhat annoying process, but I think we can make tools to vastly improve that.
2. People equate "plugin" with "poorly written bit of code that will eat my data if I look at it crossly".
This I just don't understand. I work hard on the plugins I write. Some are hackish, but I am usually pretty clear in my documentation if I think a plugin has a danger of being unstable. Just because I don't want to see some of my things integrated into core doesn't mean they are not good solutions. I just don't think the right place right now is in core. Really this is somewhat offensive to me that people are so quick to dismiss all the work I do just because I label them as 3rd-party. Maybe its just a PR issue, maybe people have had bad experiences with some other system, but whatever it is I think this will need to be fixed before the discussion can move on.
Related to this is the problem that many plugins for Trac are unmaintained crap IMO. I suppose I have higher standards than most for Python code quality, but still. The PeerReview plugin is on its 4th set of maintainers I think, after the initial authors vanished into the night. The only ideas I have to fix this are better community rating systems (voting/ranking on both plugins and authors) and showing kwalitee metrics for plugins via cheesecake.
I believe very firmly that plugin-based ecosystems are the only sane way to develop complex software as time goes on, and I think we should nip this on in the bud sooner rather than later. Trac should focus on developing framework-level features and fixing/polishing what we have now, and really very little else.