An interview with the dev behind Junk-Store

Early last year, I approached Eben Bruyns, the developer behind Junk Store, with the idea of doing a short interview. It would be a brief Q&A covering what his program is and how it fits into the Steam Deck landscape, and for someone who didn't know me from a grain of sand, it was a hard ask. Thankfully, he got back to me and said it sounded like a great opportunity ā and ever since, Eben and I have become close friends.
Junk Store is currently a Decky Loader plug-in for managing non-Steam games on the Steam Deck. It lets you download and install your purchased or claimed titles from Epic Games and GOG with ease ā all in an interface that feels like something Valve themselves might have designed.
Eben is getting closer to releasing a fully reworked version of Junk Store - not only GOG and Epic, but other platforms, generated on the fly. Emulators and non-Steam games will be ready to play with the minimum of effort. But, that's not the Junk Store we'll be covering in this Q&A.
You can find Junk Store's website here, if you'd like to read more on it!
Background and Motivation:
Q: Take us through what Junk-Store 'is' (for anyone who isn't aware)?

A: You started with the most difficult question. I struggle to explain and articulate just exactly what Junk-Store is in a succinct manner. Most people think that itās just an integrated launcher for Epic on the Steam Deck. The answer is in fact far more complicated and difficult to articulate. I will try my best to explain it briefly.
The less technical explanation:
Junk-Store is an open and extensible launcher framework and platform. Itās not a single launcher but itās every launcher. If you have the know-how and technical expertise you can extend it, launch any game from any platform using shell scripts and helper applications without touching the core plugin code at all. In fact Gog (and Epic) is implemented in exactly this way. In this way itās more like Lutris than Heroic. Unfortunately, the community hasnāt grasped even a fraction of what Junk-Store is capable of, they still see it as just an Epic launcher. Iāve actually prototyped some un-announced stuff that will blow your socks off.
The technical explanation:
Junk-Store itself is just a ādumbā plugin for Deckyloader that knows how to call shell scripts, send json to those scripts and read json from those scripts. Itās got a set of UI elements that operate on that json and in turn can call scripts defined in the json data. It does not have the concept of store fronts or APIs at all. If youāre technical at all, think of it like an inverse of zenity or dialog in linux shell script land. This is obviously simplified, but it is the general idea around it.
Q: What inspired you to create the Junk-Store plugin for Steam Deck? Was it a single issue or event which prompted you to start?
A: Iāve been a handheld PC enthusiast for a long time. Iām part of the GPD discord community and Iāve wanted a way to play DOS games through Steam with the ability to use Steam input for controller mapping for many years now. This was a major problem on Windows based machines because the Steam overlay does not work well with certain dosbox forks. The way dosbox handles display output for optimization actually halts drawing so the overlay will not draw. This meant that all attempts on my GPD win 2 using Windows were met with failure and frustration. With the Steam Deck came new opportunities, because Linux does not handle display output in the same limited way that Windows does. In fact the way SteamOS does display output is actually kinda wild and I spent a few days down that rabbit hole too. There's actually two display sessions at work, one for Steam and one for the active game. This meant that I was able to run dosbox and get the steam overlay to work very well. I was waiting for someone to build something like Junk-Store so I could leverage it to play DOS games in the way that Iāve always wanted to. As it turns out building Junk-Store was neither simple nor easy so now that Iāve done it I can understand why it wasnāt done before.
Q: There were a handful of other options to play Epic Games' media, yet you still jumped all-in for it?
A: To be honest, I never envisioned Junk-Store as being used as widely as it is. It was never specifically designed or built to play Epic Games, it was just a side effect from my design. I wanted to play retro games and built a platform that was able to do stuff WAY beyond this. If you go back through my reddit history you will see that the first version of Junk-Store I released was only managing dos and win 3x games.
It wasnāt until after I released version 0.1 that it dawned on me that I could do Epic games with it too. The reason it launched with Epic built in was because the Decky team insisted it have something usable out of the box. I wanted to release it as the base plugin for others to build what they wanted as extensions.
Version 0.3 had basic support for Epic games.
It didnāt have a login screen and it didnāt have a download progress bar. As far as I was concerned I had achieved my goal with that and I could have stopped there for my own personal needs. Iām happy to login via the CLI and not see download progress. I was also only using proton experimental hard coded as it was just a proof of concept at the time. There were still a lot of issues that needed to be addressed around proton and launching games properly, but I wanted to leave that up to users to make it meet their needs.
This was the point where the community started to find it and request more and more features be added. Steam Deck users began using this solution alongside or instead of others at this point. They liked the ease of use. Based on the feedback from users, even at this early stage, I felt I had something that could be big. So I decided to spend more time on it to make it more user friendly and adding features that I didn't need myself but that the community requested.
Q: Can you tell us about the process that led to the inception of Junk-Store?
A: I was part-way through my sabbatical after needing a break from the industry for personal reasons (Software dev and Cyber security is actually brutal on those at the top of the game, you only realise how bad it is once you stop). I was burnt out and had had enough of corporate culture and the grind associated with it. This project was a way to get my head back in the game but quickly started to look like it had applications beyond my own needs. I felt like it might be a refreshing change of pace from the industry norm.
It really was just something I wanted for myself and designed it so that the community can take it and run with it. I knew I had something awesome and actually felt guilty keeping it to myself. So I put the base source code on Github in the hopes that others would contribute to the project.
Basically itās something I built for myself that got a lot more attention than I thought it would.
Q: What needs or gaps were you aiming to address?
A: I never set out to meet any needs other than my own. The gaps are glaringly obvious to anybody who spends enough time messing around with these devices. Thereās still a TON of stuff that needs to be done to close these gaps and Junk-Store has the potential to address these issues, but itās going to take a lot more time and effort.
Q: What challenges did you face during the development of Junk-Store?
A: This is a good question, and there were many and there still are many more. The biggest issue is that not much is documented in this space, and what is documented is often poorly documented, outdated or wrong (thatās just the nature of the beast). This means you spend a lot of time reverse engineering stuff. Iāve spent weeks staring at disassembled binaries to figure out a tiny issue with something that might seem insignificant to most. It took me 2 weeks to get Epic games launching directly from Steam without the use of another launcher. The only thing I use Legendary for in that process is to obtain the command line arguments that the game exe need to authenticate to the Epic servers.
This means I had to thread a needle to figure out how to get things exactly right (and trust me, the code operates with extreme precision in that part of the launcher script), it might seem simple and easy now that Iāve already solved it but it was anything but simple or easy to get it solved. If anything is just slightly off, things will not work. To my knowledge no-one else has managed to get this process to work as reliably as I have. Itās a very subtle thing that probably took 100 hours to figure out. I thought it was insignificant, but itās the way that I WANTED it to work. Userās have reported that games appear to run better through Junk-Store compared to other solutions and I attribute it to this one piece of work (I still donāt have enough empirical evidence to claim this as fact, itās just a hypothesis for now). I donāt bend Proton to work with my solution, I bend my solution to work with Proton and Steam. This means I donāt have to fight the system and Steam can manage everything for me. This also means that Proton versions can be managed through the Steam UI so it reduces my maintenance overheads in that area. Steam can also handle prefixes without me interfering with them and causing unknown issues.
Q: I see there's been a ton of updates to it since launch, how does it feel 'progress wise' since you launched?
A: Honestly, I have a todo list thatās a mile long and itās just getting longer. To do everything I want to do, I'd need to hire a team. Itās impossible for me to complete the project on my own. Sadly, this doesnāt appear like it will happen and I will talk more about this later.
Development Process:
Q: Can you walk me through the development process of the Junk-Store plugin? What tools, what languages did you use?
A: The development process is rather caveman-like. I use a text editor (Visual Studio Code, and it sucks). All the tools I use were chosen so that it would lower the barrier to entry for the community to contribute. According to github thereās 58% TypeScript 29.6% Python 12.1% shell script (thatās a LOT of shell) and 0.3% JavaScript. These are all languages that I despise and wouldnāt use without good reason (the reason being that I wanted to have it open to as many developers as possible). Given the lack of community involvement I must say that I deeply regret choosing these tools now.
I do have some automated build processes in place on Github, but I canāt fully utilise them to get builds out to users because the Decky team have not approved these techniques and likely wonāt let it in the store.
Q: How long did it take?
A: I just passed the 2000 hour mark on this project recently. If you do the maths on that itās like working a full time job for a year. I currently work on this project from 6am till 10pm every single day. This is obviously not sustainable and I will have to address that. More on this later.
Q: You talk about the "code being available for a long time", what exactly do you mean by this?
A: The code has been listed on Github since the 29th of September 2023. It has been there for anyone to take and build on, based on their needs since then.
Q: How did you ensure compatibility with the Steam Deck's hardware and software ecosystem?
A: The hardware is actually irrelevant (provided that itās an intel instruction set), unless you make poor choices in software libraries and compilers the hardware and platform shouldnāt matter. Steam OS uses well known libraries so as long as you make decisions that work with those itās not a problem. I also keep contact with the system supplied libraries to a minimum. Flatpaks are another way around this, they are system agnostic, albeit it a pain in the rear to work with. It took me 40 hours just to get the flatpak for Gog working. Gog uses 2 flatpaks at that and that time was spent on just one.
The biggest challenge around this is actually the Steam integration. Junk-Store purposely tries to use as little as possible to interact with Steam. Thereās no fancy UI injection into menus (userās have requested these), those are fragile and will break when steam gets updated. Just have a look at how many plugins break with each Steam update. So far Junk-Store has been reasonably successful in that regard, not perfect, but not terrible either. The more you mess with systems in ways they do not expect the more prone you are to breakages. I have decades of experience doing this sort of thing. I have done many complex integrations for very critical infrastructure in my country (large critical systems run on my designs and code) and I have spent many years doing R&D to make the āimpossibleā possible. Add to that that Iāve also enjoyed a very successful career alongside this as a Cyber Security researcher, and youāll find that I have a very unique combination of skills that makes me very well suited to a project like this.
Q: What are some of the key features of Junk-Store that you are particularly proud of?
A: The feature I am most proud of, literally a handful of people are actually aware of. I built a completely configurable and extensible dosbox.conf editor in Junk-Store.
You can edit every aspect of a dosbox config file in it and if new options need to be added it can be done without touching the plugin. That code has formed the basis for every ācogā menu in Junk-Store. When youāre editing proton settings, itās the same code that drives my dosbox.conf editor (if youāre wondering why each field has a type specifier that can be changed, this is the reason). To my knowledge thereās no other dosbox.conf editor that works with a controller interface. Since I donāt officially support dosbox, itās not something I talk about often. I do have plans to incorporate this into my Gog solution in the future to make the dos games on Gog more accessible and playable in a proper way.
Technical Details:

Q: How does Junk-Store integrate with the SteamOS interface via Decky Loader?
Can you explain the technical aspects of this integration?
A: It actually does so in the same way as any other plugin. When I started this I think a lot of people doubted that I could build the solution I have. Iāve had people say that itās impossible and that my solution is magic. The reality is that itās a little bit of lateral thinking and smart design that allowed me to fit within the Decky project guidelines yet produce something with incredible functionality. Thereās also an exceptionally high degree of code reuse with it, more so than in most projects Iāve done in the past or even seen myself. I spent weeks and weeks tweaking the architecture and design so that it would work in the way it does. I had many days where I did nothing but mental gymnastics to find the solution that would fit into this awkward space. This was reworked a few times and was exceptionally taxing from a mental bandwidth perspective. There was no reference implementation for the wild idea I had, I only had my experience to draw on. Iāve led teams and architected similar things in the past but not within the constraints that I was dealing with on the Steam Deck. I know I got the design right, because I can find solutions for things now that I once thought impossible. A solid foundation and architecture can actually take you a very long way. Thereās a few things I need to tweak to allow for some really wild ideas I have, but right now I canāt focus on those.
Q: What measures did you take to ensure the security and stability of the plugin?
A: The security measures I took with this project are actually rather extreme. I made some decisions that would safeguard users from shell injection attacks and those decisions have caused me a lot of pain to design the rest of the system around (if youāve seen an error it references actions and action sets, this relates directly to this). My approach is always security first, otherwise it will fail as an afterthought. Everything I do in this project comes with a security risk, Iām constantly evaluating and re-evaluating the security implications of what I do. If I didnāt care about security as much as I do it would have been a lot simpler to just push shell commands straight from the web UI (I have seen others do this), which would have left users vulnerable to some serious attacks. Itās not perfect, but Iāve at least covered the type of stuff that your average run of the mill attacker would be capable of. Short from getting another PEN tester to review it thereās not much more I can personally do to tighten security up. As always caveat emptor, itās easy for me to build something that I canāt hack, but that might not apply to the next attacker. I do not handle user credentials directly, 3rd party tools do that. I think that a better job can be done around some of that but I donāt have the resources to tackle these issues at the moment unfortunately.
Iāve already talked about the stability aspect in the question about compatibility above.
Q: Can you explain how updates and new features are added to Junk-Store?
A: Initially features and updates were based on my needs and wants. As I've stated before, this project was built first and foremost for myself. The community always came second. That is until it gained some traction and attention.
I tend to assess issues and features based on the ability to generalise the solution. I do not solve problems for 1, but for n+1. What that means in general terms is, when I solve a problem it should be the solution to all future store fronts as well, not just the one where users are currently experiencing friction. Iām building a toolbox and workbench, not a piece of furniture. This means that the effort required and attention to detail is far beyond what is generally required to just solve the simple problem at hand.
Given the above, I donāt announce features before they are ready to release to the public. Once code is released I then have to deal with the technical debt left in the wake if the solution was not suitable to start with. Announcing features leads to pressure for releasing it.
I am also very much in the quality over quantity camp. Which is why new features and updates take so long. One storefront that works really well is worth more to me than 50 that only works intermittently. I can appreciate that not everybody shares this view point, and users can get impatient with the slower deliberate approach, so they prefer other solutions. I have always said, people are free to choose which solution and philosophy they prefer. Each user is unique, and not all solutions are suited to everyone's needs or preferences.
User Experience:
Q: How did you design the user interface of Junk-Store to ensure it is user-friendly and intuitive?
A: Honestly, Iām the worldās worst UI designer. Iām a backend dev/architect, integrations, security, cryptography, basically all the crunchy stuff nobody ever sees. This was never intended to be a tool for general use. I built it as a power userās tool. My philosophy is that the launcher should be invisible and stay out of the way. By some stroke of luck my backwards approach to UI resonated with people. I was lucky enough to have one UI dev contribute to the project before it was released. He did a fantastic job polishing my horrible UI up and making it what it is today. Unfortunately he got very busy and has not been able to contribute as much time to the project in recent times. However, Iām very grateful for the help he provided. Junk-Store would not look nearly as nice as it does without his help.
Q: What feedback have you received from users since the launch of Junk-Store, and how has it influenced subsequent updates?
A: Most of it has been great and the vast majority is positive. A lot of users have told me itās the best solution bar none by a country mile. There's even a reddit post that goes on about how Junk-Store is 'Genius'.
Unfortunately, this is the internet, and the vocal minority in the community are the loudest. Some feedback has been rather disheartening and even demoralising at times. Itās really challenging to stay positive and motivated when this happens but I try to brush it off and move on. Hereās some examples of that:
The lack of some difficult to implement features, such as cloud saves, are 'deal breakers' or the lack of Gog galaxy achievements 'completely devalues the achievement' of Gog integration.
Itās like I gave people a donut and all they can see is the hole. They only see what Junk-Store lacks compared to other solutions, not what it could do in comparison. The fact that Junk-Store is completely extensible is lost on most users. They also don't fully understand how much effort it took to get Junk-Store to where it is today.
As I've stated before, Junk-Store is built in such a way that users can write scripts to meet their needs. If they are so desperate for cloud saves, download queues, achievements or other store integrations (or whatever feature) they can add it themselves. Likewise, if they think it will benefit the community they can create a pull request so we can add it to Junk-Store for everyone's benefit. Junk-Store is afterall, an open source community project. Cloud saves is one area in particular where putting a half baked solution out will do far more harm than good, but if they are happy to roll their own solution the option is there for them.
I take immense pride in every single line of code I write. If I cannot provide a top grade solution that Iām proud of and trust with my own precious data I will not release it to the public. Users are not guinea pigs and shouldnāt be treated as unpaid testers. Even my ābetaā quality code is only labelled beta because it hasnāt had enough users and systems try it, but itās the best quality I can produce with the limited resources I have. Iām not a dev that releases half baked solutions, they might lack features, but those features I release need to be as solid as I can make them given the circumstances. The Gog solution has had no issues reported to date, Iām not saying there are none, Iām just saying that users havenāt run into them so they must be edge cases only.
Community and Contributions:
Q: How important is community involvement in the development and improvement of Junk-Store?
A: Iām glad you asked this question. The bottom line is that this project will fail without community support. Itās not possible to sustain it at the current rate.
Ideally, especially with OSS projects, at a minimum users would report bugs. However, in my experience they don't. Instead (I have been told by someone) they just stop using Junk-Store. We don't know if it's due to lack of knowledge on how to do this, or they don't fully understand that community projects require them to participate. Instead we are constantly having to chase bugs by actively scouring the internet for issues people are discussing but not reporting. In some cases, when we ask people to submit a bug report and provide them with the Github link they don't, we have to write it up ourselves. This is not a unique issue to Junk-Store, we see it all the time with other plugins too.
Another area where we need more involvement from the community is in helping each other. When we spend hours helping someone out, we would expect them to pay that forward and help out another user where they can. The reality is that once they get the help they need they disappear, or don't engage anymore in the community spaces (unless they need more tech support).
We would love to have any contributions towards the project, but instead people have the expectation that we will continue to do all the heavy lifting.
If the community expectation is that we continue to cover all of the above as well as development, then our expectation would be that they contribute via patreon or ko-fi.
This is the main reason I put Gog behind a paywall; I hoped it would encourage more community support. Nobody was contributing when it was 100% free and the community was demanding more from me constantly. I took a fair amount of abuse for this decision, but the reality is that good software takes time and money to build. If you take a look at other open source solutions in this domain you will see that they donāt have a lot of active development because the devs work on it in their spare time. If people were more understanding and more willing to support these OSS projects you would see faster improvements and growth.
Q: I see you have Patreons, how involved are they in what you do with Junk-Store?
A: I donāt have many Patreons, but I am eternally grateful to the ones I do have. Unfortunately, I do not have enough of them to have a significant impact on the project at this time. If I had enough support, then I could hire a team and we would use Patreon feedback to help drive the direction of the project. Meaning they would help us decide how to prioritise features, storefront integrations and bug fixes.
When I started this project I thought that if I provided value to the user, and they were unable to contribute code, they would make a financial contribution in the form of a koha.
The reasoning behind setting up Patreon was to give those users a method by which they could help the project to progress and grow. I have big plans and some wild ideas for Junk-Store, but to bring them to fruition I need more support.
As stated above, this was my reasoning behind putting (and keeping) Gog behind a paywall. I thought this was the best way to get the much needed support and then release it once support built up. Things were going well for a couple of weeks, I was getting 5 or 6 Patreons a day at $5. Unfortunately, we found that one of our patrons put it up on a pirate site and it has now dried up. This has forced me to pivot and lose considerable momentum.
Q: Are there any notable community contributions or collaborations that have significantly impacted Junk-Store?
A: Not really, as stated before the main contribution is from my UI guy. I also have an awesome tester who has volunteered hours in the past. He has also stated he wants to be part of Junk-Store going forward.

Future Plans:
Q: What future features or improvements can users expect from Junk-Store?
A: Right now the project is on 'life support' in a way. All the really cool stuff I had ready to go has been shelved (and in some cases scrapped). Until I can find a way to make this project viable again, I'm not sure what the future holds for Junk-Store. Iām working extremely hard to figure out my way forward and how to maintain progress, I just hope what I do is enough to save it. Iām running out of funds rapidly and I will have to go find paid work soon, and then my time on this project will be reduced dramatically.
Q: Do you have any other projects or plugins in the pipeline that youād like to share with us?
A: None that Iād want to talk about at this time. Junk-Store is my sole focus right now.
Q: What are you most proud of when it comes to what you've created?
A: Iām very proud of the fact that I built something thatās on its way to have 100k downloads. Thatās not a small number by any stretch of the imagination and even giving the base plugin away free of charge doesnāt mean itās easy to get people to download and use it. I know I built something really awesome because people want to use it.
Q: What game(s) are you playing right now?!
A: Ah, yeah thatās a catch 22. When you start a project like this itās because you want to play games, then you get too busy on the project to actually play the games. Given that I work on this project 16 hours a day 7 days a week right now, Iāve got no time to play any games.
Also my Steam Deck has become a dedicated testing device (Iām installing, uninstalling games and clearing it for test cases constantly), so even if I had the time and energy to play anything (thereās a lot Iād like to play) I can't. I also canāt afford a second deck so gaming will have to wait.
Q: All my thanks to Eben from Junk Store for this interview. Do keep in mind this was from early last year, but where it was originally published has long-since disappeared. I thought it might be nice to have it posted here!
A lot has changed in the 12+ months since this was written: Junk Store itself, the development process, updates, and what Eben is working on now.
A: If you'd like to read more on what's coming up with the massive next iteration for Junk Store, then you can follow this link to see a peek on what's coming.
You can find more about Junk Store with:
Thanks for reading!!!
- PD