- repo: https://github.com/quasarframework/quasar
- tl;dr; How I became an open-source developer and member of the Quasar team.
- eli5: Sharing isn't stealing. Help people to help you. Everyone can be a programmer.
If you know me personally, you also know that I belong to that specific class of lazy people who would rather spend weeks building the perfect tool to do something that would have gotten done in minutes were I that other kind of person: that kind who doesn’t get bored doing the same thing over and over.
For me, it is exciting when it’s new - and I don't like having to do something the same way a third time. For example, I solve problems by making tools such as an automatic video editor for batch editing short films, designing an approach for declaring the "degree of openness" of open-source artefacts, using set-theory to figure out what people mean when they say something silly, or even assembling an artistic reflection of the state of our modern world, like the following photograph of one of my sculptural installations...
Kulturerbe (Cultural Heritage) - 2007 - Installation view, Galerie Eigenheim (Weimar)
Tools are applied culture, because not only do they help us interact with our world in efficient and/or fun ways, their use also tells us a lot about who we are. Programming, as a form of communication, has always been about the automation of logical tools: input, condition, step, action, output.
Automation is a great thing, because if you do it right it really takes all of the boredom out of your life and lets the machine do the stuff you can’t be bothered with. In the 1980s, I wrote my very first program in Basic on a Commodore 64 to help me quickly generate NPC's and Monsters for the role-playing games of Dungeons & Dragons that my friends and I would play. For me the sounds of a dot-matrix printer and the clattering of D6's are permanently melded into one acoustic memory...
I suppose that I too am also a product of the epoch in which I live, just another one of those creatures that fights the staleness of entropy with every breath (and keystroke). Look at all of the extreme athletes who go to the absolute unit of their limits and sometimes even die in search of the thrill, the sport, the excitement. Look at all of the prolific Instagrammers being driven to distraction by social media; being trained to thirst for the new and the fresh. Look at all of the hipster developers who hopscotch from stack to stack because the only good is the new. Am I all that different?
Machine Learning - 2015 - Installation view, Galerie Speckstrasse, Gängeviertel (Hamburg)
You could be forgiven for thinking that I am romanticising too much when I say that coding as a form of sport is actually the thing that I love the most: The challenges of unifying an idea with algorithms, of designing architectures, of deploying code to hardware. I love seeing things arise, “Die Entstehung der Dinge” as some of Quasar's German staff in Hamburg would say. I love building tools to make these things, but this isn't where the Quasar Framework enters my story - not yet.
The Adventure Begins
In hindsight, I can't really say that my life with open-source started on accident, but it wasn't intentional either. It all began one cursed Monday about ten years ago, when I came back from vacation to discover that the intern had managed to infest my Windows work laptop with what seemed like every virus out there at the time. It wouldn't even boot! The problem was that I had some files that absolutely had to go to the printer - that afternoon.
I remembered that a good friend had passed me a Knoppix live-cd months earlier. I was always hesitant to use Linux, because my training in the 1990s as a graphic designer had forced my hand with regard to software "choices" for 2D and 3D work. But this was an emergency, and I was shocked at how utterly simple it was for me to use Linux and dig into the Windows folder structure. In fact, I was literally in awe of the power I had over Windows: the user password didn't matter...
Upon returning from the print-shop, I actually installed Knoppix and then Gimp because I couldn't find the Windows DVDs. It sucked really hard, but I sensed the challenge and had heard about this thing called imagemagick... Soon I transitioned from Knoppix to Ubuntu, from Debian to Raspian, from Mint to Arch, from Kali to Parrot etc. I learned to use GIMP, Blender, Inkscape, graphicsmagick, ffmpeg, sox, ssh, netcat, rysnc and even bash. I came to learn what file headers were, what the Magic SysRq key was, how to flip the framebuffer and how to pipe.
My time with Linux was also peppered with moments of deep frustration - like when the interrupted system upgrade bricked the PC because someone in the flat tripped the circuit breaker, or the crushing realisation of losing one specific strong passkey, the one that I would have used to recover those 300 bitcoins from 2010. And yet, there was never an experience I cherished more than getting things to work the way I planned.
Along this mostly stony and unfortunately repetitive path-of-most-resistance, I learned four lessons that are so important and applicable to everyday life && programming, that I am going to segue for a moment and get preachy:
1. Know what to call the thing being dealt with. 2. If it can't be understood, it shouldn't be used. 3. Track progress and write documentation. 4. Never steal ideas, tools or other people's time.
If I am incapable of describing what it is I am talking about, not only will I never be able to communicate it, but can I even be sure I understand it? Will I know that I have found what I have been searching for? Will I be able to report the crux of the matter as an issue so that others can understand me? This truism is even more applicable when looked at from a systems-design perspective: Design the data first, because there are no mutations without proper invocations! Getting this locked-down from the beginning will make the system more resilient and legible.
Being able to fix things when they break is not the only reason to understand the entire ecosystem of the thing you are working on. Like the old saying goes: "If all you have is a hammer, everything looks like a nail." Modern software development is an extremely delicate and fragile ecosystem composed of development environments, versioned interdependent transpilers, renderers, builders and target platforms. Even though Quasar takes much of the pressure off of programmers, it does not change the way TCP, HTML, CSS, JS and JSON work. Having a mastery of the fundamentals (including reading the SPECs) literally changes problems into creative opportunities.
For me, writing has always been a tool to achieve understanding. I give myself a task, and through the process of writing about it, I come to understand it better. Some people (especially the Typescript gurus) say that great code is self-documenting, and if this is true, then the best documentation of code is its evolution. This is what git repositories give you for free - an entire history of all changes "published" to the repository. When combined with the iterative documentation of a semver-based API and its functionally reactive classes' properties, it becomes easy to talk about the project in its current state. Just remember: without a history, nothing ever happened.
Using cracked software and stolen fonts for creative work always felt dirty, but it was what everyone else at the university was doing. We told ourselves that it was ok, because we were learning. After a decade of working only on Linux systems and collaborating on open source, I have little sympathy for software thieves and prefer not to work with people who steal software. Especially as developers we have to serve as role-models for the rest of humanity. Even though I work on a Mac system, I only use software for which I have a viable license and I prefer to use non-proprietary software whenever possible. Be excellent and militant in this regard, because everyone in the open-source universe should be honoured to give and receive this mutual self-respect.
The Black Hole
Image memed by Reddit User xaxaxa_trick
Before I discovered Vue.js and the Quasar Framework, my software projects were generally hobbled together from snippets I had collected along the way and my repositories were heavier than node_modules. I never really found a framework that I immediately stuck with, and I tried more than a few. Don't get me wrong, I did make some exciting art installations and archives, but what I had done could never be called "best-practice" because it felt like I was always learning something new. As long as it worked for me then I was happy. I can't count the number of times I told people: "You just have to use the latest Chrome browser." Looking back and in comparison with how I work today, the pessimist in me feels that most of what I had done was really a collection of edge-cases glued together by stack-overflow answers plopped into a nested folders copied from found repositories...
Less is More
One day I was looking for a way to efficiently build an app for a side-project, and I decided to take Quasar for ride. It sounded like an “eierlegende Wollmilchsau” - the kind of thing that was too good to be true and served too many purposes. Much of my education as an artist and designer trained me to trim the unimportant and focus on the central issue. But after thinking about it, even for its broad scope, Quasar would let me write less code and be more productive...
I was shocked when I built my first test project with Quasar. For one, I really wasn't expecting the browser to refresh as I made (non-exceptioning) changes to the code. It really didn’t seem like it should be possible to build Cordova, Electron apps and a Website from the same code base. That quickly? Material design compliant? The build process finished already? Um... ok. I was seriously impressed. (Months later I would write an official article about this called The Quasar Method.)
If you are like me, you generally check out the readme, make sure you can live with the license and then just install the thing and see what happens. When you run into trouble, then you start reading the manual. The thing was, I didn’t really run into trouble with Quasar.
I merely used the online guide to discover all of the things that the Quasar Framework brought to the table. And there is a lot of great stuff. A LOT. So much that it doesn't even all fit on one table... I started building that side project with it, and in so doing I discovered the Discord community, because at a certain point in serious (side) projects it is just a good idea to ask other people how they solved their issues and compare notes. The competence and friendly nature of the community on Discord seemed like a fairy tale - and I was hooked.
The Genie's Toll
As with anyone granted three wishes, I immediately began dreaming about all of the things I could do with this framework. Native apps with access to the file system and the ability to call system binaries. Not having to handcraft multiple versions of the same app in order to distribute to both the mobile and desktop app stores. Quick and dirty control systems for hardware projects. Electron-based encryption-key generators. Massive networks of connected apps sharing a distributed P2P filesystem and database...
Somebody had spent a lot of time building Quasar according to the very principles that I live my life by - and the feeling of empowerment was intoxicating. Soon I found that I was answering almost as many questions on the Discord server as I was asking. In the process I slowly got to know that "somebody" behind the Quasar Framework. Razvan Stoenescu - a programmer that belongs to that rare and specific class of people who is never lazy - in fact he is THE model of programming diligence.
Over the months I became more and more acquainted with the framework - and witnessed the infectious fervour with which the git-updates bot on Discord was posting messages about Razvan. He. Was. Always. Working. I also discovered on the Discord channels and in the forum that there were a few types of questions that were asked repeatedly. Questions about testing, about icon sizes, about typescript, about ways to use Sketch and even how to follow accessibility standards like a11y. Questions that needed to be addressed because they were questions that bothered me too...
+1 Pencil of Wisdom
One day I discovered a tiny little icon of a pencil at the upper right hand corner of one of the doc pages. I clicked it and was teleported to an editable fork of the page I was reading - and suddenly saw a spelling mistake. I changed what had bothered me, committed it and made a PR. It was really so utterly easy that it became a little infectious. I started seeing little mistakes everywhere, and then I sat myself down and went through all of the doc pages and made a big PR from the comfort of my IDE. This is an exercise I wholly recommend, because not only did I help the community, I also learned a great deal about Quasar's inner workings.
At some point I suggested an improvement to the language of the Patreon page, the landing page of the website, the wording of some CLI messages. And then Razvan and I discussed starting a blog at Medium. I made a proposal for a testing mode of quasar-cli and a cross-platform webpack plugin as a factory for creating all of the icon types ever needed by Quasar artefacts. After some initial guidance I started working on these projects, and their releases are now part of the roadmap to Quasar 1.0. We began having strategic meetings, finding technical partners and discussing who to invite to our staff and what tasks we should give them...
People who stand out on the Discord channel are those who are not only helpful and friendly, but also creative problem solvers with both a drive to do things right the first time and perseverance to see things through. Having a few successful pull-requests is also a great way to show commitment and awareness of what makes Quasar unique.
Every day is different, but there are similarities. Today, for example, I sent Razvan the weekly reminder of things on my list that I need him to take care of. I helped someone in our Patreon chat understand why a specific package is installed by quasar-cli even though we don't consume it directly. I reviewed the structural composition of a proposal for our new issue-reporter. I solved a tricky layout problem using SVG markup in CSS using
clip-path: polygon(). I gave specific advice to one of our technical partners about collecting a Github authentication token. I answered a question about licensing in one of our repositories. I iterated on some logo and font proposals for our upcoming relaunch. And I wrote this article about how I joined the Quasar team.
It may be obvious to you, dear reader, that I haven't the time to work on any of my old side-projects anymore. I want Quasar to be perfect before I do any of them. They'll still be around. Even though I don't have as much time for side-projects as I would like, when 1.0 stabilises I expect that I will be getting back into more creative things. Like putting together a 2-way binding of Sketch master files with Quasar...
Happily Ever After
If you are still interested in joining us after reading my story, if you feel qualified to get involved and you truly love open source software - please get in touch. We are specifically looking for contributors to assume task-ownership in the following working groups: Testing, Continuous Integration, Art Department and Media Outreach.
If you want to find out more about Quasar, please consider:
- GITHUB: https://github.com/quasarframework/quasar
- THE DOCS: https://quasar-framework.org/
- DISCORD: http://chat.quasar-framework.org/
- FORUM: https://forum.quasar-framework.org/
And please Vote Utopian.io for witness! They are using Quasar for the next version of their Website!