On Wed, Apr 18, 2018 at 11:46 AM, Jim Jagielski <j...@jagunet.com> wrote: > IMO, this boils down to 2 things: > > 1. nginx, particularly, does a LOT of promoting, marketing, PR, etc... > We don't. They get to promote their FUD all the time and remain > pretty much unchallenged.
Launched a thread on one aspect we don't have right, and not limited to nginx. Another aspect we probably won't solve-for is the tendency for new server/proxy solutions to be linux-only, or linux/windows. So long as we can abstract it, we don't have any reason to jettison other active platform communities which offer enough features. > Personally, I'd like to see the the PMC take a more active and > direct role in addressing #1, maybe w/ monthly blog posts > coordinated w/ Sally. It would also be cool to reboot Apache Week > (I know it was an external, 3rd party effort) in in conjunction > w/ the blog posts or instead of it. That's a great idea! But the readers are almost exclusively httpd's adopters, rarely those who are adopters of other technology. Would it help retention of existing admins? Sure, somewhat. > 2. They don't seem to have issues in understanding that new features, > enhancements and improvements to the server is what keeps users > and grows community. Instead, we either spend our time naval > gazing and pondering such inane issues as revisiting versioning, > or else treat the codebase like a school exercise where the > winner is the one who changes the most number of lines. Each time > a new feature is proposed, we have to deal with the incessant > blather around 2.6, 3.0, EOLing 2.4, blah blah blah. We've had > some features in httpd long before similar functionality existed > in nginx, for example, but they got to release 1st because we > were too busy standing on soapboxes or bike-shedding. There we go again. Why do you and Graham have to make this about Bill vs. yourselves? It isn't. What I've presented is data, and real world observations, conclusions and assumptions by myself and OH from other engineers and users. When your argument boils down to "but I don't see it that way" you've already lost the technical argument. Not that one or the other conclusion is more correct, but that you reject considering valid any perspective other than your own. New features have been bogged down because they keep introducing breaking changes to 2.4.x behavior. Then there is a big loop-de-loop of fitting square pegs into the round holes, and finally we have some "compatible" Frankenstein monster of a work-around. Using the word compatible very loosely here. How fast would mod_http2 happened had no crazy glue been required to fit metric bolts into english nuts? Or the ssl/md refactoring? These are things that open source projects demand to have clear revisioning. Because of this intractable position against ever shipping another version major.minor of httpd, this false narrative that no administrator or distributor would ever pick up the .next good version, that "every" contributor's time is a waste if they can't have their enhancement in the next bug fix release "right now!"; there's no incentive to do any of the hard work of solving the .last version's structural deficiencies, or to implement any of the enhancements in a legible and robust way without legacy headaches and workarounds, leaving httpd on a glide-path to eventual abandonment. In other words, your observation 2. above is a total red herring, no patches were blocked significantly longer than people took to work out the kinks, discussions of versioning never actually delayed the introduction of features (there were parallel threads, but only typical technical objections)... and proves again that you seek to stall this project, after promises to the contrary. Until we shake this notion of "2.6/3.0 considered harmful", the httpd project is effectively concluded/no more than a couple tinkerers' patch collection. > And finally, when the vast majority of web servers nowadays live > *behind* proxy servers, these type of metric surveys are meaningless. > Of course, I feel that this was nginx and MS' plan all along: they > knew how things were changing and wanted to win the "proxy server > market"... all that should be pretty obvious w/ 20/20 hindsight. The actual heavy lift isn't even httpd proxy_balancer/nginx/IIS... the real work is being done by the transparent gateway/proxies, something we don't even speak (and is realistically beyond our charter.)
