Apache Comes With Too Much Community Overhead?

drizzle writes "There's an interesting story on the Apache Marketing blog about whether or not Apache projects come with too much overhead, especially compared with other services or a roll-your-own approach. The article states, 'It's true that compared with SourceForge, Apache has a more rigorous management structure. The ASF has formalized processes and procedures that we believe represent best practices governance. All new projects must pass through an incubation period to ensure that all of the project's members have internalized these processes. However, each project's leadership has a tremendous amount of discretion in managing within this framework.' There is also a follow up article written by one of the httpd developers about 'What Apache brings to the table.' The article cites community, experience, legal framework, diversity, brand strength, and networking as reasons why developers and companies should consider bringing their projects over to Apache."

Comments

Tell me about it

[Anonymous Coward]

I just setup an Apache web server for use at home, and now I've got 4 Apache developers living in my basement. When they showed up, they said they were my Apache community overhead and I had to let them stay there. Oh, and I apparently have to feed them too!

Re:Tell me about it

[bhalter80]

Mine said food was optional but Bawls was not

Re:Tell me about it

[LiquidCoooled]

That's nothing, I installed Linux and now I've got a colony of penguins living in my freezer.

I'm dreading the upgrade to BSD.

Re:Tell me about it

[Anonymous Coward]

Man, whoever marked this "over rated" is far too uptight. what a fag.

Re:Tell me about it

[geminidomino]

I'm dreading the upgrade to BSD.

Don't Be

Re:Tell me about it

[Anonymous Coward]

That chick has as much to do with BSD as the movie March of the Penguins was about Linux.

Nice try though.

Re:Tell me about it

[emgeemg]

...and I couldn't care less. =)

They must be doing something wrong

[winkydink]

After all, it's not like they created one of the most popular open source apps of all time or anything like that.

Re:They must be doing something wrong

[fermion]

By this logic, MS makes the best microcomputer operating system in the world, and we all jsut better start using it.

There is always room for self reflection and improvement.

Re:They must be doing something wrong

[mithras the prophet]

No, I think the analogous observation is that Microsoft must be doing something right, because they've created the most popular operating system software (and probably software, period) ever. Which is true: they are doing something right. That something might be nefarious business practices and ruthless leveraging of a monopoly, but they're obviously doing a good job of it.

BSDs?

[RT Alec]

How about the "overhead" of the various BSDs? FreeBSD, OpenBSD, and NetBSD all have what could be described as "too much overhead" in their development model. Yet all three are considered among the shining stars of FOSS operating systems. Stable, robust, and "you know what you're getting".

BTW- Apache is developed primarily on FreeBSD.

Re:BSDs?

[slavemowgli]

It may be just me, but I think you're reading too much into a Netcraft report here. Outside of the fact that FreeBSD and Linux seem to be about equally present here, the platform on which the projects's *website* is hosted doesn't say anything about the platform the project itself is developed on.

Case in point: openbsd.org is hosted on Solaris. Does that mean that OpenBSD is primarily developed on Solaris? Of course not. And the same thing goes for Apache, too. It's still possible that Apache is primarily developed on FreeBSD, of course, but a Netcraft report doesn't say anything about whether it is.

Re:BSDs?

[RT Alec]

According to Apache's web site, quite a bit of Apache is actualy developed on FreeBSD servers. As far as the individual developers go, I believe Brian Behlendorf makes a good representative of senior Apache developers.

Uh, what?

[Anonymous Coward]

You want to do a project? Okay, well nobody is forcing you to work with Apache. The Apache community keeps consistently turning out good products. This tells me they're doing something right.

Yeah, so with sourceforge you don't have to spend as much time on organizational matters. And also on sourceforge 98% of the projects are stalled out in the planning stage. I don't see an improvement there.

Re:Uh, what?

[Anonymous Coward]

I was considering contributing to the Geronimo project. I signed up. Before I saw a single line of code - I had more than 1000 mails in my inbox, emails that were dealing with purely administrative detail and discussions on organisational matters. I grew so fed up with it that my interest drifted elsewhere.
Admin overhead? you betcha!

