My motivation for creating libjtapi.org was patio11’s “how to successfully compete with open source software”. Patio11 wrote from the perspective of proprietary software selling to consumers competing against open source clones. Despite Libjtapi being a open source library usable by programmers much of the advice still applies.
The general advice patio11 gives is to focus on what the software’s capabilities and the surrounding environment and not the software itself can do. That is to say: Our users do not have a jtapi problem, they have a job ticket problem.
Thus we need to talk about job tickets and their place in a modern printing system. We need to write targeted pages for each format as if libjtapi was THE solution for THAT job ticket. If they search ‘pwg job ticket library’ or ‘how to parse pwg job tickets’ they should arrive at libjtapi documentation for a pwg job ticket specific hello world.
This is an easy one. Much of my freelance work is setting up attractive wordpress sites. In the past year alone I’ve shipped upwards of eight wordpress sites.
The downside is that these beautiful wordpress themes are all closed source. One battle at a time.
User Experience & Speaking the users’ language
Programmers prefer code so the hello world is going to be plastered everywhere. The homepage is going to open with a small paragraph about consuming & producing jobtickets with jtapi. Right below that will be the hello world. Each job ticket format page will contain a standard specific hello world. The site’s footer will also have the hello world.
On the download page below the link to the zip will be, you guessed it, the hello world. Bonus: there will be a link to download libjtapi_helloworld.c
Once visitors see the zip they’ll see the exact command line for creating a local branch of the bzr repository. Then a series of screenshots that document using the bzr explorer gui to create the local branch.
The end game goal here is to assure programmers that libjtapi solves their problem and get them to download us. Once we have users then contributors & bug reports will follow.
There is going to be a set of re-occuring problems. Some will be fixed in software, others will need documentation. When these get fixed we should make an issue of this. The site’s news section should re-assure programmers that libjtapi is active and getting better and better.
Every bug I fix will be one more reason to use libjtapi, it is one more mistake that libjtapi can save the programmer from committing.
One of the many reasons typical open source libraries’ websites are sub-optimal is that the website comes last. By creating libjtapi.org now at a time when there is no code and we do not need users or contributors the website will be well-established and ready for when we need it.