Otherwise known as the "voting machine company was too stupid to implement SSL" attack?

Or, for email, the "what idiot thinks email is secure without local S/MIME or PGP signatures" attack. Seriously, on-wire tampering is the least if your worries if you're *emailing* ballots around.

You'll be welcomed in engineering roles for mission-critical / safety-critical machine control systems, etc.

Outside that ... yeah. Good luck. Half the time my customers want the quick and dirty solution to a problem when they're contracting for work, against my advice to fix it right otherwise it'll break later for reasons x, y, and z. It's not just vendors pushing this, it's customers pushing for the lowest price and ignoring the consequences of doing so.

I fix bugs and develop features for customers in open source (BSD-alike licensed) software as part of my job, through a company that's made a reputation for PostgreSQL support.

That said, I agree that the support model for open source software doesn't work as well for people who want to use something casually. It's great if it's a core and major part of what your company uses, because you can influence its direction, prioritise improving the things you care about, etc.

It doesn't work as well when it's just a minor part of your tooling/infrastructure where no one user/company can really justify paying a contractor to do the work. It becomes like a shared driveway: everyone wants it fixed, but everyone just waits for someone else to fix it. It's very hard to get people to go in together to fix it, and if you do they'll spend forever arguing about whether they want a quick bodgy patch-up or the full long-lasting strip and resurface treatment.

It's easy to sink a lot of time into it if you go the "just fix it yourself" route too, as even simple issues often have huge learning curves around the languages, tools, conventions, etc involved. You can find yourself feeling like you're chasing a supply of issues growing faster than you can fix them too.

That said, I've dealt with many closed source vendors who add bugs faster than I can report them, or make bug reporting impossible / ignore bugs entirely.... and still charge huge premiums. On the flip side there are OSS projects that're incredibly stable and solid, so you can use them without really being concerned about issues. A lot of it comes down to choice of vendor/project/tool.

My favourite trick when dealing with sales people is to construct questions so that they have to say the word "no", or say that their product does not do / does not support something.

It's hilarious watching the "oh, yeah, we can do that" people double-take as they're forced to drop out of their automatic and unthinking responses and actually construct a new lie or really think about and answer the question.

You only have backups if you test them regularly, otherwise all you have is a false sense of security.

The same is true of failover.

If it's anything like many such big companies the customer service team couldn't tell the difference between a bug and user error to save their lives. The're probably also under pressure to admit no bugs - which is easy, because the software is bug-free until the instant a new release is made, anyway.

I wouldn't be surprised if the dev team used the mailing list to bypass the customer service people as well. That way they can actually find out about problems from customers without having to interpret reports filtered through four layers of idiot between the customer and the dev team.

I have the pleasure of working for a company where the dev team ARE the support escalations team and keep an eye on support contacts. Of course, we're small, and that doesn't scale, but we're also not afraid to say "I think that might be our bug, let me look into it."

After meeting your #1 requirement - finding the project interesting - I'd focus on the attitude and community:

* Is it friendly?
* Is the discourse on the mailing lists / forums / whatever generally positive in tone?
* Is it welcoming to new people?
* Is there a list of new developer / getting-started tasks, tutorials, documentation, etc?
* Is there any sort of mentorship program? Or at least a code-review / patch-review process?
* Is there a well defined process for people without direct commit access to get changes included?

and the codebase:

* Is the codebase sanely structured, documented, and commented with a fairly consistent coding style?
* Does their revision control show disciplined series of commits with good commit messages?
* Is there a way to report bugs?
* Is there regular development activity, not just occasional patches?
* Are commits usually followed by streams of fixups, or do they tend to be reasonable the first time around?
* Is the complexity level accessible for you - i.e. is it simple enough that you can follow, but complex enough to be challenging and interesting?

In other words, I'd be looking for something with a healthy community, code that isn't buried in technical debt, with good development practices and a positive attitude.

I've actually run business Linux desktops for years, and I had endless problems.

* Random GNOME profile corruption. Lots of it. XFCE was no better, just different corruption issues;
* OpenOffice bugs and crashes;
* OpenOffice crashing, starting "recovery" but failing to find the tempfile it's trying to recover, and endlessly trying to recover that file every time the user launches it from then on;
* Mail clients (Evolution or Thunderbird) crashing but leaving dead processes around that had to be manually killed before they'd relaunch;
* Painfully difficult and buggy central configuration and management of things like desktop profiles, mail setup, etc;
* Handling of archives in email attachments, those horrible broken outlook TNEF files, etc, sucked;
* Printing was painful and buggy despite my being quite careful to get only native PostScript printers. Various apps would generate broken PS in all sorts of exciting ways, or CUPS would set job options that printers would choke on, basic printer features were unusable, etc etc;
* Random app devs who decided to call umask(0700) and override the system umask before creating files, because OBVIOUSLY they know better than the user and sysadmin what the file/dir creation perms should be;
* Numerous apps that'd suppress the setgid bit when creating new subdirectories in shared working trees, leading to more permissions issues;
* I was nervous about even minor upgrades to fix bugs, because for every bug fixed there'd usually be three new exiting bugs;
* For the Windows desktops (for a few users who needed accounting packages etc) using Samba for roaming profiles, *tons* of profile corruption issues, endless printing problems, incredibly poor performance, and difficulties interoperating with the Linux desktops