configuring apache #1 complaint, still unaddressed

[SuperBanana]

There is also a follow up article written by one of the httpd developers about 'What Apache brings to the table.' The article cites community, experience, legal framework, diversity, brand strength, and networking as reasons why developers and companies should consider bringing their projects over to Apache."

Two words why you shouldn't use Apache unless you absolutely need to (and most apache users don't NEED apache): configuration complexity.

Apache's configuration file hasn't changed dramatically since the days of v1.3, and it's still an absolute train wreck. It is seconded in nightmarish complexity and eccentricities by Sendmail- and barely at that. See the old slashdot story Why I hate The Apache Webserver.

I have an idea. Let's see replies here, suggesting Apache alternatives that are a)lightweight b)easy to configure c)open source with BSD or GPL (or similar) licensing. Why? IMHO, the Apache group has gotten a little too comfy with their market dominance and years of blind faith from unix users. Sounds like it's time to remind them that especially if you're already on an open-source platform, you have a lot of choices.

Let's see lots of people trying out different webservers, helping improve them if they come across problems, and helping integrate these different webservers into distributions better, and so on. (That debian package for "joeserve" out of date? Help update it! Init scripts a mess? Spend 15 minutes coding up some improvements and email in a diff to the maintainer. Etc.)

Re:configuring apache #1 complaint, still unaddres

[greenpenguin]

I'm inclined to agree, much as I like Apache. It is not very nice to set up, especially if you want to do something odd.

Dunno ..

[RedLaggedTeut]

I have this feeling that most of the stuff that you complain is hard to configure with Apache, that you couldn't do this with the lightweight stuff at all.

For simple stuff, what is so difficult about setting a port and a base directory?

Re:Dunno ..

[The Spoonman]

How about the simple fact that unless you read, memorize and completely digest the entirety of the Apache documentation, there's no way to know exactly what the bare minimum is necessary in an httpd.conf to just serve static webpages on a particular port. Is a "MaxKeepAliveRequests" an absolute essential? "StartServers"? Which modules? Is dir_module an absolute minimum requirement?

"Oh, but httpd comes with a default configuration file", you say? The default configuration file is almost 1100 lines long! If you remove all of the comments (none of which say "you MUST have this line for Apache to work"), it's still over 300 lines long. Hardly a simple configuration. Are these important questions? For a server that's facing the Internet, it would be nice if I could follow the best practice of "minimum necessary", but Apache doesn't give that as an option. I finally had to figure it out by starting with a conf file that just had a "ServerRoot" directive and kept adding to it until the damn thing finally started and served pages. And, FORGET asking the Apache community for help. Their default answer to any question is "did you RTFM"? To which I respond: "Why not narrow it down to one or two of the 600 pages for a brother?"

Oh, and my config file after I got it down to barest? 15 lines.

Re:Dunno ..

[fimbulvetr]

fimbulvetr@media:/etc/apache2$ grep MaxKeepAliveRequests apache2.conf
# MaxKeepAliveRequests: The maximum number of requests to allow
MaxKeepAliveRequests 100
fimbulvetr@media:/etc/apache2$ grep StartServers apache2.conf
# StartServers ......... number of server processes to start
StartServers 5

