Hacker News Reader

Comment by nine_k | Hacker News Reader

This is why the key product should be open-source. Else it's too scary to invest in it: what if the company behind it folds, and you end up in a dead end?

Only certain super-behemoths like Microsoft or Apple can afford to have their infrastructure products being closed-source.

View on HN

How many people in the world can work on a large DB, even with source?

I am all for open source, but it doesn't make things like this is easy as some make it out to be. For example with Linux source, how long would it take me to fix a video driver bug? Perhaps a year?

I hope it wouldn't take you a year to hire someone qualified to fix it for you.

If open source only works when you pay for it, it's just an abstraction layer around ordinary commercial software, with the same pressures. In fact, most of the people qualified to fix Linux video drivers are already employed full-time at a graphics card manufacturer (with its sales pressures) or a commercial redistributor (with its sales pressures). You could pay one of those companies for a support contract. But other than that, if someone else qualified exists, it's only worth their time to take these contracts if there's enough sustainable business to keep up-to-date with how Linux graphics drivers work; chances are there isn't, and they're spending their time in full-time employment doing something else entirely. So, you're at the same place where you started: the problem is complicated enough that there aren't enough reliable sales, and so it only gets done by large companies that can afford to fund the work because they already have enough sales of enough things.

(Full disclosure: I am one of the people who could have been qualified; one of the jobs I was considering a few years back was a graphics-driver-hacker position at Red Hat. I happened to instead choose full-time employment doing various, mostly userspace Linux stuff for a startup. When they ended their incredible journey, I would have loved to make a living taking contracts like the ones you suggest - and I still wish I could - but there aren't enough of them and they aren't reliable enough to make it better than just taking a full-time job with a profitable company.)

With ordinary proprietary software, there's only one team in the world you could possibly hire for maintenance, and if they're too busy or have a conflict of interest you're just screwed. Competition among maintainers should make them more efficient and scale better.

Maybe?

But that assumes there is a ready supply of people that can fix a certain part, and want to take contracting work. For example, let's say I have an ATI XYZ in my laptop. It has a driver bug and won't work. ATI driver is open source. Who do I hire to fix it?

Except that's not quite true for ordinary proprietary software - there are a number of people who make a living supporting Windows or Active Directory or Exchange or whatever who don't work for Microsoft. There is a difference of degree, in that third parties who support open-source code (e.g. Oracle supporting RHEL) have access to the source, and third parties who support proprietary code usually don't (although it's possible to get a MS read-only source license!) and only have access to compiled binaries. But that's not a huge difference. There are people who are very good at tracing and disassembling compiled binaries, or simply at understanding how the system works even in the absence of code, and they have thriving businesses. Sysinternals, for instance, was a separate business acquired by Microsoft.

(Note that I am carefully using the phrase "open source," not "free software". Part of the free software ethos is that you can realistically modify your code as needed. I do happen to think that the current free software movement isn't very good at delivering on this promise.)

His point is a little more subtle than that. When you're choosing a database engine to build your company on, knowing that it's open source provides some level of guarantee that someone will continue to maintain it if the company/developer folds, even if that someone is not you.

Therefore, if you're the one building the database, open-sourcing it de-risks your product to your potential customers, to some extent.

To expand on this point, if you look at Linux development, multiple companies are contributing to the project! The product exists outside any single organisation.

Of course closed source products can also be collaborations, but open source + open development practices can make this a smooth and natural result.

Someone? You shouldn't pick an opensource project hoping someone motivated picks it up soon after it's abandoned. The primary company going down is usually it, especially when the project hasn't even picked up enough community yet.

If the DBMS's users wouldn't chip in enough money to cover the cost of developing it before the company went under, it seems hard to believe that they'll suddenly decide it's cost effective to pay for having it developed post-failure. If anything, it just implies that they've become so tightly coupled to the product that the DBMS vendor's failure represents a sudden existential crisis.

I think, more important that whether or not the DBMS is open source, just consider how critical the DB is. If you can't live without it, stick with a DB that you can be virtually 100% sure isn't going anywhere soon. Save your experimentation with new products for the small and less-important stuff, and make sure the small stuff doesn't reach some critical mass before the DB vendor does.

> This is why the key product should be open-source. Else it's too scary to invest in it: what if the company behind it folds, and you end up in a dead end?

The way this is dealt with for closed-source software is source-code escrow. The support contracts stipulate that the company that built the software set aside the code with some stable third party, and that it be available under specified conditions, such as the builders going out of business.

It's not as good as having the source freely available, but then it's dealing with an extreme contingency, anyway. Very, very few users of a piece of software have the expertise to build it from source and then debug it if they run into problems. So they're probably screwed either way if the builders go belly up.

> Only certain super-behemoths like Microsoft or Apple can afford to have their infrastructure products being closed-source.

The alternative is to buy truly critical software only from companies you trust a lot. XYZ Valley Startup is unlikely to be around in 20 years, but Oracle almost certainly will, as will Microsoft.

It works the opposite way too.

If a project is open source then who is committed to helping you support and maintain it? You essentially need to have a team to do it.

If there's a company behind it, it gives you assurances.

Especially for a small company that needs to focus on building a product rather than committing features and bug fixes to their database

You can have an open source product with a company behind it, they're not incompatible.

Red Hat's market cap is almost $15B and they're worth $2B. Definitely not incompatible.

This is like saying "the widget sells for $15 and the price is $2".

I assume you mean they have $2bn in annual revenue?

Yeah.. whoops. Thanks for pointing that out.

Right. My point was more that being open source in its own isn't always enough. Having a company behind it makes a difference to many people - more than the distinction between open vs closed.

I was able to sell our company on Cassandra because there is a Datastax there to support it when the shit hits the fan.

Of course the entire point of this particular article is that they are pretty difficult to make profitable

You cannot draw that conclusion from the data at hand. There's plenty of closed source product companies that shut down because they didn't manage to make a profitable business as well.

Reply on news.ycombinator.com