The rise of the Apache Foundation | Hacker News Reader

The rise of the Apache Foundation

infoworld.com

78 pointsjimjag58 comments

IMO large number of apache projects are in 2 categories:

1) First try out in open source. If it gets popular, develop commercial package around open version + extra/proprietary feature or support while open source version is relegated to experiment or lab evaluation in companies.

2) First offer a commercial offering. Once it is proven to be failed or non-strategic or both, donate to Apache foundation.

None of that is bad per se but it makes me feel very many apache projects are of middling quality and riding on vendor driven hype.

One of the best things about the ASF is that technical governance stops at the Project Management Committee (PMC) level. There is no steering committee sitting in judgment of your project or telling you what to do. The Board's writ extends to community oversight, but not technical oversight.

The ASF believes that emphasizing community tends to produce excellent software on average. Gating projects or otherwise interfering based on somebody's arbitrary judgment of quality would be be foreign, and would in fact impede the freedom of projects to develop according to the best judgment of the individuals actually doing the work.

Sure, I think apache is mainly about legal/project management best practices. Let the committers/contributors care about engineering quality.

I had that feeling about the Apache Foundation, but I also saw that they had a lot of projects which seemed to be important, even if most of them seemed to be heavily oriented towards large enterprise-style Java-based things, which I haven't had much use for myself. Then they took on OpenOffice, and lost what little of my respect they still had.

Background: OpenOffice used to be the go-to Microsoft Office compatible free software suite for Linux and other Unix-based systems. Then some politics happened and it forked to LibreOffice, and essentially all the developers left for LibreOffice, which is where the development happens today. However, the company still legally owning the OpenOffice code, and the name, still try their darnedest to get people to still use the rapidly-failing OpenOffice, to convince new developers that this is the same OpenOffice that they once knew, etc. (They have had a booth with staff at every FOSDEM for many years now, often conveniently located right beside the LibreOffice booth.) For the Apache Foundation to accept OpenOffice as a project in this situation is unacceptable. Predictably, the aforementioned company tries to play up the Apache Foundation connection at every opportunity, trying to imply that since it's an Apache Foundation project, it is therefore a serious and still active software project.

So much incorrect in the above I don't know where to start... what "aforementioned company" are you talking about? You imply it's a company that "own(s) the OpenOffice code, and the name", but it's the ASF that "owns these" not whatever company you seem to be implying.

I would suggest getting your facts right before posting things... it makes one look kinda foolish.

Maybe they don't own the name (i.e. trademark); it’s not very important to overall accuracy of the summary. It’s also very odd of you to ask what company it is – shouldn’t you, of all people, know? I left the name out because it’s not important what company it is.

I didn't know much about the ASF until they took in (Apache) Groovy last year, into the incubator in May and as a top-level project in November. ASF bent or broke many of their standards to accommodate Groovy...

Most Groovy links at apache.org redirect to groovy-lang.org, which is privately owned by a single individual. He also keeps his own mailing list which he claims has more subscribers than the official Groovy users list at Apache. Access to the old mailing list history was obscured and made difficult. The Groovy build system mainly runs on a separate server somewhere in Germany, with only minimal interaction with the Apache process. The Groovy brand was changed from referring to a spec to referring to their particular implementation, something which I challenge.

Based on that sample size of 1, I wouldn't be suprised if ASF bent or broke their standards to accommodate many other projects they take in.

I may seem that way, but the whois database is just plain wrong :) The ASF owns and manages groovy-lang.org.

Yep. And the fact that the CI system is donated by JetBrains is also known and allowed. No "standards" were bent nor broken. The poster simply does not know what they are talking about, making their sample size not 1 but actually 0.

It would actually be useful if some of the criticisms against the ASF were actually factual, so we could improve the ASF. But instead, they are simply fabrications or distortions.

> the whois database is just plain wrong :) The ASF owns and manages groovy-lang.org

If there's no record in whois, then it would be more useful to say since when ASF has owned groovy-lang.org, and how one can check.

> be useful if some of the criticisms against the ASF were actually factual

How would anyone know ASF owns groovy-lang.org if the public record is wrong? They didn't own it at some recent time. And which other claim is false? The fact that Apache Groovy's CI system is donated by Jetbrains is "known and allowed" doesn't make it false.

Conspicuously not mentioned: OpenOffice.

Or Apache Wave.

The important point for a report on 2015 is that OpenOffice's six-month security hole was a huge embarrassment, and it had been deliberately kept out of project reports to the board.

Jim Jagielski, who was interviewed for this article, was one of the people pushing super-hard for Apache to take OpenOffice in 2011, insisting Apache could maintain a desktop application, then having nothing to say when they utterly failed to.

And Matt Asay knows all this! And that's why its absence in a report on Apache in 2015 is conspicuous.

