Hacker News Reader

Comment by micah_chatt | Hacker News Reader

I'm curious what impact this will have on other ASF projects, specifically Mesos. A number of the features required for a smaller or medium sized organization to actually use Mesos in production are only available in Mesosphere's DC/OS. And whenever those shortcomings are brought up, the answer is "oh well if you really need authentication beyond htpasswd, you can pay for DCOS." Like the article hinted at, I hope the ASF tries to do more to work with vendors to help OSS side of projects flourish rather than just be lip service.

View on HN

If you contributed a reasonable patch to Apache Mesos, implementing a feature like enhanced authentication, and then that patch was reject with such an excuse, that would be a problem.

But Mesosphere choosing not to contribute specific features back is their choice. The long term belief in a healthy community is that enough people will contribute patches that make the project better.

There are many, many ASF projects that are healthy.

Take HBase... A thriving community, committers and PMC members from dozens of organizations, no open source vs commercial interest collisions.

Projects backed by a single commercial entity are suspect, but can work fine as well (Kafka for example).

Disclaimer: Apache HBase committer here.

Cool, do you see HBase being used in prod? (Outside of Google that is). Who's using it?

I've seen hbase used in production at a number of startups, and worked at one where it was used. It's very powerful and flexible, but it's also not like running any other database. Setting up Cassandra is like "java cassandra.jar". Setting up HBase is...someone's job for a while is going to be "running HBase".

Anyway, I'm talking about small-ish startups that aren't super researchy technological trailblazers. There are definitely people outside of microsoft (I'm assuming that's what you meant instead of Google as Google already had BigTable and HBase started out as a Powerset project and so ended up at Microsoft) running HBase in production.

I heard Flurry has something like 2k+ nodes. Though post Yahoo acquisition, who knows what's going on.

My company does quite unfortunately; we don't really have enough data to make it necessary and it was justified w/ vague notions of scaling blah blah blah.

Facebook, Salesforce, Google (just the HBase client APIs, though), Flurry (now Yahoo), Yahoo, Apple (Siri), Pinterest, Twitter, Rocketfuel, Huawai, SiftScience, just to name some.

I work at one of the above :) where we run many, many thousand HBase servers.

There is an interesting article about HBase vs Cassandra et al here: http://www.infoworld.com/article/3066358/analytics/hbase-the...

I cannot validate or refute any of it. Hoping some here can.

Hbase is approaching a decade of age. It is well understood, rock solid, and pretty much ever error is googleable. There are numerous companies that run it in production. Hbase may not get the press Cassandra does because of it is not as easy to setup due to some external dependencies (HDFS and Zookeeper). But its very much production ready for some epic data sets.

Facebook uses HBase pretty massively.

https://code.facebook.com/posts/321111638043166/hydrabase-th...

Google doesn't use HBase. Facebook does use it for Facebook Messages I believe.

It's used pretty extensively at Adobe.

> I'm curious what impact this will have on other ASF projects

It might cause those committing the code, building the tests, and writing the doco for other ASF projects to question whether their project is being justly managed. I only watch one ASF project, Apache Groovy, and it has a similar imbalance between fluff managers and grunt workers.

Although all 9 members of its PMC are committers, only 4 of them have ever committed code since Groovy joined the ASF via its incubator 18 months ago. The other 5 (i.e. chairperson Guillaume Laforge, Jim Jagielski, Roman Shaposhnik, Konstantin Boudnik, and Andrew Bayer) are all committers but have never committed any code in that time. I can't find any other technical contributions from them either. All 5 are also ASF members, whereas only 2 of the other 4 PMC members who do grunt work are ASF members.

There's 10 other committers in Groovy, most of whom are more active contributors than those 5 I named, and in my view have far more merit to be on the PMC than them. OCI, the company doing Grails consulting, a few weeks ago enlisted an active PMC member (Paul King) as an OCI consultant "to coordinate contributions to Groovy". If Groovy's governance at ASF doesn't radically change fast to give PMC voices to the people doing the actual work instead of those ASF politicians, OCI might tap into the discontent and "take over" in similar style to DataStax, or even fork it like LibreOffice.

Sometimes members of the PMC are on the PMC to help committers do things in the Apache way - Jim (in particular) is a member of the ASF board and likely mentored the project early on (I'd go check to be certain but I'm mobile at the moment).

Because it's 18 months since Groovy joined the incubator and 12 months since it became a top-level project, it could be time Jim Jagielski and all ASF members not actually contributing to Groovy leave its PMC so that the proportion of those actually committing code and similar goes up from its present 44%. OCI is ready to pounce if they don't.

The PMC can (should) invite active members of the community - there's no fixed size, the PMC can add members at any time.

There's no need to worry about ratios of people committing code - the PMC is about guidance, not about writing code.

I believe Apache Groovy implementations should be led by their technical people, so its PMC should only have people in it who can and do code, test, and write docs. Groovy's past problems have been due to managerial sorts running things.

Do you have a personal vendetta against Groovy?

That comment is from a newly-created anonymous user responding with the word "personal" to a roll of facts and figures by someone who's real name and photo can be found by following the user link. If anyone (even someone anonymous in HN tradition) wants to challenge the facts I presented, present other relevant facts (not speculations on motives), and show how a different conclusion can be drawn, then I'll happily reply to them. I believe the Grails consultants at OCI will try and take over Apache Groovy, DataStax-style, irrespective of my own personal feelings on Groovy.

I'm a lurker and created an account. I have worked with Groovy/Grails for the past five years at multiple large corporations as well as one state entity (both employment and contract work). I was actually surprised on how many companies use it. Also, I have never heard anyone with such a negative response to it. You can take off your tinfoil hat now.

I've never worked with Grails, but used Groovy a lot from about beta-10 to v1.8, though have since moved on to other languages, even trying to bring Groovy-like ideas to those ecosystems, most latterly Go.

I'm positive about Groovy's widespread use for builds and scripts on the JVM, similar to the way Bash is used on Linux. It doesn't get used much for building actual systems, even though some of Groovy's project managers tried to repurpose it for that. I've long had concerns about Groovy's governance, and believe that's the reason for its problems, e.g. Pivotal, OCI.

Reply on news.ycombinator.com