On Sun, Feb 22, 2009 at 9:10 AM, Bernhard Schussek <[email protected]> wrote: >> > I understand that, but we have to investigate the cause of this > problem. I guess that very few people use or even know about your > plugins. Again, I think the root of this problem is the current > situation about the plugins. There are too many plugins with too > little information about their quality and about differences between > similarly named plugins as well as too little documentation.
I agree entirely here. > I personally mostly go for custom solutions, because the time required > for finding an appropriate plugin, getting to know how to use it and > debugging it hugely exceeds the time required to write the required > functionality myself. I can well imagine that other developers feel > the same. I have this urge a lot too, but I wind up regretting it. (: We got a lot of mileage out of sfSimpleCMSPlugin before it got stale. We also get a lot from sfFeed2Plugin, sfWebBrowserPlugin, sfDoctrineActAsTaggablePlugin and sfJqueryReloadedPlugin. We've contributed back to sfDoctrineActAsTaggablePlugin and sfJqueryReloadedPlugin, but that didn't take as long as reinventing them would. And of course everybody uses sfDoctrineGuardPlugin or sfGuardPlugin, but since those are practically in the core I hesitate to mention them. >> Most of the time a few "burning souls" do most of the >> work on any given project. > > Well, that's always the case for OSS with little publicity. It's the case for OSS with lots of publicity. Most of the work on Firefox, OpenOffice and even the Linux kernel has historically come from a small core of people. >> The prefixes also serve to keep the sf namespace clean for new core >> plugins > > Why should the core team release functionality for something that is > already actively being developed by the community? I was referring to the middle ground between plugins at large and the actual Symfony core: "core plugins." Plugins like sfGuardPlugin and sfSimpleCMSPlugin that are blessed with access to the ticketing system. Functionality that many, many people need and more than a handful of people are willing to contribute to, but which nonetheless doesn't need to be in the core itself where everyone would be stuck downloading it. Core plugins would also need to be released under a suitably open license (such as the MIT license used by Symfony itself). I like the idea of reserving the sf- prefix for core plugins. Plugins that the Symfony team has recognized as being strong enough and popular enough to deserve that designation. Conversely, inclusion as a core plugin would be attractive to developers and we'd be willing to give up our own two-letter prefix in exchange for being on a list of plugins that people actually use. (: Of course, a comment system would also be useful. It would be more democratic than waiting around to be blessed as a core plugin, and a lot faster too. >> they prevent me from getting stuck if somebody *else* >> abandons a project which is camping on the "right" name for something >> I want to do. > > In this case nothing holds you back from taking over the lead of the > abandoned plugin and to work on a next major release. Nothing but the months of politics and nonsense that ensue before everybody agrees that this has happened and I'm designated as a developer on that project. > I see that, but you cannot compare the size of these projects with the > size of the average plugin. There's just no point in forking an > abandoned plugin that covers maybe 1000 lines of code. Such a plugin > cannot even be considered "complete", so somebody should take the time > to finish it off instead of forking it. sfSimpleCMSPlugin is currently an "abandoned plugin." It's not trivial, and it's quite complete for Symfony 1.0. It's just not moving in new directions anymore. > I would really like to know some plugin development and usage > statistics. In the past, Fabien only ever released information about > how many new plugins had been published. I don't think that this > information is very useful. I rather would like to know the average > development time before plugins are abandoned, the ratio of > functionality vs. users etc. If we had these statistics, we could base > our investigation of the "plugin problem" on some real facts. I agree completely with this statement. -- Tom Boutell www.punkave.com www.boutell.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