The success, or failure, of OpenOffice itself says little-to-nothing about the success of the ASF itself. Why OpenOffice was not as successful as hoped is a long and drawn out story, and Apache suffered from the ill-will that the OpenOffice community accumulated over the years, due to mismanagement by Oracle. By the time it was donated to the ASF, maybe it was unwise to think that those dynamics could be changed, but it was worth it to try. Even so, the donation of OpenOffice to Apache, and the subsequent relicensing of that codebase to ALv2 was a MAJOR benefit for the entire OpenOffice eco-system, especially LibreOffice which, as soon as the ASF did the relicensing, consumed those changes to their benefit. Which is one benefit of permissive licenses in general.

I would encourage people to look at the (open and public) discussions when the incubation of OpenOffice was debated; I would also encourage people to read the tons of other communications about it as it progressed. Instead of having "nothing to say", as this clueless poster suggests, there is/was a LOT to say, which WAS said, and done so in an open, public, and transparent fashion. Maybe all that is uncomfortable for people to admit, since it goes against their misleading and incorrect narrative to paint the ASF and OpenOffice so negatively, and for this reason it is good when real journalists keep the facts straight.

During the discussion of the security hole last year, you conspicuously had plenty of time to comment at length on how unfair it was for people to note Apache's utter inability to maintain a secure desktop application, as did several of Apache OpenOffice's alleged developers.

However, neither you nor they apparently had any time to fix the security hole. The fix being, literally: remove one file from the download. Well done.

The below link as well as the (public) dev@ list clearly show you to be mistaken:

https://whimsy.apache.org/board/minutes/OpenOffice.html

That's a mention from October 2015 and April 2016. The absence from board reports was brought to public attention in July 2015, and the October 2015 mention you cite is a direct response to that: https://lwn.net/Articles/650411/

Please read the thread:

http://thread.gmane.org/gmane.comp.apache.openoffice.devel/2...

That supplies the background to the LWN piece, and doesn't in any way contradict its assertions that this was a serious problem that should not have been suppressed. That public attention is why it was mentioned at all in the October report.