Seems that they're documented enough to figure out a barebones configuration. I realize you're pointing out it's complexity and these examples are nothing but trees in the forest, and there are plenty more, but the point is that they _are_ documented. Apache is an extremely powerful and flexible webserver. For light servers, it's easy to get it up and running right away (by keeping the defaults) - and the reverse is true - it takes very little work to get a default httpd.conf to run in a highload environment (assuming you're running in a pretty standard one).

Now, if you need a super custom setup - it's not such a huge leap for the developers (and even the guy at apache who is the boss of what gets put in the default conf) to presume that the person needing it in a custom environment knows apache pretty well and knows what they need to use in the configuration file.

Finally, I do think it is reasonable to say that people who setup a website should take the responsibility of knowing, at least the basics, of running websites. Even if this means gathering more than a cursory understanding of the workings of apache or any other webserver, it is certainly going to be more beneficial for them than sitting around bitching about the complexities he doesn't want to learn.

Re:configuring apache #1 complaint, still unaddres

[Doppler00]

Why don't they just make the configuration file XML, release the specs, and someone comes out with a GUI configuration editor. Problem solved.

Re:configuring apache #1 complaint, still unaddres

[david.given]

If you want simple, static content, thttpd is stupidly tiny, stupidly scalable, and way faster than Apache. Unfortunately it uses the old fork model for dealing with CGI scripts which make it quite slow as doing that (but no worse than the old NCSA httpd). It has a number of interesting features, such as per-filetype bandwidth throttling (so you can specify that MP3 files only get transferred at 10kB/sec), but also has some suprising omissions --- the MIME type database is hard-coded, and it only handles HTTP 1.1. But if you have a simple site based mainly around static pages, thttpd is probably ideal for your purposes.

Configuration complexity

[Elrac]

Yes, Apache (Web server) is somewhat hard to configure. There's a large file with a lot of (documented) features and settings, and a lot of ways to go wrong there.

On the other hand, Apache is incredibly flexible: You can use it as a proxy, it does ssl, it fronts for Java Web servers, it rewrites URLs, it authenticates, it slices, it dices and I'm probably just scratching the surface.

Someone who knows his way around the config file - and that's really the only crucial thing to know about Apache - is able to get it to sing and dance. The header in the file warns people to read in-depth documentation rather than relying on comments in the file. There is documentation, there are books. If you're going to play at being a 'professional' Web admin, then you need some of this stuff.

For the less seriously inclined Web maker, programs like Webmin let you fiddle with a subset of Apache settings through a HTML front end. On an even broader front, many Web site hosters provide a dumbed-down interface that allows only a small subset of configuration options and keeps the user from doing anything really stupid.

And for anyone not covered above, yes, I'd recommend getting a simpler Web server. Personally, I find Tomcat a little easier to configure than Apache, but that's just me. I'm sure there are dramatically simpler products. Hell, lots of people have written their own!

The discussion in this topic is not about the complexity of using the Apache Web server, but the complexity of managing an Apache project. I'm not sure if I'd be perfectly happy "doing" an OS project under Apache, but... that's what choice is about, right?

Re:Configuration complexity

[fimbulvetr]

Just one link, but it should speak for itself:

http://archives.neohapsis.com/archives/fulldisclos ure/2004-06/1004.html

KBB, by choosing to run IIS, infected every web visitor of theirs one fateful day. Do you want to be _that_ guy?

Re:Configuration complexity

[zerocool^]

On the other hand, Apache is incredibly flexible: You can use it as a proxy, it does ssl, it fronts for Java Web servers, it rewrites URLs, it authenticates, it slices, it dices and I'm probably just scratching the surface.

You're exactly right, and your parent poster is exactly wrong. Attention, Please, Everyone:

EASE OF USE DOES NOT INDICATE A BETTER PRODUCT.

Apache is incredibly powerful. There's a reason it's the most popular webserver in use today, by far. And, with most linux distros, it's relatively easy to configure given the default configuration file.

The grandparent poster seems to suffer from the "I can't figure out how to do it in 5 minutes, therefore it's too hard" syndrome. Well, guess what? Work harder, or find a webserver that's easier to configure. For starters, there are any number of graphical (and ironically, web based) configuration utilities for apache. See ApacheGUI, Apacheconf, and Webmin. Aside from that, if the big bad config file scares you, maybe IIS is for you - you know, checkboxes and dropdown menus and insecurities.

But, seriously, the ratio of (Size and complexity of apache config file) to (complexity of the program) is very reasonable. I worked at a linux / solaris based webhosting company for almost 3 years. It took me about 2 or 3 months before I was completely comfortable working with almost all facets of httpd.conf. I understood the general idea in about a week, and there are still some parts that I'm fuzzy on, or don't get, or would need to google, but a couple of years ago, I could have almost written a config file by hand. They're seriously not that long, if you take out the commented sections (which are, of course, there to hold your hand). By contrast, I only scratched the surface of the sendmail config file.

Basically, my post boils down to: You can understand the basics of the apache webserver in an hour with a tutorial, google, and a test box to play with. Most of the time, the default options will work for you. There is almost no end to the amount of apache documentation available for you. And there's no need to understand the intensely complex aspects of the webserver outside of specific instances. For basic usage (as with most programs), stick close to the defaults, and google for answers to any questions you have.

Just because You, grandparent-poster, can't understand the apache config file in 5 minutes doesn't mean that the whole project should be scrapped. Every part of the config file serves a purpose. Any new project you create will need to have all the variables in the current project defined, or it will be less capable than apache. Please, take the time to learn what you're doing, and come up with real problems that need real solutions.

Just as an aside: vi versus Notepad.exe - Which is better?
vi is more cryptic, by far.
vi takes longer to learn
vi doesn't look as nice
Notepad is very easy to use
Notepad is graphical

However, once you take the time to learn vi, you'll see that it's difficulty in learning, once surmounted, leads to a much more powerful, capable text editor.

~Will

Re:Configuration complexity

[Jason Earl]

IIS just seems like it does as much because the administration tools for it are so complicated. If there's one beautiful thing about apache it is that if you get a solid configuration you can simply scp it to the next machine and you are golden. However, comparing the functionality built into IIS to Apache's built in functionality is just ridiculous. I haven't used the newer versions of IIS, but I am pretty sure that they can't be configured as a proxy server, and I am positive that they don't have Apache's powerful URL rewriting ability. You also can easily setup up Apache to authenticate against all sorts of data sources from plain text files, to Active directory, to databases like PostgreSQL or MySQL. I am sure that the real Apache gurus could make a very long list of the features that Apache has that IIS doesn't have.

Re:Configuration complexity

[loom_weaver]

The original poster does have a point. A very powerful piece of software can still be easy to configure and not lose its power.

One way to do this is to have 3 different levels of configuration. Novice that exposes only a few options, medium, and finally advanced which gives you the entire gamut.

If 75% of the people just want to get something up and running then tailor the configuration to show them only the options those people will need. If an administrator needs more power then they can go into more advanced modes.

Configuring firewalls is an especially notorious. Many users want to just protect a single machine. Some want to protect a full blown network with NAT/DMZ/etc.

Likewise with httpd.conf. One person just want to set it up to test some web page development. Others want virtual domains and proxies.

Showing everything at once is overwhelming and often unnecessary.

Re:Configuration complexity

[Nazadus]

You are correct in many ways, however the usefullness of a product is *entirely* on the documentation *if* it's a complex project.

Example 1: Microsoft Windows API isn't documented well. Does this mean it sucks? No. I've seen some *really* cool stuff out there.

Example 2: Apache is flexible and has allot of documentation. Does this mean Apache is good? No. Their documentation is too complex. But this doesn't mean Apache sucks. It just means that using the more complex parts of it gets difficult.

Example 3: PHP is documented well and is flexible. Does this mean it's good? Heck yeah. You can even leave comments if it forgets something or you think something should be clarified better.

Just some things to think about.
Recently I've been working on a guide for getting OpenBSD with Apache/LDAP/PHP/a bunch of common stuff. It's been very tough due to lack of documentation. Especially LDAP, fucking A that's been tough. I even have three books and barely know where I'm going. I feel like a baby... naked.. or something.

The leap to just too difficult sometimes, and this can (and sometimes should) discourage people from using it as a real solution. If a boss finds out you've spent 4 days trying to learn *insert feature of the week here*, he's going to be pissed. The key is _good_ documentation. Good documentation is tough to write though...

I've only gotten Sendmail working once (on Slackware 9.1). After that I went Postfix becuase it was easier and felt beter documented. At the time I was a serious noob at the internet thing (as far as getting services running) so I should probably go back and see if anything has changed or if I'm just better than before?

Re:configuring apache #1 complaint, still unaddres

[Vario]

Or if you want something smaller than Apache and a little more than just static pages try http://www.lighttpd.net/. It is secure and beats Apache 2 performance wise and the configuration takes only a few minutes. It runs on my small server for months now and is certainly worth a look.

Everyone missed the boat...

[}InFuZeD{]

Out of curiousity, did any of the above posters actually read the article? Or even the Slashdot post?

This isn't about Apache's Web Server at all. It's about the Apache foundation, and running projects with them. Apache's web server is just an example of a project that is run under the Apache Foundation... and any bloat / hard configuration in httpd has little to do with Apache Foundation's "overhead".

Article is not about the httpd server

[LFS.Morpheus]

First, If you actually read through the blurb (not even the article) you'd see that they're not talking about web servers - they're talking about Apache, the organization behind the web server.

Second, I would recommend the up-and-coming lighttpd, which I have used for both static and dynamic content. I have never used thttpd so I am not sure how it compares on the static end.

Re:Comparison chart

[owsla]

That comparison chart was last updated in 1998. It's woefully out of date.

Mod parent down.

Re:configuring apache #1 complaint, still unaddres

[fimbulvetr]

You have to be kidding me? XML? Are you out of your mind? Apparently you've drank the XML koolaid and you're parroting it's usefulness for everything but ending world hunger. Almost every OSS project I use relies on the ease and simplicity of text configuration files. Of the few XML configuration files I've ever used, I've been left with a disgustingly horrible taste in my mouth afterwords.

Some of use don't want some GUI to do our configurations, and we certainly don't want to be at the mercy of one. When the GUI breaks or doesn't work (It's KDE only, it's gnome only, Xorg isn't installed, one doesn't exist yet, the ones available don't support these new options yet, ad infinium), we don't want to have to construct super perl scripts with XML capabilities to do mass changes in configuration files. Some of you might be fine with your tomcat's server.xml file being 1500 lines and the accompanying bloat, but I for one choose less complexity, even if the only advantage is controlling configurations more efficiently.

