Apache offers stewardship for projects of a certain size. That is they have to be big enough to accept the overhead of having for example a vice president of the project.
Big companies create big projects.
Big companies create projects written in Java.
Big companies wants a steward for their projects to welcome outside contributors.
Project - Company - Commercial Product
Geronimo - IBM - Websphere (parts)
JackRabbit - Adobe - Adobe AEM
Felix - Adobe - Adobe AEM
Apache CXF, Apache Camel - Red hat - Fuse
Apache Sling, Adobe, Adobe AEM
For a while, I was part of one small non-Java bit of the ASF: https://tcl.apache.org/rivet/ but I haven't been active for a few years, and indeed, as of last weekend, decided to resign from active membership in the ASF and 'go emeritus'.
It's a good group doing good work.
Apache has a pretty good framework for "crossing the t's and dotting the i's" in legal terms for code contributions, so that big companies know that all the code is accounted for and there are no nasty legal surprises lurking - in theory.
(p.s. Try "it's")
My point was not that big companies don't use languages other than Java. My point was that the tired cliche of Java dominating at big companies is entirely warranted. If I implied that Java penetration at large enterprises is 100%, then there is a lot more wrong with my writing than a missing apostrophe.
Can you elaborate on these?
Accumulo, Ambari, Avro, Cassandra, CouchDB, Falcon, Flume, Hadoop, HBase, Hive, Kafka, Knox, Oozie, Phoenix, Pig, Samza, Spark, Sqoop, Storm, Tez, Zookeeper.
I can imagine many database companies in particular Oracle and Teradata wishing Apache wasn't as fantastically competent as they are.
I think the simple answer is that while lots of people do not love programming in Java, it can be attractive for projects that want relatively good performance without trying to implement a system in C++. There are also a lot of tools and companies that have investments in deploying JVM applications.
At my last company, our main method of IPC was sending Avro messages over AMQP (using Apache Qpid). It was the best IPC I've worked with.
I think you mean WebSphere Application Server Community Edition which has nothing to do with WebSphere Application Server (what is commonly known as Websphere). Quite frankly I don't understand why Apache didn't kill off Geronimo over half a decade ago (other than IBM $$$): it is essentially dead, has no users and only IBM committers. But at least it will end soon, IBM as already announced that they will kill WASCE in favor of Liberty Profile.
> Apache CXF, Apache Camel - Red hat - Fuse
CXF is also the basis for the EAP SOAP stack. I don't know how "big" Fuse is compared to EAP.
> Felix - Adobe - Adobe AEM
Not so sure here. It goes back to Oscar from ObjectWeb. While it is certainly used by Adobe AEM it's also used by several other products even Eclipse Equinox these days.
It seems that Adobe has a product built on that, AEM, and , afaik, employs at least one of the main committers of the Felix project.
The Java/C(++)? divide also seems to correlate with "commercial-friendly" (Hadoop, Lucene) versus "developer-friendly" (Blender, Linux) software.
Apache is not a company, it's a foundation, non profit style, founded around the Apache Web Server at first but adding lots of project under the Apache licence. Some where donated to it by commercial companies, others started there.
One of the major sub-projects of the Apache Foundation was a Java based server, called Tomcat, started when Java and Servlets were all the rage, more than a decade ago (1999-2000). It was based on code donated by SUN, and grew very popular fast.
From that, and under the "Jakarta" umbrella, it grew lots of other Java related projects, and this attracted new Java projects in turn.
I think also there is a kind of pragmatism involved. For instance, even though OpenJDK is now Open source, people like Richard Stallman think Java is an oppressive island, so Java people are less likely to be part of the GNU world.
I was surprised to hear this claim, so I looked into it. The only thing it's turning up in this vein is the description of it being "shackled", or comparable adjectives, all before the JDK was GPLed a decade ago. Do you have a specific source on this?
* Initial projects started in Java by various contributors
* Large open community of Java which contributes back
* Wide acceptance of Java being cross-platform
* Today Apache is the de-facto home for any donated code from a corporate
Java-centric relative to C#?
Possibly because a less FOSS friendly vibe among C#ers previously.
Possibly because the relative stagnation language-feature-wise of Java fostered a culture of frameworks and libraries.
Many users of the language Java have trouble understanding the complications of proxies, generics and reflection. Unless one is well-versed in these technologies, one might be tempted to blame the type-checker.
Frameworks such as Spring or Hibernate, perturb the purity of the type-system. This creates complexity in larger projects, and again the users would blame the language, instead of the framework.
There are many valid complaints on Java's type system, such as its verbosity or type inference. Scala seems to solve the most pressing issues with these.
I'd say Objective-C's type-system is much less powerful.
The point that Spring and Hibernate undermine the type system is valid, but why do they undermine the type system? Because it's inadequate for cleanly expressing as common a problem as ORM. If you need to resort to dependency injection and more-or-less invisible abstraction layers to write readable code, your type system has failed you.
Consider by contrast the ActiveRecord model from Rails. It's exquisitely simple and understandable, and does an enormous amount of work for you in very little code, while frankly being no more problematic or dangerous than Spring and Hibernate. Of course, this is in large part due to Ruby metaprogramming power that springs from dynamic typing, but I don't think that means dynamic typing is superior. Clearly, it's not protecting you from a lot of basic problems that a static type check can catch.
So how do you get a type system that provides the benefits of static typing, without getting in the way of clean code and leading to ugly workarounds? How do you make strong typing help rather than hurt on the small scale as well as the large?
I don't know yet, because I'm no expert on more modern languages. But Java isn't managing it.
The Java type system is quite old. It's doing some interesting new things anyway like the pluggable type systems via the Checker framework, but nobody is going to claim Java has a cooler type system than Haskell.
If you look at Kotlin, it makes some small but much needed upgrades to the Java type system, like real properties, traits, delegates, function types, integrated nullability and flow sensitive typing, better generics etc. It doesn't go as far as Haskell though.
Talking about ActiveRecord: I've come to understand this system has been the focal-point of insecurity by design issues (http://railspikes.com/2008/9/22/is-your-rails-application-sa...)
To answer your question, I'd strongly suggest to have a look at Scala. It's clean code, easy to read, fast and as expressive as ActiveRecord (plus the type-safety).
Also some Apache Java libraries (several of which are used in Android)
Some of them are a bit odd:
Others have really, really buzzwordy descriptions:
Does it have its own subdomain on apache.org? Then it's a top-level project.
It's not uncommon for projects to start as subprojects and then get upgraded to the top level, and some of them came out of Hadoop. For example, Avro started out as a Hadoop subproject before becoming its own top-level project.