What can the Vbulletin community do for VB 5.x ?

[katie hunter]

Originally Posted by cellarius

And here we go again. All this has nothing to do with xenForo at all. You're so fixed on that other software. People did not leave because they liked other software or didn't like developers fired in the first place. They left because vB4.0 was practically unusable at first release (and it stayed that way until up to 4.0.7 at the least), and became halfway good only with 4.2. And many of those staying with vB during the long stony track that vB4 was and prepared to give IB a second chance, were apalled when IB pulled the same stunt again with vB5 - selling customers a software for very good money that would clearly take years to be in state to be used productively.

You see, I have been using vB for years, was a fan, coded lots of addons, did alpha and beta testing, ddicating lots of my spare time to that. The problem was: I did it not only for free, but also for nothing. I (and I'm not alone in this) more and more got the feeling that we were being ignored, much like the support and even dev staff must still feel. Our opinnion on basic pruduct design questions was not valued, our feedback usually was in vain. What do you think with how many of such nifty design ideas we did come up for vB4, or, for that, for vB5? How many of the issues that IB now sells as vast improvements in minor releases were already pointed at in alpha/beta testing? The problem always was: Once the users (including alpha and beta testers) got a look at the product, practically everything was set in stone, including the release date (although no one ever admitted that). The state of the product did come into the matter, neither with vB4 nor with vB5. How else to explain the catastrophic state of vB4 and vB5 at release? A state, that was very well known to IB management, if they only once listened to our feedback?

You see, different from those working for IB, I (and many others) had the possibility of turning away in disgust at that. And given the employee fluctuaton in the last few years, even some of those getting their paycheck from IB did not really fancy working there, or develop any pride in the product. The lawsuit just added to that, but it's not the core of the grudge. As I said in the beginning: Had IB continued to deliver even halfway decent software, many of the old hands would not have turned their back. Really, you don't seem to understand half of the problem here, being all fixed on your own grudge with xF.

I agree to some part about what you said when it comes to IB but i don't hold any grudge against XF. They really are as I described before and you read my previous posts in different threads. Anyways, i won't talk about XF or how they acted. This is about VB 5.x and IB.

[nhawk]

Unless things have changed, IB isn't the root of the problem. IB is part of a larger conglomerate held by the Hellman & Friedman group.



But, when I went to the IB website I found that vBulletin isn't even listed in their list of brands they own. So in my opinion, that is a pretty good sign of where vB stands in IB's opinion of it's own division.

Anyway so far as someone purchasing vBulletin, I don't see that happening for several reasons.

Is vBulletin even for sale? If not, that squashes it right there.

If vB is for sale, what are it's profit margins? Personally I don't see vB operating with a profit. If that's the case, the purchase would have to be done with venture capital. And anyone providing such capital would want to know when they would get their money back. At this point, depending on purchase price I would have to say 3 to 5 years. I don't think any venture capitalist would wait that long.

Finally, if vB were to be sold, there would have to be a major shakeup at the company. In the short term, that could have disastrous results if the fallout within the company isn't controlled. If the company were to survive a major shakeup, then there's the development time for something that's usable. And we're back to my last comment about return on investment. You would be looking at a year or more before a usable product could be developed.

vB4 started the company on a slippery downward slope. It started to recover but then released vB5 which took away any foothold it still had and continued the downward slide of the company.

Unless someone with come common sense steps in and actually reads what the alpha/beta testers were saying before the release of vB5, and makes some major changes, I fear vB5 is the death spiral for vBulletin.

[final kaoss]

Originally Posted by nhawk

Unless things have changed, IB isn't the root of the problem.

Oh I think IB is the one who is in control of making decisions involving vbulletin. Probably the most accurate review coming from a Software Engineer:

Software Engineer (Current Employee)
I have been working at Internet Brands full-time

Pros – If you don't work in HQ, you won't be expected to do anything.

Cons – * No 401k match.
* Unless you work in HQ, they don't know you exist, nor care about you.
* They buy up companies, absorb their tech stack into their data center, and then shut them down.
* None of their departments communicate with each other, so they get nothing done.
* Managers are spineless, and never make any decisions.
* Pay is terrible
* They prefer to hire entry-level people and brainwash them into thinking that they work at a great company
* If you work in HQ, your workload will increase whenever someone leaves, because they never hire anyone.

Advice to Senior Management – Fire management, hire talented people, and pay them well.

No, I would not recommend this company to a friend – I'm not optimistic about the outlook for this company

[nhawk]

One of the keys to that review is this...

They prefer to hire entry-level people

I'm pretty sure I saw similar general statements in several reviews.

Hiring someone fresh out of college is actually a challenge. I've had to do it many times in my career.

The last thing I would tell a fresh graduate before I hired them went something like this...

You can take half of what you learned and throw it out the window because it's out of date or not applicable in real life. And if you can take the other half and apply it properly then you have the job. If you don't think you can do that, tell me now so we don't waste each other's time.

And that's where a good portion of the problem is with vB5. Fresh graduates have grand ideas that just don't work in real life. And there's nobody guiding them back to reality.

[katie hunter]

But VBulletin developers aren't new graduate college students. The issue here is that we need more, currently I was told we have 4 developers only.

Originally Posted by Paul M

Excluding Kevin, who spends a lot of time on project management, there is only David, Gorgi, Ed & Jin.
They do not all work exclusively on vBulletin 5, there is also vbc & vbcloud work (vbc includes vb.org, vb.com & vbg admin).

Also there is nothing wrong with new graduate web developers as long as they are graduating from prominent universities like Harvard, Yale and so on, they do have the skills and learn while in college. I guess what I can say is that there are 2 type of web developers, those who relay on everything they learn from college and those who always explore new ideas from outside resources and love to implement unique ideas, the latter is what we need.

Founders of Google, Twitters, Facebook, Disqus and all these unique ideas were new graduate students with visions and ideas that they like to implement and test.

[nhawk]

Facebook is a good example of a company that tried something and then backed away from it.

They tried doing everything client side like vB5 is and changed back to server side for the very reasons vB5 doesn't work well. It eats up database query time and slows response way down.

[Zachery]

Uhh what? How does doing things client side eat up query time?

[nhawk]

Originally Posted by Zachery

Uhh what? How does doing things client side eat up query time?

Without going into details, here's what I see happening with vB.

1) vB5 sends out all of the page layout, javascript, CSS etc. and it's loaded in the browser. This includes many things that aren't displayed on the page until some script action takes place.

2) The browser sends a request for the information to be displayed to vB5.

3) Because of the massive amount of information needed to display vB5 client side (which includes many things that don't show until a script calls for it), that results in 60 to 100 database queries per client on page load.

Whereas, a per page server side system (with some clientside scripting) would make much more sense since only the data needed to display that particular page would be queried.

Even if that analysis is not fully correct. Anything that requires 60-100 database queries to display needs to be reviewed and re-written. There no need for more than say 15-30 queries for any page to display.

[Zachery]

Query count isn't end all be all.

If I can spend .05 seconds doing 100 queries, you'd prefer 10 queries that take .5 seconds?

[nhawk]

Originally Posted by Zachery

Query count isn't end all be all.

If I can spend .05 seconds doing 100 queries, you'd prefer 10 queries that take .5 seconds?

.05 seconds on what kind of server?

I can fire up my Sunfire 6800 with 24 64-bit processors and beat that time, but most people don't have that available to them. And it's not exactly the most economical server to run for a single small application.

Try that on a more common dual or single core server with 5400 or 7200 rpm drives. It's not usually going to be .05 seconds.