Tough Call.

[Anonymous Coward]

I'm not going to bash the Apache Foundation or Apache Developers, or even Apache itself. It's all good work, and lots of it, while I sit around doing SFA...so who am I to bitch?

However I believe that any bloat, be it at the Foundation, or developers, development, or Apache is all part-and-parcel of the Kitchen Sink mentality of computing.

I was going to blame the Linux community's Kitchen Sink mentality, but then I remembered Microsoft and their products (and just about everybody else) and realised that it's a computing thing, not platform specific.

Ever asked somebody to do an install for you, either because you don't have time, or it's new to you, or whatever? They will always install every last little thing, "Because you may need it someday".

I'm a minimalist when it comes to systems, and I mean minimalist: unless the system won't function without something, it's not installed. Yet I have never met anybody else with the same approach.

Humans and bloat go together I guess.

But what have they done recently?

[penguin-collective]

Yes, Apache 1.x is enormously popular. But that's not where the work in the Apache project has gone recently; recently, they have been working on Apache 2.x, XML-related projects, and lots of other projects. Are you using any of those more recent projects? How much impact have those projects actually had? And is the amount of effort that has gone into them justified by their impact?

Re:But what have they done recently?

[winkydink]

Actually, yes. I am part of the Spamassassin development effort.

Re:Don't bet your business on OSS

