At my company we are currently re-assessing which team will take on the responsibility of external documentation (end user, training and support documentation). We don't have a dedicated technical writer on staff and, like most development teams, our developers struggle with writing high quality, consistent end user docs.
Who should own this responsibility and why?
You need someone in authority to make sure it gets done (I guess managers should do that?). All 3 of these groups should have input. Product owners may be involved more during the requirements hunting and testing phases. Tech support may pick things up during testing and when they create training docs. The more imput they get from developers the better, but there needs to be some discretion to prevent taking up devs time.
The documentation should begin with the developers, at least the technical documentation, and should be reviewed for quality control after the respective code passes code review. If the documentation fails quality control it should pass to an editor for clarity and uniformity.
I would argue that without a technical writer, the ownership of documentation should fall on the developer, however, documentation should be the responsibility of the both the developer, support engineer, and marketing team.
The views offered by the developer/support/marketing people will be different by necessity, and each should have input in order for the documentation to fulfill it's goal.
Joel Spolsky has a good series on writing specifications that also touches on this.
IMHO a software developer should be able to write decent documentation. If he can't, then he's incompetent (that he's not the only one who can't write is a lame excuse). So cut his salary and hire a technical writer with the remainder - or if it feels better to think the other way round, double the salary of the other developer competent in writing.
While lots of people seem to be religious about strict role definitions and separating developers from writers, it doesn't change the fact that there are developers quite capable of writing good documentation, and they're obviously way more valuable than their tunnel visioned colleagues.
Everyone should have a hand in writing 'documentation' in some way. For developers it can be as little as comments in the code to explain the intent of the code, to going as far as being involved writing design documentation and specifications. Tech support should be writing support documentation to support the application. Q/A should have documentation on how to test the product and a change log. Product owners should ideally if it is custom software have a copy of the specifications, as well as a 'user manual' if needed.
Not all of this 'documentation' will reside in the same place or even have the same purpose. In fact it is quite possible that you can have too much documentation for a project. It really comes down to common sense for what you need for your situation and project.
Technical writers own documentation. Developers provide technical insight, tech support provides troubleshooting insight and product owners provide the overall insight (uses, future directions, and so on.)
If you don't have technical writers, you should get the best writer in a team to be responsible for it. Roles are not important as long as all them are committed to providing the information the writer needs.
Just my opinion, but... EVERYONE!
If documentation is not a collaborative effort, then something is bound to get left out. In terms of who drives this collaboration - well, I guess that's down to the individual circumstances of the project team; someone in a position of authority, that's for sure.
IMHO, having developers write end-user documentation is a very bad idea. Developers are good at writing code, not end-user documentation. If you've ever used software with docs written by the development team, you'll know what I mean. The docs are pretty much worthless for anyone that's not a developer.
Now if management is not willing to pay for a dedicated technical writer, I don't know what the best solution is.
My vote is with Chris Rice on this one ... everyone should own the documentation.
To this end, you should have all your docs in a wiki. That way anybody who is ever frustrated with innaccuracies or ommissions in the docs can fix it themselves, rather than just grouse about it.
If you can, then set up a Wiki and a single person responsible for it. That means everyone can edit but that single person gets GOD MODE and can undo any change plus set the rules. This way, everyone can easily contribute to the docs and, if you choose your Wiki carefully, you can export it and ship it with the product or, even better, put it online for the end users to edit/comment.
The answer depends on what kind of documentation we're talking about:
End-user documentation shouldn't be written by programmers, only exception is if they are really good at understanding a what kind of problems users need to solve with your application/program/system. You should really leave this task to a technical writer.
Code documentation should totally be written by programmers because they are themselves users of the code. If they're bad at writing, it's okay. Hopefully some other programmer in the team will correct logical errors, grammars or spelling mistakes that some are prone to do (but please write code comment documentation in seperate checkins/commits in order to avoid merge conflicts).
In the case of ownership I believe in collective code ownership among programmers. You can ensure higher quality if everyone has a helping hand in it. Except for end-user documentation unless they're really versed with all requirements that an end-user has (which is impossible in large scale scenarios).
A lot of these responses are talking about internal documentation. You didn't ask about that; you asked about end-user (external) documentation.
On any large enough project to have specialists, external documentation should not be written by developers. That's technical writing, and there are legions of folks out there working full time as technical writers. If you're a software developer able to write top-quality end user documentation, you're in the tiny minority of working developers today.
If you're a small team, too small to have a full time technical writer, you've got two choices:
We have embarked on an interesting experiment to use a social media platform and a community approach to make our enterprise software documentation more up-to-date, accurate and relevant.
We definitely have found a divergence between writing styles of technical writers versus developers, QA folks, consultants etc.
We also are finding that varying incentive systems get in the way to creating the best possible documentation in an agile fashion. Developers mostly are incented to develop code in time and scope, technical writers to deliver style guide compliant documentation.
We do however see that the only effective way forward is a co-creation model, to lower the cost of understanding our products, and increase knowledge discovery effectiveness.