Hacker News Reader

> That's essentially my problem with the open source.

And that's my problem with the moniker 'open source' - it gives people the wrong idea. Free software is all about freedom, and surprisingly that often turns out to be easier to explain than the nebulous appellation 'open'.

Amusingly, each of your five dot points applies entirely to non-free software (behind non-free software there's a commercial entity, their products often end up getting designed by committee and are the worse for it, projects die as soon as they (product or company) cease being commercially viable, competition is discouraging and leads to similar but worse in slightly different ways products, and people contributing via bug reports or plugins or code contributions or blogs on how to use the product are doing it 'for free').

You said behind every popular open source project there's a big company -- what would that be for the Linux kernel, Apache, KDE, Python, VLC, gimp?

Btw, don't tell Hashicorp that it's pointless trying to write a better orchestrator than K8s. : )

Maybe the moniker should have been something like Libre Source or Liberty Source?

Or English lacks a nice sounding word for the meaning we want to convey. Branding is hard.

I don't think "open source" needs to apologize for anything. Making profit from it wasn't ever the goal for most projects. That you cannot derive profit from it may have to do with your business model.

You could offer support for the product you are offering or maybe you can just write proprietary software. To think that there is a problem with open source as a concept sound like a pretty alien conclusion to be honest.

Most open source projects don't have corporate backing obviously. The large ones that are heavily in use? Sure, because their developers use it too.

> Open source projects end up to be designed by committee [..]

I can agree on that point, but again, that is a minority of project that have become very successful.

> En-masse community memebers get nothing from contrubuting to project

That is the point of any free contribution. I know that can get exhausting and that there are ungrateful users that can ruin it for you, but I still don't see how open source is the problem and not your disposition to it.

I think the article overall is not convincing. Maybe our expectations are too high, but whose aren't in todays software world. Without open source it just isn't possible to let developers teach themselves as efficient as they can do now. That these costs are externalized by companies and that they might not give back enough is the nature of voluntary work. But it certainly not undercutting some imagined market.

The problem with open source is not that the source is available, that you can modify it to your own needs, or that you can contribute back, it is that anyone can redistribute your software for free, and that you can't discriminate between e.g. small businesses or personal use and Google in your license terms. This cuts off the possibility of actually supporting yourself financially as an open source developer in many cases and is an ideological commitment that mostly benefits large corporations at the expense of individual developers.

Then someone can dual license the code. Something like AGPL for general development and commercial licenses via request. This way the source is open at all times and companies that want to use it and modify it for commercial purposes can get a commercial license for that. In this case the biggest issue is copyright assignment. In order to dual license you require everyone who's contributed to agree. In large projects that's difficult. In a company, copyright can be handed over to the company, but anyone outside the company who contributes has to either sign over copyright or agree to letting their contributions be dual licensed.

The best option looks like a tight copyleft license combined with a contract for copyright assignment and revenue sharing for contributors and dual licensed for commercial use. The most difficult part of this would be gauging developer worth based on contributions, but that's something that happens in every company anyways.

> * Open source projects end up to be designed by committee, which inevitably turns projects to bloatware, which are hard to maintain and hard to use.

That's a concer of mine too and that's why I'm in favor of the BDFL[1] figure.

[1]https://en.wikipedia.org/wiki/Benevolent_dictator_for_life

> * Competition is becoming more difficult. Why to try to make another deployment manager if there's Kubernetes?

At the same time, you can also study how Kubernetes does the job, and come up with radical superior solutions.

> At the same time, you can also study how Kubernetes does the job, and come up with radical superior solutions.

I feel that's a bit of a reach. A small team will magically come up with something better than hundreds/thousands of developers that thought/developed k8s?

It's nice to think anyone can do that, but I believe only another company (and probably not a small one) could try and do that. I doubt bunch of open source contributors could come close to that.

But that's a different discussion regardless if open source or closed, big companies vs small teams issue will ever exists.

What I'm saying is that the product being open source allows you to study it, let's say you want to do something as fast as Redis, you have all that previous work open. I don't imagine a single person in a room going line by line studying it, what usually happen is that many people study particular aspects and write about it the problems they had, improvements and so on.

> I doubt bunch of open source contributors could come close to that.

Well it depends a "bunch" of open source contributors can organise themselves and grow into organizations, there are many examples.

Fair points.

Although this does open another hole for companies like Amazon/Google to, for example, repackage Redis as their "product" and sell it too.

But as you said, these are different discussions altogether :)

yes, that's what happen with MongoDB and AWS, right?

The ugly thing is that they take advantage from the brand too just saying "X brand compatible" they can use the brand reputation and re-package it, I agree on that point being an issue.

Thought doesn’t scale. A solid design/architecture can only come from a handful of minds. The hundreds/thousands of developers than can provide volume of features, not necessarily quality. This is why one person (or small team) can still be disruptive.

> * En-masse community memebers get nothing from contrubuting to projects while doing a lot of work for free. One may argue that in return they get polished product, but in reality that's far from true.

If you frame it like that, sounds like people are forced to work for free, think about other open source advantages, for example the freedom to customise the software to your needs without questions asked. You can fix a bug that is blocking you for doing something, instead of waiting a big company to prioritise your little problem. And that's just the first that comes to my mind, there are much more.

But I understand that your statment seems to come from a frustating experience, I'm curious about what was that product.

> "Competition is becoming more difficult. Why to try to make another deployment manager if there's Kubernetes?"

Open source projects are there as common heritage of mankind that addresses a major need. To me they are similar to roads ans railways. Where is competition to a road? Is there real competition to tcp/ip?

That's your problem with open source a la GNOME

There are well maintained Open Source projects that have effectively a BDFL and don't lose focus. Go language or Lua come to mind.

But people like to complain "Go is Google's language" because it's authors rejected some fringe proposal. Not that I like Go, but there are many ways of doing open source.

Similar experience, that is how I changed from an advocate with Linux Journal subscription and stuff like M$ on my email signature, to work again mostly with commercial software.