[TYPO3-core] Decide on community vendor name for CMS

Fabien Udriot fabien.udriot at ecodev.ch
Wed Apr 23 18:14:45 CEST 2014

Hi Thomas,

> I don't think it would be good. We introduced Namespaces and Vendor 
> Names to prevent between similar package/extension names. For example 
> there can be more than one shop extension. If the community again uses 
> the same Namespace, nothing is won in this regard.

Please, keep in mind this would be a recommendation and not a mandatory 
thing. I can easily imagine that many extension authors will keep the 
prefix of their company name. Regarding the multiple "shop" extensions, 
as of this writing and probably for a long time ahead we'll have to 
stick to the TER rules which forces extension key uniqueness.

But correct me if I understood you well, in the vision you carry, we 
would have a TER supporting vendor name and displaying them as such on 
the TER FE. This would go pretty much in the direction of a homemade 
packagist for our needs. In this vision, having a vendor name 
"biodiversity" is not harming. Flow would also needs such tool BTW. I 
feel we are slightly drifting away from the topic but the big picture is 
important OTOH.

This being said, I don't consider having a generic vendor name being 
necessarily a bad thing.

> Further platforms like packagist assume that your composer vendor name 
> somehow reflects that you are allowed to register new package names 
> under your vendor. How should this be possible in a shared fashion?

TER already allows everyone to register its package (well, you will 
argue with the vendor name).

> Think further about a matching github team name. Should be everybody 
> be in that team?

No Github organisation. We have our Forge for that. How to improve it, 
is another topic.

> Let things evolve indepently and give them a plattform there they find 
> other typo3 packages. I think we planned a successor of the TER based 
> upon composer. There each typo3 related packages/extension will be 
> presented as part of the ecosystem. What happens beyond that should be 
> out of our reach.

Out of reach? If you mean they are outside our control / infrastructure, 
it is not a problem as long as talking Composer.

> Vendor names also tell you who is the main maintainer of the code. If 
> it's the community then everybody is allowed to directly push to that 
> repository? I don't think so.

You'll find this info typically on the home page of the project. It 
could be mentioned on the TER detail page or if not released there 
within the composer.json file.

> There are always a bunch of people that are gatekeepers and have a 
> vision of the roadmap. If these people form a team then the team name 
> should be the vendor.

True, although in most cases it is bound to one person.

> If you want something community driven then choose something like 
> T3MediaGangsters and tell people clearly how they can contribute in a 
> contribute readme in the project.

ha! ha! signed: your faithful Daltons...

>> FYI, in the Flow world, they have picked up "FlowPack" as community 
>> vendor name. I have only heard
>> that and if someone have more relevant details, feel free to tell 
>> more.
> I don't think that FlowPack is intended to be an umbrella vendor for 
> each and every Flow package created out of a community process. I 
> think it is rather a team of Flow core people that maintain a bunch of 
> Flow close related pacakges.

I think so too although I can imagine popular packages becoming 
"FlowPack" at one point.


More information about the TYPO3-team-core mailing list