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

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: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.

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

[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

[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: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.

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".

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.

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.