These were "basic users" who needed little more than word processing and occasional use of other simple document exchange, PDF viewing, printing (oh god, so much printing), email and simple attachment handling, and image viewing/sorting/saving. They weren't doing anything complicated.

Windows 7, Active Directory, and Group Policy were an incredible breath of fresh air when we bit the bullet and switched over after acquiring a Win2k8 R2 server for unrelated reasons. Sure, they have plenty of problems - but wow, did it work better overall. Things like volume shadow copy snapshots of server-side roaming profiles were a huge improvement over periodic bacula snapshots of bits of user homedir state.

The main problems we had with Windows were with roaming profiles - and were caused by obvious bugs in OpenOffice, Firefox (moved to Chrome which was better), etc, especially keeping piles of temp state in %APPDATA% not %LOCALAPPDATA% where it should be, modifying SQLite databases directly on remote storage, etc. These apps don't get tested on "business network" type setups, with roaming profiles and redirection, and they don't follow MS's recommendations on file layout etc. It shows.

The only serious issue I had with the Windows deployment was that %APPDATA% redirection for roaming profiles is horribly broken with caching enabled; the sync tool just throws a spak, gives up, and waits for the user to resolve conflicts. It's quite capable of creating conflicts even if there's never any connectivity problem, and the results are messy. Once I disabled offline access and caching for %APPDATA% (a significant performance hit, and it meant that if the server was down even briefly all clients would just freeze) the sync issues went away, but it wasn't a great compromise.

I wasted a huge amount of time babysitting the Linux desktops. I reported so many bugs, wrote so many patches - even though back then my C programming was ... er ... limited, so I could only tackle some issues. It was whack-a-mole, and it was no fun at all.

I use Linux on my laptop for work, and I'd hate to use anything else. Though with the KDE4/GNOME3 thing I'm getting less fond of it. For basic end users, though? Nope. No way, never again.

... and yes, I know it's hard. I've spent *hours* figuring something out to write it up. Many, many times.

OTOH, I'm using someone else's often very good work for free. Perhaps it's not an efficient use of time ... but then if I've paid for something I often find I still have to dig around and figure out issues with it anyway.

Agreed. You can produce good docs without the solid co-operation of the dev team, but it's much more difficult, more time consuming, and a lot more frustrating. They also tend to bit-rot a lot faster.

I love the way that people who don't contribute themselves describe those who do as "lazy" and demand that they make "excuses" for not doing what they're doing well enough to meet the standards of random other people.

This attitude actually makes the problem worse. "Screw you, why should I bother documenting something I wrote for me when some asshole's going to come along and tell me it's not good enough for them anyway? What'd they ever do? I'll just make it work for me."

Your point is somewhat accurate, if poorly made.

You neglect important externalities though. Often the devs are competent, but working to unrealistic deadlines and with priorities that specify that the product must work - not be pretty or properly documented.

You'll find this attitude in many fast-moving industries with little regulatory oversight.

Heavier regulation tends to force better processes, better documentation, higher standards for QA, etc ... and greatly increase the cost and time taken for everything.

It's a trade-off. You would clearly prefer the trade-off to be more toward a process-based, managed system than it currently is. Are you also willing to pay 3x as much for software? To greatly reduce what's available or possible for people to build for free, or make it entirely impossible?

I share your frustration, but unlike you I don't think the answers are simple, or that the explanation is that people other than you (obviously) are stupid.

Did you report a bug about it?

Sometimes the folks working on the tool just don't spot these issues and need to be poked. I know it's true for me anyway.

I find it incredibly valuable to talk to people who don't already know the system/problem/etc well. They often see what I can't because I'm already too immersed in it. When they don't, they're still useful because they force me to fully explain the problem and in the process often identify an error in my reasoning.

I often write explanations to this imaginary new user now, when I'm trying to figure something out. Or I tell it to my partner - I work from home so there's nobody else. If she's not interested, well, the baby has no choice but to listen ;-)

I'm glad to see you say that.

There's still plenty to improve in the Pg docs, and we welcome patches from everyone.