[penguin-collective]

You are making your company dependent on the GOOD WILL of others.

Quite to the contrary: with OSS, you are not dependent on anybody.

The real thing you should worry about is that with closed source software, you are at the mercy of your vendor.

However it all functions perfectly under Windows and Mac OSX.

I'm typing this from a Mac OS X laptop--which I just had to reinstall because it was dying with a kernel panic during boot. Before that, it failed to read the xD cards from my new consumer digital camera. And among many problems, file associations are inconsistent under OS X, the green resize window button is unintuitive, and the Finder views switch haphazardly. The point is that even the best desktop operating systems have problems--Linux, OS X, and Windows are comparable in that respect. If you claim otherwise, you're simply trolling.

vs. the Red Hat girl

[matt me]

Ok, whilst on free OS logo fetishes.

The Red Hat model.
http://www.madyiordache.com/TheRedHat.htm

Re:configuring apache #1 complaint, still unaddres

[mcrbids]

IMHO, the Apache group has gotten a little too comfy with their market dominance and years of blind faith from unix users. Sounds like it's time to remind them that especially if you're already on an open-source platform, you have a lot of choices.

Yeah, they need a message. Look at that beautiful graph now - Apache's hit 70% this month!

Obviously, they're hitting that percentage because, like, people don't have a choice in the matter. It must be dirty pool playing on the part of the ASF... right?

