• SoftwareBurger

last modified May 4, 2019 by danielstrypeybruce

There's an old saying that you don't want to see how the sausage (or the burger) is made. But that's what peer production is all about! Yet, because free code burgers are often made out of other free code burgers, or used in other free code burgers, and sometimes even used in proprietary burgers, it can be very confusing for people new to the field to understand how all the different burgers fit together.

What if we had a website that visualized any given software package as a Software Burger, showing all the stack of files and dependencies that package is made of, as the layers of ingredients between the buns? Different kinds of ingredients could be different colours, one colour for files created for that burger, and another colour for external dependencies. Clicking on any dependency layer could take you to the Software Burger page for that package, and so on. Burgers all the way down to the basic nuts and bolts. Maybe layers could even be opened up and closed on the same page, like a folder hierarchy being opened in a file manager.

Software Burger could help hackers working on related projects avoid reinventing the wheel, and instead combine their efforts on high quality back-end components, while making sure each front end serves a specific subset of users. For example, media hosting packages could share generic back-end components, while working on multiple UIs aimed at different use cases; photographers wanting a public web gallery and simple editing, or groups wanting to host a range of media on a shared interest. Just as importantly, Software Burger could help end users who are not developers or software freedom activists to understand the relationships between all the different brand names they hear about.

Some of the data that Software Burger would visualize is probably already in the Free Software Directory, and if the FSD admins like the idea of the project, that would be a good place to store all of it. Software Burger could either be a separate site that used the open data from FSD as a base, or it could even be integrated into the FSD as a feature.

Existing examples of dependency visualization


Freshness Metre

The page for each package listed on the SoftwareBurger site could also include a 'freshness metre' so people can see as a glance if a piece of free code software is still in active development. Commits to the source repo would automatically keep the freshness rating high, but if there's no development on the source repo associated with the software for x months (eg 12), it 'goes off'. If for some reason, the project is still alive despite no commits (eg it's a simple library that hasn't needed any in the last x months), the developer can manually check it to keep the metre set to 'fresh'.