I think it's appropriate to remember that those of us writing plugins want to be generous with our time but also have other motivations for working long hours for free - we need to get our names and our companies' names out there, and we need to build consulting business. Motivations not unlike those that drove the development of Symfony in the first place.
Really long and annoying plugin names are a self-punishing choice (people will be less likely to use them), but a two-letter prefix unique to your company makes sense IMHO. Everyone has to think about branding to some extent. In general, I think visibility for developers and their companies should be higher. It doesn't cost the Symfony project anything to help that happen. In the near future P'unk will probably set up a separate trac instance so that we can have ticketing for our plugins (currently not available to non-core Symfony plugins via the main Symfony site) and so that we can get some sort of handle on how many people are actually downloading and using them, at least if they are doing so via svn (no statistics at all are available via the main Symfony plugins site). I know there are lots of people out there using sfDoctrineApplyPlugin only because I heard from a chorus of folks who wanted it ported to 1.2. But normally I get almost no feedback at all. In general the Symfony project could do more to make developing and maintaining high-quality plug-ins an attractive possibility for developers. While I'm on the subject, let me add my own to the chorus of voices begging for a comments mechanism for plugins! There is absolutely a problem of too many low-quality plugins and obsolete plugins and too little information that would help people make informed choices among them. I am willing to be among those stuck with the task of moderating the incoming stream of comments. -Tom On Sun, Feb 22, 2009 at 7:42 AM, Bernhard Schussek <[email protected]> wrote: > > Hi all, > > On Sat, Feb 21, 2009 at 11:34 PM, Tom Boutell <[email protected]> wrote: >> A two-letter prefix of your own on filenames, replacing the sf prefix, >> is very common. > > Although this is a common way to name plugins, it is not the > officially recommended one. Fabien's latest statement is that the > prefix to be used is "sf"[1], even though he made contradictory > statements in the past[2]. > > I personally think that choosing custom plugin prefixes is a bad > choice. Right now, we have a lot of different plugins for the same > purpose with varying names (sfSimpleCMSPlugin, sfSimpleCMS2Plugin, > sfInstantCMSPlugin...). Mostly all of these plugins are in an unusable > state. Now if we use custom prefixes as well, this situation will get > worse (pkSimpleCMSPlugin, abSimpleCMSPlugin, otSimpleCMSPlugin... ???) > > What is really missing in symfony is a clear community guideline for > developing plugins. My personal opinion on plugin development is: > > 1. Choose a very simple but descriptive name for your plugin (e.g. > sfCMSPlugin instead of sfInstantBoosterSimpleCMSPlugin) > > 2. If a plugin already exists with that name (or a similar one), > contact the author. In the best case, the author will agree that you > work on the plugin as well. If he does not or if your opinions on the > architecture of the plugin differ too much, create a new branch inside > that plugin. The highest goal would be to showcase your ideas, discuss > them with the community and the original author and eventually merge > some of the changes that work well back into the trunk. > > 3. Document your code excellently, write test cases and publish good > written documentation comparable to the symfony documentation. > Francois held a great presentation about this on SymfonyCamp08 [3]. > > 4. Showcase your plugin and write about it. Write about it in blogs, > publish screencasts, do everything to arouse interest. The more users > you have, the more feedback you will get, the more developers might > eventually join your team and help you develop the plugin. > > After all, plugin development is a community effort. This also means > that not everything might be solved exactly how YOU want it, but how > the community needs it. Splitting plugin development across multiple > plugins with the same purpose but no shared effort, on the contrary, > does not help the current situation. > > > Bernhard > > > [1] http://groups.google.com/group/symfony-devs/msg/4c47ffd08aed294a > [2] http://groups.google.com/group/symfony-devs/msg/90498ce79958c591?hl=en > [3] > http://redotheweb.com/2008/09/15/developing-for-developers-my-symfonycamp08-presentation/ > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