I find the Apache config file fairly easy to set up. It works reliably and without complaint every day, with now just shy of 5 years of perfect uptime...

Of course, you might consider this option... Pick your poison.

Seriously, other than httpd

[smittyoneeach]

...I thought apache.org was primarily about Java projects.
I won't go into a troll about how challenging it was, trying to set up Tomcat to work with a database.
Poring over the source code, what I gathered was that they were using XML files and the admittedly interesting reflection features of the JVM to more or less script the JVM and quite a bit of the app server, especially the security stuff.
The documentation was less than illuminating, and the source code little help. So I took a failing grade in the software engineering class, quit school, and got on with life.
Anyway, a survey of apache.org would reveal an overwhelming Java bias in their projects, no?

There's a problem?

[lseltzer]

I'd think at least twice before criticizing Apache's basic structure. There aren't many open source projects that are as successful as Apache and dominate their space as thoroughly.

Re:configuring apache #1 complaint, still unaddres

[Excelsior]

You have to be kidding me? XML? Are you out of your mind? Apparently you've drank the XML koolaid and you're parroting it's usefulness for everything but ending world hunger.

He's not out of his mind, and you aren't proving your own sanity by being rude. There's nothing wrong with XML for configuration files, and plenty to gain. If you have config in XML, developers can write config integration or front-ends in any language that has an XML parser. PHP, Java, Perl, Javascript, Python, Mono/.NET, etc., etc. With normal text config files, you have to do ugly string manipulation, and you have no way to adjust from version to version without custom hacking for every setting in the config. This is why front-ends rarely exist for most text config files, and why front-ends do exist for many XML config files.

Further, with XML the configuration option and it's set value can be validated. Right now, we don't know if any setting in a text configuration is actually doing something or doing what we want. From version to version settings change, go away, gain new options, etc., and we have no way of knowing if our setting is valid until we view documentation - and even then we have to hope the documentation is up to date.

Some of use don't want some GUI to do our configurations, and we certainly don't want to be at the mercy of one.

No one is forcing you to use a GUI front-end for XML config files. But thanks for thinking that you are the center of the universe, and all those who want a front-end be damned.

When the GUI breaks or doesn't work (It's KDE only, it's gnome only, Xorg isn't installed, one doesn't exist yet, the ones available don't support these new options yet, ad infinium), we don't want to have to construct super perl scripts with XML capabilities to do mass changes in configuration files.

Editing an XML config file in a text editor isn't harder than a non-XML config file. The same "stuff" is there. Yes, it has tags around it that take up space, but big deal.

Roller Weblogger's Transition to Apache

[GuruThrill]

I've been monitoring Roller's transition through Apache's incubator process. You can get a glimpse of all the legal licensing issues a project has to go through to become compliant. Definitely an interesting read:

http://mail-archives.apache.org/mod_mbox/incubator -roller-dev/200511.mbox/thread

mod_jk

[Anonymous Coward]

They don't seem to apply their rigorous procedures to mod_jk, the plugin that JBoss.org has taken over development of. The quality of numerous releases over the past year has been very disappointing. The 1.2.15 release looks decent, but its predecessors were very buggy to the point of being what I'd consider beta software not ready for running in the enterprise environment.

Re:Apache has a lot of XML, SOA projects

[Florian Weimer]

Actually, Java projects are a minority of the Apache projects, [...] Apache recently has gotten a lot of new committers in XML and web services development. Like with Axis2 and Synapse. They also have a project called Maven, [...]

Axis2, Synapse and Maven are Java projects.