I think a full text search engine on the plugins README would help people a lot. It is hard to find what you want when you can only search on name and author.
On Feb 22, 5:27 am, Tom Boutell <[email protected]> wrote: > 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.comwww.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 -~----------~----~----~----~------~----~------~--~---
