Hacker News new | ask | show | jobs
by LarryL 2886 days ago
> why is there such a hard dichotomy between "commercial - binary blob" and open source?

I see at least 2 reasons.

1) Mindset (and ignorance)

I've worked in big telecom companies, in their technical teams, which means people who know about programming in big (BIG/HUGE) projects. Even there, many of their -very- experienced tech people were AFRAID of anything open-source. They were terrified that using anything that had the words "open" or "free" (as in free software) would mean that they would have to "give" their code "gratis" and lose their customers.

The irony? Those programs were BIG projects that were only useable with their hardware (think stuff like devices' OSs & supervision UIs for telecom equipments), it would not have worked with other devices and any attempt at an adaptation would have cost more than developing from scratch. Add to that that they only sold to a handful of companies (those hardware + software solution are expensive) so they would immediately have noticed that something was wrong, and you see how INSANE it was that they were afraid. They had completely bought the FUD from Microsoft and the like.

And thoss were TECHNICAL people, I leave to your imagination the attitude of managers... :-(((

2) Quality (or lack thereof)

A lot (if not most) of code done for "enterprise software" is of pretty bad quality (and I'm being nice). I've seen such horrors that you are left to wonder how anything AT ALL could work. The incompetence was staggering, comments and tests inexistant, no source management, no documentation, "if" conditions spread over hundreds of lines, 10 thousand lines of SQL in a single file, config files thousands of lines long maintained by hand (which I showed contained hundreds of errors), etc.

Showing how "sausages are made" (an horrifying view) would be bad, maybe even suicide (once their ineptitude would be proven) for those companies.

On the other hand, the bad quality would have quaranteed that nobody used their projects (LOL). Even compiling them was a HARD task. Real example: I had just arrived on a project where the most experienced guy was unable to install on my computer the tools needed for development... I had to write code "blind": without linking & testing nor documentation. Am I surprising you when I tell you it did not go well? (And they had the nerve of blaming me for their incompetence!)

1 comments

There's a third issue - support.

I worked for a place about 15 years ago which was trying desperately to retire its previous flagship product in favour of the new version. The new version was better written and more scalable, but the major value for them was that they had made a big mistake with the old one -

The gave away source code and allowed customers to customise the software, but they still honoured support contracts. This had turned into a huge cost, as engineers were having to go out to customer sites and spend days figuring out what the customer had done.

You can't effectively support what you can't see, so you can only really support OR allow modifications.

No sensible person is going to be mad with you for asking them to reproduce their issue without local customizations applied if they want you to help them with it.

Write it into your support contracts. Maybe offer smarter customers to review and sign off on their modifications in exchange for a reasonable fee.

These problems can be solved.

Actually, it seems like a huge wasted opportunity. If a company is so invested in your software that it's willing to develop a custom patchset and an internal team to maintain it, then it would make a lot more sense to buy the service from the very people who wrote the software, that know it best and can pull together multiple customer wishlists into standard solutions. That's why the open source service model can exist, the original developer is uniquely positioned to profit from these synergies and deliver value for the customer.

So you can have your proprietary cake and eat it too, you can sell "NO WARRANTY, EITHER EXPRESSED OR IMPLIED" commercial licenses at fixed prices, but at the same time, earn much more profitable support and customization contracts from select customers.

As for the people still opting to customize their own "NO WARRANTY" installation, of course they won't get and don't expect any support for their customization until they also buy a services license.

> asking them to reproduce their issue without local customizations applied

This was a big, complex piece of software, a bank-level payment switch. It's possible that they couldn't run at all in their environment without the customisations applied.

> These problems can be solved.

I agree, if the contracts are well written and sensible :)