project renaming and usage improvement

[iamstarkov]

after merging this, please re-publish it, so it will be published by new name

[ai]

+1

[iamakulov]

If doing this, ilyabirman/Likely should also be renamed. Probably there’re other affected libraries.

[eugene-lazarev]

Thanks for PR. Sorry but we won't rename npm package. Please ask @ilyabirman for any non-code updates.

[iamstarkov]

@eugene-lazarev, @ilyabirman why do you want to prefix jouele with ilyabirman- if jouele is available?

[ilyabirman]

Branding :–)

[iamstarkov]

do these kind of npm packages make sense?

• gaeron-redux
• facebook-react
• airbnb-enzyme
• mozilla-mdn-data

[iamstarkov]

branding is in github url

[7rulnik]

Why you don't wanna use scope for this? @ilyabirman/joule?

[dimapaloskin]

@ilyabirman scoped packages looks more suitable for this

[ilyabirman]

I don’t know how exactly this would influence the real-life practice. The tools I use (i.e. sass, svgo and such) I only see in package.json / gulpfile.js as “sass” and “svgo”. I have no idea if they are scoped or not, but I just don’t know who their original authors are. I don’t want to be like this.

Also, Likely (https://github.com/ilyabirman/Likely) has been published on NPM as ilyabirman-likely for a long time already.

As to things like React — well, if I were Facebook and cold afford this level of PR, these problems wouldn’t have bothered me. In addition, facebook-react would seem like it’s some kind of tool for Facebook, as Facebook is a product itself. But ilyabirman-jouele doesn’t look like it’s something “for” Ilya Birman, it perfectly reads as something “by” Ilya Birman. So it looks fine to me.

Anyway, what are the benefits you are missing with the full name?

[ai]

Benefit is to have more contributors. Having personal brand in name could stop other developers in future to maintain the project. Also it isn't look like welcome project, when you understand that you work will be published under other personal brand.

I understand that it is OK in design works. But in development you need morning contribution from other person. More collective work.

For example, if i made whole PostCSS release by my own, I will anyway use “we” in ChangeLog.

But I understand, it could not have real problem. You can support it by your own and will not have problem with finding other maintainers.

But this naming is against current open source culture and, I think, it is main reason why people leave a comments here. It is like go to Western restaurant and seat to the table without invitation — culture difference.

[iamstarkov]

Anyway, what are the benefits you are missing with the full name?

this kind of branding is not common in nodejs community, thus alienates a bit consumers.

Developers usually pick good name and mention themself in the README. Other case is when a good name is already taken, then developers are usually go with scoped names in order to avoid name clashes, like @user/pkg-name.

Last case about naming is pkg-name on npm, but node-pkg-name on github, but this is the case when that particular developer has github projects in different languages.

And i havent seen anyone who would publish their packages with their last name in the package name.

[dimapaloskin]

As you wrote above facebook-react looks like a tool for Facebook. You are exactly right. It's the reason why I was a bit confused when I read the package name first time. I needed time to understand that ilyabirman- is just a "brand".

Using @ilyabirman/jouele looks more familiar and readable to javascript developers.

[iamstarkov]

but people usually use scoped packages only if normal name is already taken

[okonet]

Another reason why I also think this is a bad decision: If you decide to stop maintaining this code, it will be hard to find a new maintainer. npm is full of unmaintained packages and contributing to this trend doesn't seem like a good thing to do.

I have no idea if they are scoped or not, but I just don’t know who their original authors are.

If you're interested, you can always take a look on GitHub and star the project. package.json is intended for computers, not humans, so I think it's okay not seeing all contributors from all packages you use (and all packages those packages depend on) in there.

I don’t want to be like this.

Scoped package is a way to go, then! But honestly, I don't think this is how it works in open source. You'll be famous if you create something really useful, not just because you put your brand on lots of things. I think @mxstbr put it really well in http://mxstbr.blog/2017/02/creating-open-source-projects/

[ilyabirman]

The points you all make are perfectly reasonable. Thanks for the input.

The only mismatch here is that you are saying things like “against current open source culture”, “this is not how it works in open source” as if I was trying to label my project “open source”. But the truth is actually the opposite. Even though you can see the code of this project, I would never identify it as an “open source project”. Think of it as of a product in a package.

If I stop maintaining the project at some point in the future, it means I’m no longer interested in it, and so there is no reason for me to worry about its faith. And if there is someone else who wants to maintain it because they find it useful, and my name in the project name stops them — well, again, it’s not my problem. And I’m not trying to be snarky here. It’s just logic: if someone wants it, they will use it regardless of the name, if they don’t — then who cares?

[okonet]

@ilyabirman https://github.com/ilyabirman/Jouele/blob/master/license.md is saying the opposite of what you're saying, so you should probably update it accordingly to remove this misunderstanding.

[eugene-lazarev]

@okonet, what exactly in MIT License seems the opposite to Ilya's opinion?

[okonet]

@eugene-lazarev this:

as if I was trying to label my project “open source”. But the truth is actually the opposite.

Technically you're correct but I think the whole purpose of this license is to empower open source community. So if you're not seeing your project as "open source" project, then this should probably be reflected in the license?

[eugene-lazarev]

@okonet, license is about legal, not moral aspect.

[iamstarkov]

@evgeny-lazarev License is also communication to developers