Your point was that discussion was suppressed. The links show clearly that it was not, and when the CVE was published (and therefore public), there was open discussion and a suggested work-around. You may not agree w/ the method used to "fix" the CVE or the speed in which 4.2.1 was released (for myself, I don't either), but your claims of suppression and stuff being "deliberately" hidden is obvious FUD.

That's literally the thread demonstrating the accuracy of my claim above that "it had been deliberately kept out of project reports to the board." That's literally the thread where they're doing that. You have literally cited something completely supporting my claim and saying "see, this cite proves you wrong!!"

That conversation took place on a publicly archived list with hundreds of subscribers. Any one of them could have escalated the issue to the Board.

My claim (as the cited conversation is the smoking gun for) is that the project excluded it from their report to the board, not that it was never reported to the board.

In any case, the board were fully aware for a long time of what a disaster the AOO project was; are you claiming they didn't know about the security ineptitude or something? What, precisely, is your claim here?

If you don't have a few failures from time to time, you're not trying hard enough. Forget who said that.

A failure, probably.

"If everything you try works, then you are not trying hard enough."

Gordon Moore, co-founder of Intel

Huh, i didn't even know that existed.

Given the way that LibreOffice has given them an epic beating are you surprised?

Wasn't really their fault. The project was abandoned way before and they just got dumped with it.

Sure it was. If the Apache foundation didn't want the responsibility then they should have said "no."

Their were real solid reasons behind accepting the donation... even though most did not pan out, just the relicensing ALONE was a major Good Thing for the OpenOffice ecosystem. This allowed for key and provable IP provenance, something that was lacking in LibreOffice, and known/trackable licensing.

Even so, bemoaning the ASF for even trying seems very disingenuous and somewhat ignorant of the facts.

The ASF doesn't take "responsibility" for projects in that sense. The individual communities do. The ASF exists mainly to provide legal/infrastructure support and to promote a certain approach - "The Apache Way".

For the ASF to accept OpenOffice as a project was absolutely The Right Thing to do, and the world is a better place for it, even if LibreOffice is more popular right now.

One of the ASF founders, Brian Behlendorf, was recently appointed E.D. at hyperledger.org (a project of the Linux Foundation). Perhaps Hyperledger is aiming to become the Apache of blockchains.

As an open source contributor and developer myself I never feel good about releasing stuff under GPL or Apache (yes, both) because they're long and some parts like the liability section kinda contradict what a liability disclaimer is about, and most importantly, it's impossible for a developer to understand it. That's why most projects initiated by developers (without a company) are MIT or ISC or a BSD variant. Also see the OpenBSD project's (which I don't use and am not affiliated with) views on the Apache 2 license. All I can understand is that both GPL and Apache licenses are that long and hard to understand for non-lawyers because they wanted to have a water-proof legal document. Which means as a developer you have to trust what others think the text means if you were to release code under it. I use the ISC license because I understand it and can explain if someone asks me about the conditions. I couldn't do the same with eith GPL or Apache. ISC/MIT with a patent clause might be useful addition for those of use who need that.

> That's why most projects initiated by developers (without a company) are MIT or ISC or a BSD variant

[Citation Needed]

A lot of Linux software of all sorts is GPL. A lot.

I said "initiated by developers", particularly with the post-Github ecosystem in mind. In Linux, obviously, there are many GPL projects, that's not a surprise. I'm talking about what license most developers choose who aren't working on the linux userland (or kernel). There are whole communities where liberal is the default license choice (Haskell, Erlang, Apache, BSDs, Golang).

Sure, there are a lot of communities out there, but before you can say "most developers", you'd have to give me some numbers.

My "anecdata" is exactly the opposite. Until a few years ago, most software I'd use or release was GPL, or bastardized versions like MPL. BSD was seen as legacy and MIT was fairly rare; APL was just used by the ASF.

Things have changed a bit, mostly because GPL is a bit messy when applied to stuff like JS libraries (Wordpress themes were probably a turning point for many). But the GPL is still massive.

I don't understand. In what way are you disagreeing with me? I didn't say there's less GPL out there. All I said is that with more open source projects popping up than in the past, and given how a random developer who understands English can also follow the BSD/MIT/ISC license text fully, how most new projects are liberally licensed, and most of the time MIT actually. GPL and Apache licenses are hard to use because you place your trust on their interpretation to lawyers, which is fine since many large projects trust it, but it's equally easy to understand how single developers or small dev teams choose, say, MIT for a new project. They don't choose the Apache license because it's a long legal document. I tried understanding it all and I failed to understand their contradictory sometimes-disclaimed-sometimes-not liability clause. Upon further inspection, I noticed that pretty much the same text is in GPL3's liability clause, so I concluded this must be something they must put in, even though as a developer to do not 100% disclaim liability as you do with MIT/BSD/ISC licenses.

I disagree because you make assumptions not backed by data and try to pass them for truth. Just because you're uneasy or not convinced by the benefits of GPL, it doesn't mean "most developers" feel the same.

Show me numbers that prove your point and I might reconsider. Until then, you're free to believe what you want and I'm free to believe you're wrong.

Again, I don't disagree with what you're saying, but you're missing my point. I am very well aware of the benefits and can imagine when I would want a copyleft license but GPL's text is not it. Neither is Apache's license text for when I want a liberal license, but I accept it for its patent clause if that's needed. Repeating myself, unless you place your trust, which is a reasonable thing to do, with those who've vetted both licenses' texts to be fine, developers go with short licenses they fully understand. That's the argument here. If there was a well-known and short copyleft license, it could be similarly popular for new projects. I'm unaware of such a license and I'm afraid you misinterpret my argument as a copyleft vs liberal debate, but I've said that both Apache2 and GPL(2,3) suffer from an unapproachable wall of text with the cited clause existing in both and having the same semi-liability-disclaimer bug.

The length of the GPL text is mostly there to specify (limit) scope, and use specific legal terms for common legal situations. GPLv3 also add sections for license compatibility, to make it easier for violators to avoid lawsuits and continue with life if they decide enter compliance with the license, and define legal terms that is understood in US law, EU law and India/Asia. If you don't need any of that, you could just write down the four freedoms and add "must use this license" at the end. It would be almost as short as MIT, but enforcement will require a lot of common sense from the courts rather then legal precedence.

I once heard a interesting idea to rewrite GPL in terms of pure permissions. It would be in theory compatible with the existing license, significant longer text, but somewhat easier to understand since it would just be a long list of explicit things which the licensee has permission to do.

I'm happy to find someone who has a deeper understanding of the issues it tries to solve by being so verbose. While you're here, do you think you can help me understand why Apache2's (and GPL(2,3))'s liability disclaimer clause effectively seems to disclaims just in part? BSD, MIT, ISC, all just disclaim any liabilities caused by the code, whereas GPL and Apache have an exception embedded in the clause, and I cannot make sense of it. Say you publish code under Apache or GPL that is then used by some uninformed who loses data and claims your tool is at fault, now claiming you to be liable as laid out in the sentence about exceptions to the rule. Why would one want that as an open source developer in code they publish but have no paid service contract of any kind in place that would cover liability claims?

From Apache2:

    unless required by applicable law (such as deliberate
    and grossly negligent acts) or agreed to in writing

This is the bit which is in no form included in BSD, MIT, ISC, and it rubs me the wrong way. I do understand that you're not above the law, but that's for courts to decide, and this bit doesn't seem to help either party (one of the contributors or the damaged license taker (aka user of the code)).

I also don't understand how the following connects to the rest of the clause but other than that I can pretty much make sense of Apache2

    even if such Contributor has been advised of the 
    possibility of such damages.

Why would the contributor be advised of damages the code he's contributing himself or contributing to might do?

I am not a lawyer, and my knowledge over disclaimer clauses is mostly from a days lecture by a legal historian professor, and he summarized it as mostly forgotten magic which is based on century old practices. For example, the practice of all caps just happens to be an example that a specific US agency gave in order to describe how to make a disclaimer "noticeable", but people just ran with it and now it just what everyone does.

I do have a guess on why Apache2 mention applicable law, which was something I read in Swedish contract law (if licenses is a contract or not is, of course, also debated between lawyers). The law mentioned specific situations in which either a clause in a contract or the contract as a whole could be declared invalid, which could happen when for example a clause is "too unfair" or when a party can be said as unaware of the clause or its consequences. My guess is thus that the Apache2 disclaimer mention applicable law as a way to dodge laws in countries which otherwise could make the whole disclaimer invalid.

As for the last question, a contributor might have sought advice from a lawyer which, as many lawyers do, gave an advice of caution. In some cases, foreknowledge about risks increases damages and risk of being sued, so my guess is that the disclaimer tries to avoid that situation.

In both cases, it seems as mostly efforts to try make the disclaimer more safe to use in a international context, where MIT and BSD is more focused on the law which govern Massachusetts and Berkeley. I personally doubt however that the differences matter much in practice, particular in the US and EU.

Black Duck's data says that GPL (2 + 3) is the most common followed by MIT followed by APL.

https://www.blackducksoftware.com/top-open-source-licenses

I've archived the link to be sure, and from what I see, MIT is first, followed by GPL2, followed by Apache. Here's the snapshot right now: http://archive.is/L4hLm (http://archive.is/L4hLm/image).

Combining versions 2 and 3 of the GPL makes it larger than MIT, at 30%.

That's one way to look at it, so if you combine MIT and Apache => 42 (add BSD and ISC => 50).

Still not "most" in the absolute terms that prompted my response. "More" could be argued, "most" implies a dominance that is simply not there. I know it sounds like I'm nitpicking, but I'm just trying to explain the point.

I didn't cite numbers because I didn't base it on any, and it was probably sloppy to use the word "most". So, if I could go back and fix the post, I would say: "most new projects I've seen in the last few years...". Thanks for pointing out my lazy wording.

I didn't check all the other licenses on that page for copyleft/liberal, but assuming it's just GPL2,GPL3,LGPL2,LGPL3, it didn't look like the absolute sum would dominate, but these statistics are necessarily precise anyway because many projects are not under a consistent single license, so...

I wasn't trying to make any particular point as opposed to just presenting some data. As a quick summary, it seemed reasonable to combine the GPL versions while keeping the other different licenses separate (even if a number of them are of the weak/no-copyleft variety). In general, a variety of published analyses have shown a general increase in non-copyleft license use vs. strong copyleft but I haven't seen such an analysis recently.

If I wanted to compare strong copyleft with no copyleft, I'd probably combine all the GPL variants (including LGPL and certainly GPL) and compare that number to, at a minimum, MIT + BSDs + Apache. That leaves out a lot of licenses in terms of absolute number but covers a pretty wide swath of projects.

https://github.com/blog/1964-open-source-license-usage-on-gi...

TL;DR:

  Rank	License	% of projects
  1	MIT	44.69%
  2	Other	15.68%
  3	GPLv2	12.96%
  4	Apache	11.19%
  5	GPLv3	8.88%
  6	BSD 3-clause	4.53%
  7	Unlicense	1.87%
  8	BSD 2-clause	1.70%
  9	LGPLv3	1.30%
  10	AGPLv3	1.05%

To be clear, the ALv2 is characterized as a "BSD variant"... It is also extremely popular and well known and understood.

Yes, as is GPL(2,3), but your normal software developer doesn't understand either fully as they do BSD, MIT, ISC.

EDIT: the "as is" part is in the context of "understood".

I would not call GPL2/3 as a BSD variant in any way... BSD is permissive; GPL2/3 are strong copyleft. Unless you have a VERY lax definition of "variant" grin

EDIT: Thx for the clarification!

I didn't say that, but I can see how you'd interpret it this way, if you consider the parent comment.

"as is" was referring to "understood".

Sorry for the missing context.

>> That's why most projects initiated by developers (without a company) are MIT or ISC or a BSD variant

Even with companies this is true sometimes. Microsoft went through a bunch of licenses for its own open source stuff, starting with its own Ms-*, then using Apache for a bunch of projects. And now if you look at all new projects (.NET Core etc), they're all MIT.

I'm definitely stuck in the paradox of choice.

Also, some advice on how to make money doing OSS is to dual license it (eg copyleft for most users & copyright for commercial licensees). So now there's two decisions.

Reply on news.ycombinator.com