Should we allow company/product names in module/theme project names

I agree that the case for themes is different from the case for modules.

In a module, what does the company name add to the project name?
When I see the company name in a module name I always look for another module with the same purpose; if I would find a module called AVPnet Nodewords, I would check if there is a module called Nodewords, and verify if both have the same purpose.
A module name should describe its functionality, not who made it (OK; the word Nodewords doesn't describe what the module does, and that is the reason I created another project for Drupal 7).

I understand that with all the modules already created in Drupal is sometimes hard to choose a name for a project without to create confusion with a different project that could have a different purpose; generally speaking, if two modules have similar names it means that probably they have very similar purposes, and therefore they are duplicates of each other.

I would agree with this, but I think if we have a policy for modules it should apply to themes (and translations, theme engines, etc) equally.

I think the best option for branding is to put it on the project page as most projects seem to. This also allows for changing of the branding if maintainers change, etc.

We can have looser requirements for the node title, as that can be edited quite easily, so if the module changes significantly or maintainer changes, the name can be revised accordingly. This is not true for short names, which should be generic, I feel.

That said, I generally do not like to see company names in the project title unless it's something related to that company's services. For example, Salesforce, YUI or Google Analytics projects wouldn't make much sense -- and it would be very hard to find them -- if the company names were left out of the node title, as the projects are about embracing services provided by those companies. On the other hand, if everyone followed the 'Acquia Marina' naming model, I'm not sure what kind of aftertaste that would leave in my mouth. Then again, this is an open source project where sponsorship is a key to keeping the code flowing, and I'm hesitate to support any Draconian rules at this point, especially since the camel's nose is already in the tent. In the end, it becomes more a matter of taste.

Re longevity of themes, I see two factors that have played into this to date:

• Way back when, Drupal changed its core theme engine from xtemplate to phptemplate. That was huge. Total reinvention was required to move forward. Then things stabilized a bit. It's not clear how much of a reinvention we're heading towards with Drupal 8, but it's going to be big and mere updating of themes is unlikely to happen easily.

• Themes interact not only with Drupal but have to interact with the rapidly evolving front-end development world, where browsers are now getting updates every few weeks, web standards have been in total flux, javascript is being reimagined, and entirely new protocols are coming into play. xhtml moving to HTML5 is but one piece of the puzzle, that itself will be huge.

Now, as the web moves from interconnected silos to streams of data flowing through multiple intersections to multiple devices, the very role of a "theme" is up for review. I would expect to see more theme-module packages in the coming months and years, as we're talking more than just presentation now. These kinds of endeavors will require some intense investment of time and resources, and maybe a company underwriting that should be allowed to be recognized in the project title. I don't know. The limitation seems to make less sense as projects become more product-like.

That said, trying to draw lines between types of projects, or which projects are "products", can get awfully fuzzy. As such, as a matter of policy, I don't see having different rules for different kinds of projects to be a productive way to go, though. Whatever the decision, at this point I feel it should apply to all projects, fwiw....