When I wasn’t making art on computers, I was telling them what to do by programming them, which I’ve made a career out of in the world of web development for nearly two decades.
This intersection of art and computers has a third, equally important, intersection—open source —and it’s why me joining Tidelift fits in so well with the way I work, the tools I use, and the values I hold about creativity and freedom.
I got my start in the open source world during college, when I ran a distribution of Linux called WinLinux on an already-old Pentium 133. WinLinux lived inside a Windows filesystem, so I didn’t need to partition my hard drive, and I could easily access all of my files in both Windows 98 and Linux. I started to very slowly use the Linux part of my computer more and more, dropping to Windows only to do things like watch videos or burn CDs. It was nice having a local environment where I could run my Perl scripts, something that was a pain in Windows back then.
In school I majored in computer programming and minored in graphic design. I used all the usual tools to make my art for myself and for my class—Photoshop for drawing & manipulation, Illustrator for vector work, and QuarkXPress for page layout, as this was pre-InDesign.
The biggest issue I had with these tools is that I would have to continually pay to get new features (and now, with Adobe Creative Cloud, if I stopped paying, I’ll lose access to my files completely). I have no problem with paying for software, but I was about to learn what happens when a company decides to end support for software that became critical to my workflow.
Blender, the 3D modeling software I used for making backgrounds for some of my art pieces at the time, was a closed-source shareware product. You could use the limited free version, or pay for a key to unlock more features. At the time, it was very simplistic in what it could do, had a difficult-to-use interface, and the default renderer was nothing to write home about, but it worked well enough for me. I was getting ready to fork over some of my cash for a key when it was announced the company that owned it was no longer going to sell or support it, as it was no longer profitable.
Instead of switching to another tool like 3ds Max or Maya, I contributed to the Free Blender campaign, the first of several times I’ve paid in either money or time to help develop and promote open source art software. This first campaign paid for the release of the source code to the community so that they could develop it as they wished, and future campaigns focused on improving Blender for making short films with ever-increasing quality. The most important thing is that the source was now available for all, forever.
I’m still pretty terrible at Blender if you couldn’t tell, but it’s important to me to have tools that, in theory, I could improve myself and that would always be around, as opposed to the closed-source tools that could, in theory, go away at a moment’s notice, or never be improved upon again.
Eventually I started moving my entire art creation process, mainly my comics, completely over to open tools. First, I used a Wacom tablet with The GIMP to ink overtop scanned pages, but scanning and assembling penciled pages is tiresome, and my skills in inking in The GIMP, a bitmap-based drawing tool, did not provide the precise, clean look I wanted (partly because of skill at the time, I admit). I then moved to doing my comic pages entirely in Inkscape, a vector-based drawing tool—doing “pencils” in light blue in one layer, and “inking” in a layer above it in black, both with the Calligraphy tool, which meant my inks could be adjusted on a per-stroke basis.
The problem came when I wanted to “color” parts of the drawing. I had been creating a “colors” layer behind the “inks” layer and hand-drawing colored shapes using the Pen tool behind the inks—a very slow, very laborious process, even with a tablet. In The GIMP I had a paint bucket that could fill areas of a drawing, but that’s easy to implement in bitmap. Could I get something similar in Inkscape?
Over a caffeine-fueled, sleepless weekend, I assembled a slow-yet-functioning Paint Bucket tool. It did a bitmap fill of the rendered image in memory, then used Potrace to create a vector version of the fill to be inserted into the drawing. The difference was immediate—my time to color a comic page was reduced to ⅓ of the original time. The work that weekend paid for itself in the next three or four pages. The tool was a complete hack, and it doesn’t provide a precise fill, but it sped up my drawing process by leaps and bounds, and it’s lived in Inkscape ever since.
My work on Inkscape eventually took me to a Libre Graphics Meeting in Montreal, where I met other developers who worked on Inkscape and other OSS art projects, and hung out with lots of artists who primarily used open art tools. My own OSS development, however, was going to go back to a much more familiar place for a while—web development.
I’ve been publishing my comics on the web for a very long time, even before “webcomics” were a thing! I started putting my very early college comics up on my website around 1999. I had always built my own comic websites, either manually or with some simple Perl or PHP code to build the nav and schedule things going live.
After getting fed up with building my own sites, I decided to finally use ComicPress, an early webcomic-focused theme for WordPress, and in the initial minutes after I installed the theme, I realized that there would be no way I was going to manually FTP files up to my server and create posts by hand.
Not only did I start working on improving this free theme with two other developers, I also created ComicPress Manager, which was once one of the most popular tools for getting comics up to a WordPress/ComicPress site, and easily one of the more complex pieces of software I built. Not because of what it did, but because of the incredible number of combinations of environments and browsers it had to run on, which made debugging issues extremely difficult.
Eventually the demands of keeping the plugin running on so many flavors of WordPress, PHP, image libraries, browsers, and host operating systems was too overwhelming, and I stopped working on ComicPress and all of my other WordPress projects. Shortly thereafter, I also stopped working on my Ruby Gems, my JavaScript testing tools, and pretty much anything else public and open source.
I was burned out doing development for others, and I wanted to get back to working on my own, non-software projects. Sure, I’ve published the occasional thing to my personal GitHub account, but my days and nights of development on open source software for the community were effectively over.
I found the ad for the position at Tidelift in December 2017. Once I learned about Tidelift’s mission, I knew I had to get on board. After a great interview process (we’re hiring!), I started in early January 2018, and it’s been a great experience. Tidelift’s focus on improving the quality of life of the maintainers of the dependencies used to build larger apps—the kind of apps I’ve built throughout my entire career—is a fantastic way to bring more awareness and support to a value I’ve held dear for a very, very long time.
Anything that can be done to make sure developers of the pieces of infrastructure that I use daily have the motivation necessary to keep maintenance and upgrades and bugfixes coming, and having all those changes go back into the world for all to use, forever, is a huge win in my book.
I still use open source software almost exclusively—all of my computers run Linux, and I use Krita, Inkscape, ImageMagick, and The GIMP for almost all of my art (Procreate on an iPad Pro is really good, what can I say?). I’ve contributed money to Krita when they got into a bind with taxes, and I continue to sell the idea of using open art tools to my comic friends when I can.And now, in my day job, I can continue to promote this idea through the work I do for Tidelift.