Think about what we did wrong and how to continue

[MarcWeber]

Despite VAM works great we did something wrong - user estimations (2014-02):
vundle#rc hits @ google (approx 272.000 hits)
vam#ActivateAddons hits @ google (approx 800 hits)

ratio (google hits): 340
star ratio (github): 13
fork ratio: 9

Maybe I've been mistaken and nobody wants a managed pool of plugins, maybe we didn't care enough about README.md ...

Anyway - time to think about how much additional time to spend on VAM ..

[Shougo]

vundle#rc hits @ google (approx 272.000 hits)
vam#ActivateAddons hits @ google (approx 800 hits)

I tested it by neobundle(approx 27000 hits, but most of them are Japanese entories)

I think VAM's concept is good for example dependencies, plugin information, many VCS support, vim.org support, but the configuration is different from Vundle.
Users must pay the migration cost.
neobundle is not, but neobundle also has smaller users than Vundle.
I think Vundle's feature is simple and good enough for most of people.
Although neobundle has many features, it is complex plugin manager like VAM.

[Shougo]

Anyway - time to think about how much additional time to spend on VAM ..

It is difficult problem. But I think vim-pi concept(plugin information repository) is important than VAM.
People may use different plugin managers(VAM, Vundle, neobundle,...), but they should use same repository information.

[steveno]

I realize that as an open source dev you always want a large following, and that when you're not named Linus Torvalds people just don't follow you by default (ie his stupid diving app that everyone was excited about even though you know none of them dive). I assume no one would use git either if it weren't for him. It's great, I guess, but no more special than mercurial for example.

Anyway, I hope you keep the project going. You've got great work here. gmarik has effectively bowed out of vundle. I now question the future of that project personally. I'd hate to lose VAM too.

[Shougo]

Yes, the selections are important. Although smaller than Vundle users, VAM has many users. VAM don't have to stop the development(neobundle don't have to stop, too).

[glts]

I've seen your messages on vim_use, @MarcWeber, and I get the impression that you are pretty disappointed.

But 300+ stars on GitHub isn't too bad – and I agree with @Shougo that you have something extremely important going on with vim-pi: the central plugin info repository. That is something that eventually all plugin managers might depend on. Maybe put a priority on that for the time being?

[MarcWeber]

@Shougo vim-pi concept(plugin information repository) is important than VAM.
You were missing a "more than" here :)

I agree - which is why I pushed exactly that question - how vundle wants to implement dependency management - and whether we can collaborate

gmarik did care enough to close / move an issue:
VundleVim/Vundle.vim#241

@Shougo: VAM does already implement a vundle emulation, getting the {rtp: .. } stuff work (second argument to commands) would be doable, we could have a second rtp in VAM thus not much would change for vundle users. We could there easily ..

@glts: Its not only about followers, also about trying to find the best way to maximize benefits (that's what open source is for ..) - and about talking to each other.

If Vundle would adopt vim-pi (and having names rather than github pointers) - then it would turn into VAM (minus other VCS support). And that's the problem. I even offered switching name of VAM to vundle in that issue 241, gmariks action was closing and reopening the issue saying "he wants to solve problems, not creating them".

Please also read the "why vim sucks" section on vim-wiki.mawercer.de. I do not only worry about VAM, but also about Vim and its community (Emacs has more users anyway). If I would have known all the trouble maybe I would have learned Emacs. I chose Vim for 'less stress to finger" reasons without knowing better that time lol. It still serves me - switching would be too much pain

I'd even join vundle, but it doesn't make sense because VAM has everything vundle has (feature wise). Even though my mail to vim-use didn't get much replies we have to push the community idea even if not many will join - those who do will benefit.

[Shougo]

I agree - which is why I pushed exactly that question - how vundle wants to implement dependency management - and whether we can collaborate

I don't know whether the dependencies feature will be implemented in Vundle.

VundleVim/Vundle.vim#384

@Shougo: VAM does already implement a vundle emulation, getting the {rtp: .. } stuff work (second argument to commands) would be doable, we could have a second rtp in VAM thus not much would change for vundle users. We could there easily ..

If VAM can compatible with Vundle like neobundle, users may do not change plugin management system.

I'd even join vundle, but it doesn't make sense because VAM has everything vundle has (feature wise). Even though my mail to vim-use didn't get much replies we have to push the community idea even if not many will join - those who do will benefit.

I think Vundle is more simple and stable plugin management system than VAM and neobundle.
So, it is less features than others. It is directional difference.

[MarcWeber]

Shougo: What do you mean by "more stable"? On the other thread you've said "I don't think VAM is ready" ? What is your impression based on? Maybe you should give it a try once before making such statements.

[MarcWeber]

The really funny thing is: given enough users they also get close - some PRs never got merged like this supporting additional VCS: VundleVim/Vundle.vim#134

[MarcWeber]

#241 contains some "Easy to fix - for starters" issues people who want to help but don't know where to start could start with ..

[Shougo]

Shougo: What do you mean by "more stable"? On the other thread you've said "I don't think VAM is ready" ? What is your impression based on? Maybe you should give it a try once before making such statements.

Vundle has less features and changes than NeoBundle/VAM.
So I think it is more stable. Unfortunatelly, if you add features, it will be more complex and less stability.

[MarcWeber]

ZyX has done some work on implementing tests. Install/updates are used often, so regressions would be caught fast (even in the VAM case). The last time something trivial broke we had an issue within 48h or less.

By the way computers generally fail because there is cosmic ray - so why are we using them at all? :) Multiply this by the amount of lines the linux kernel has - multiply it by the amount of for (c = 0; c <= count; c++) usages in the kernel (I found 2-3 cases when using a simple grep the last time ... (of course it should be < not <=). You're right - that's why I don't want to add parallel install - because then I'd start using Vim the way it was not written/tested (I had and have enough issues with vim-addon-async which uses client-server feature ..). Counter measure: We have 4 eyes reviewing code (mine and ZyX) - and that's proofen to cause less bugs. So which argument is stronger? .. :) You're right in the general case - but given that Vim is buggy by design (eg resize issue) (vim-wiki.mawercer.de -> why viml sucks) .. I don't think we should think about starting such a discussion here.

[Shougo]

You're right in the general case - but given that Vim is buggy by design (eg resize issue) (vim-wiki.mawercer.de -> why viml sucks) .. I don't think we should think about starting such a discussion here.

Vim may be broken. But, to rewrite Vim will break more and more.

[thet]

@MarcWeber thanks for creating VAM and vim-pi! that was my only vim plugin manager for years, but now i'll give vundle a try.
it's a bit tedious to fork/pull-request every time i want to try out a plugin not available in the VAM/Pi list, like this one: https://github.com/tpope/vim-vinegar. also, is a lot simpler and leaner than vam, which is not a drawback. vundle seems perfect to support the use case of adding a repository just found on github. unfortunately it doesn't support hg and others, but that seems to be fixable.
i can't say if i stay with it or switch back to VAM. time will tell.