Hello folks and welcome to the eleventh edition of the interview series “I contribute to Ember” , presented by the folks at The Ember Times . 
This week we’d like to highlight the work of contributor Stefan Huber AKA @st-h . Stefan talks about his web app for musicians 
, building a recording studio when he was 20 in the basement of his mother’s house 
, maintaining various Ember addons 
, and more!
What are you working on recently?
A project I started a few years ago as a side project. It’s a web application that helps musicians and music studios to organize, share and get feedback on their audio files, Stacktune.
I also maintain a couple of addons which I found missing or unmaintained while working on that project. The two most popular currently are ember-content-editable and ember-resize-text. The first one allows one to create input elements that automatically resize based on the contenteditable feature. The latter brings a feature to the Ember world that has been known to native iOS developers for a pretty long time: the ability to resize a single line of text so that it fits into a given element.
Recently, I have been experimenting with the best way to serve and update a Single Page Application (SPA) that also has Fastboot support, which led to ember-service-worker-index-fallback. The main issue was that it did not make much sense to me to serve an outdated app from the service worker when there already is a server rendered up-to-date version available, which rehydrates back into a full application. So, the addon is trying to get an updated index page first, but falls back to the cached version if there is no or slow internet connection.
What made you interested in working on that particular project?
I decided to build a recording studio when I was about 20 in the basement of my mother’s house (who was very supportive). Soon I realized that getting new mixes to clients and collecting usable feedback was quite painful. I also encountered similar situations when I was playing in bands myself. After I had studied computer science a few years later, I had some free time and nobody had yet released software to address these issues, so I decided that now would be a good time to get started.
What’s your biggest motivation to contribute to Ember?
There is no such thing as a free lunch. I strongly believe that open source projects exist because people are actively contributing to them. So, if I find something that does not work or need a feature that does not yet exist, I look into ways to fix that. Even if one doesn’t know enough about internals to determine the best way to fix things, digging around and finding the cause of an issue can save other people quite some time.
What has been your most important learning from contributing to Ember so far?
The community and how it is organized is an extremely important part of OSS. For instance: Nobody wins if we have a couple of addons that all claim to do the same thing. A few of them seem to be no longer maintained, and all others only serve very specific use cases. But if we can get all those developers to work on one or two addons that solve the problem in a generic way and maintain those for a longer period, we’re all golden.
Is there any piece of advice you can lend to first-time contributors?
Be nice and just go for it. Don’t be afraid. If you are in doubt just open an issue and ask. People usually are very supportive if you intend to improve something. Plus, looking at other people’s code is a great way to improve your own coding.
Other than that, I think addons that become stale are quite an issue. We now have adopted-ember-addons on GitHub, which I think is awesome, however it deserves much more attention. I have adopted addons in the past myself, because I was using them but noticed they no longer get updated. I had also released a temporary fork of another unmaintained addon, but luckily these days we are now able to incorporate those fixes back into the main repo. (Editor’s Note: Check out the #adopted-ember-addons channel on Discord.)
Another awesome thing I overlooked myself for a too long time is that you just can add a GitHub repo as a dependency in package.json, which is incredibly convenient if you want to fix an addon which seems to be no longer maintained. You can just add your fork to the dependencies of your app without having to go through a npm release, until you know what is up with the main repo.
How did you get started with Ember?
I started to work on a web application that I always deemed missing in my spare time soon after I got my first job as a backend developer. Back then I knew very little what was actually going on with frontend stuff and started out using a web application framework called Grails. Soon after I had put together the first useable prototype, I realized that server rendered pages will never be flexible enough and will come with the need to request data from the server where it actually would not be necessary at all. I pretty much wanted to build a page that was as performant as possible and was intrigued by the idea of a SPA, so I started to add Backbone. That made a lot of things easier, however I was quickly looking into using a framework that was more designed for what I wanted to build: an ambitious SPA. That was still back in the 1.x times of Ember.
What workflows do you have to keep yourself motivated to contribute?
I try to ask myself if this new component that I am building is something that would be helpful to other people. If so, writing a new addon might be a good idea. Plus, you might get a ton of people testing your code for free and a few who might improve it further. Other than that, it’s mostly just a matter of when I came across something that I want to be fixed or improved. Like recently I wanted to reduce the file size of my Ember app by lazily loading an add-on that only sometimes is needed. So I opened an issue and in the end submitted a PR.
Stefan Huber is working on a startup as a solo-entrepreneur / full-stack developer, where he makes use of a lot of Ember: Stacktune - organize, share and get feedback on audio files.