X

Marc Fleury to Apache: Get relevant

Do we really need all the Apache projects? No. But then, do we really need most of the open-source development we get?

Matt Asay Contributing Writer
Matt Asay is a veteran technology columnist who has written for CNET, ReadWrite, and other tech media. Asay has also held a variety of executive roles with leading mobile and big data software companies.
Matt Asay
3 min read

I see Apache doing great work all over the place, but Marc Fleury sees things differently, perhaps because the projects his old JBoss team competes with (like Geronimo) have been lackluster competitors. Marc takes a swipe at community cheerleaders and those that suggest he should do more to support Apache.

At the heart of Marc's Apache complaint is a belief that code is king in open source, not the ill-defined "community" around that code:

[At JBoss] we paid for coders; not politicians, or should I call them Aparachiks. The idea of funding somebody like Geir Magnusson, who as far as I can tell, has never written a line of code, but runs around contributing "community spirit" offends my sensibilities. Even if it didn't, I would still decline the offer. My Red Hat contract prohibits me from contributing to projects that compete with JBoss. Do I need to remind Jim that Geronimo competes with JBoss, albeit not very successfully. Should I be grateful for Geronimo?

It is interesting how many people online purport to speak for the "Community," almost as many as purport to speak for God. I find myself asking: how do they know? The open source "Community" is by definition diverse. It includes students, consultants, industry employees, volunteers, professionals, shills for IBM, hobbyists, fanatics, cynics, superheros, and the silent online majority who never show up in Google quotients. There is a certain presumptiousness in speaking in the name of The Community. Speak for yourself, not for me, not for the community. I am part of the community.

If Apache wants to remain relevant these days, it needs to lower the proverbial ratio of chiefs to Indians. It also needs to get rid of the last remnants of its historical hostility to Java and seriously ask itself what is so compelling about the BSD license to justify replicating already successful OSS projects like JBoss or, more recently, the Java VM.

Again, I'm generally happy with the Apache Software Foundation, and think that it does great work. I do tend to agree with Marc, however, in that Apache tends to replicate a lot of code/projects that have been better done elsewhere. But then, I'd probably offer this same criticism of JBoss, which historically (though less so now under Red Hat's cost/benefit analysis) thought it had to reinvent every wheel, from ESBs to portals to...you name it.

It's not that JBoss did these poorly - in many instances, it did/does them exceptionally well. It's just that JBoss didn't need to build a content management system (which it apparently strongly considered writing). It's probably better off adopting a leading ESB than write its own. Etc.

But back to Apache. And "community." Across the board, I think the open-source world could do better at contributing to existing projects rather than reinventing "new" ones. Sometimes the community involved in a project is not conducive to building on top of it. Sometimes the project is rock-solid but is reluctant to take outside contributions (I know a range of developers who have attempted to contribute code back to Lucene, Spring, and other projects and have gotten nowhere), but it's better to keep using it, anyway.

And yes, sometimes it's better to start anew. But do we really need scores of Linux variants? Of databases? Of content management systems? Of IT management tools? Etc.?

No, we don't. It's one of the great strengths and singular failures of open source that we really aren't any better at creating communal code, when viewed in the aggregate of all open-source development. We're not worse at it than proprietary software, but I do think we'd be better off with more open-source activity focused on fewer projects.