This is a quite paradoxal phenomen that happens to some open source projects. The code is open and free, but some of the experts hold their knowledge very close to their chest. It's totally understandable since they of course need to make a living somehow, but it kind of defeats some of the benefits with open source.

It doesn't have to be ill will, or even will. Something like JACK is a component of a system. Maintaining this component as open source is fairly simple -- but capturing and sharing the understanding the complex interplay of components and the tradeoff needed to achieve certain ends in the wider system is really, really hard.

Linux might be free and open source software, but it's not a failure of anything that it doesn't come with a free systems administrator education.

Roughly speaking it levels the playing field. With Open Source smart people and companies that attract smart people get an edge.

Good point! But the hazard is that the we risk getting FOSS software that is unnecessarily complex to configure because of this.

In my experience proprietary software is often far more complex, in fact in another league than most FOSS SW for now (source: have installed and reinstalled so many Oracle databases, Enterprise Manager and APEX installations I have lost count.)

Depends on the software and author. Case in point: sendmail; virtually everything ever made by RedHat (the software is free, but there's no useful documentation if you're not a paying customer… cf. NetworkManager, PulseAudio, GlusterFS … only systemd seems an exception, for now).

Good point! However, I would agree that server/system software that is "best-in-breed" tend to be FOSS. But I'm afraid I have no studies or other hard facts to support my case.

Configuration can be a pain. Sane defaults help and smart UIs help not to mention good documentation.

I've been playing with some software over the last week that has wiki for documentation and an active user forum with people willing to help. But it's completely disordered and incredibly hard to discover. Half the battle with usability is making it easy to use and understand.

Some contracts are worded very... weirdly, so to speak, which makes talking about projects potentially dangerous.

I don't think it's such that the person in question doesn't want to share the knowledge, it's that imparting the knowledge is time consuming and draining.

> He wasn't particularly interested in talking about the work his team had done :P

As in, he tried to keep the secrets secret, or it seemed to be trivial and uninteresting to him?

more likely the former