Major OSS applications like Hudson/Jenkins would likely face stiff competition from paid or free book authors, but I'm not sure that this is a show-stopper. There's always room for improved versions or "by example" type books. If somebody needs to learn about the tool fast, they may be likely to drop a few bucks (really cheap compared to spin up time) even if they're not sure what they're going to get. Also, there are lesser-known, but highly regarded applications, that nobody has published decent documentation for.
I would say....
The biggest hurdles to get over if one chose to self-publish "howto" texts or "by example" books directed to particular OSS tools would be as follows:
- As always - marketing. Getting the word out. MUCH harder than it appears.
- Credibility. Will geeks speak favorably amongst themselves of the work or will it be regarded as lightweight, laggy fluff?
- Timeliness. OSS changes SO fast. Commercial software can be relatively inert for many months or even a couple of years.
- The "everything should be free" culture of OSS.
I think the marketing and credibility aspects could be mastered by socially tethering yourself to the inner core of OSS project maintainers and becoming known as an authority on the tool. That in itself would be quite difficult until you had the right cred to be known to the right inner circle people. Major open source projects are intensely competitive about who has a voice with the maintainers of the project. (Who will be the ones who really understand the product architecture, plans going forward, etc.)
The rest of it would be a full time job staying ahead of the latest release. And the "free" culture of OSS would seriously affect the uptake of a reasonably priced e-book or real book.
Just LOOK at all of the elements that have to be perfect or very good.
This is definitely not a retirement job. This would be hard work, essentially developing an information product business around an OSS tool. Against significant multiple challenges.There are
far easier subject matters to develop, publish and market informational products on than complex enterprise class OSS products.
So I really don't see this.
Actual marketability as a technical writer demands mastery of desktop and online publishing technologies. As in, you MUST be able to develop a publishable manual or help file from scratch with no input from a designer. YOU are the designer as well as the tool jockey. There is absolutely no niche for technical writers who pass pure content (just words) along to their clients or employers. That tool mastery is the killer, for me.
Do you mean mastery of the the DTP tool, or the software tool to be documented? Understanding how to use the software might be a show-stopper. It's a lot like maintenance and takes a lot of time.
YES! I could not be any clearer. You got it.
I have a local friend who is a technical writer. When he worked for technology companies, he CONSTANTLY had to jump through hoops to prove his buzzword compliance. Back around 1996 when we last worked together he was constantly tinkering with add-on tools for MS Word, and stand alone tools like Robohelp. When he interviewed for jobs it was more like a science fair show and tell exercise to convince hiring parties that he had this current bundle of help authoring apps under his belt.
I'd rather maintain a stupid H1B's abandoned Hinglish code than deal with the crap associated with the market demand for DTP tools.
Where the job title says technical writing, the actual craft of writing is secondary.
Why is it, then, that the main qualifications always seem to be English or Journalism ?
Because even though almost all documentation is pure crap, it still has to read like business English, not Chinglish, Hinglish or retarded IM speak.
To extend the anecdote above, my tech writer friend is an ex journalist from the Detroit Free Press and Cincinnati Enquirer. He has been laid off or fired multiple times and his talent has usually taken an extreme second or third place to showing that he can format his stuff real pretty using Pagemaker, or later DTP tools.
Here's the bottom line.
Technical Writing in the software industry is an unexpectedly and surprisingly complex career challenge - on a par with software development, but not nearly as well respected - and the industry places high priorities on things other than "good writing" as its chief goals in a technical documentation project.
