> Very cute that there's a one click deployment using some semi-magic third party service

The author of the repository seems to work for that third party service so feels more like a proof of concept for deployments to that service.

This is the problem with open source, anytime someone tries to submit a finished solution - someone will come out of the woodwork and blame them for not attributing enough. In this case the link exists, but it isn't in the favorable order.

That seems disingenuous don't you think.

The only thing they added was a dependency on a closed source 3rd party """cloud""" service. This is basically the open source equivalent to blog spam and should be rightfully put down.

And the post you're replying to isn't even trying to do that! Its just suggesting that hacker news would find more benefit out of the original repo over some closed source cloud bait made by an employee of said proprietary cloud service.

This is a little aggressive. Sure, Balena offers a proprietary licensing to make money for their cloud software, but all of the technology is built with open source first. You can self host OpenBalena (the open source parts of Balena) and do your own deployments locally. I'm not sure if going after open source projects that can make money is the best way to promote open source software.

> I'm not sure if going after open source projects that can make money is the best way to promote open source software.

but im not doing that.

I'm going after open source projects that can make money (by building closed source infrastructure) taking other peoples open source projects and moneifying them into a new """open source""" project (where 99% of the meat is in closed source cloud infrastructure) as a way to piggy back off of the work of other people so that they can advertise on hacker news.

Like, if the repo actually added something substantial and new to the project, that would be one thing.

If this was an article that explained how to do the gluing/config work this github repo does, also, another thing. even if hosted/made by the cloud company. That at least appeals to the intellectual pursuit.

But this is just some config files.

I believe you mean open source infrastructure

RPiPlay is itself composed of many great OSS projects (e.g. GStreamer). Maybe we should somehow be able to publish the shole "tree" of contributions to a particular project (including build-time tools) ?

Yeah, personally my view is that if an OSS project contributes something new to the existing tool then it should be acknowledged on a place like hackernews.

Also, because acknowledging the project you built on top off recursively references other tools, there is no need to publish the whole tree. That exploration is left as an exercise to the viewer of the repo.

If we had a reliable way to identify contributors there might be nice ways to build on top of that. Like semi automatic donation services that uses id keys of the list of contributors.

Never going to work. Someone will cheat the system by creating multiple identities in order to get more than their fair share. Besides, how do you even measure what’s fair automatically.

And likewise, automatically distributing money per dependency will just make people split projects into multiple parts to get more of the money, or to add fake dependencies.

Donations need humans in the loop to decide where the money should go.

That's why I said semi automatic. It should always be up to a human to decide exactly who gets the money and how much. But there could be systems that makes it easier for that human to make such decision and worry about the important parts of it.

The automatic parts can consist of listing candidates, link to their contributions and handling of the transactions, not selection.

I just remembered the drama a couple weeks back about some library for coloring terminal output...

People do stupid shit for fake internet points and fame already, I wouldn't put cash into that equation

We already have put cash into the equation. There are donation buttons on many repos nowadays. Should we fight against that or should we try to make better use of it?

That should mitigate against fake dependencies, but not splitting important projects into multiple equally important projects, unless this engine also incorporated something like SLOC or number of commits (either of which would make splitting a net zero) but those are non-metrics as well...even more readily abused.

Not following what your point is here? I'm not promoting metrics. I'm just saying we should allow lifting up the whole software supply chain for donation driven projects.

Just saying how any tooling to automate the process would be easy to game all the way down, so the due diligence toward donating has really got to be a manual human effort.

So like an attribution manifest that contains direct contributions and links to other OSS manifests? Then you could just have a project walk the manifests and generate an output of everyone who contributed?

There is a link at the bottom of the readme directly to RPiPlay.

Yeah, I saw that. My point is: considering the title of this submission, I'd rather see it linking to the people that actually built the software that does this airplay mirroring.

As it stands, this is a submission of "a one click deployment of rpiplay to balenacloud" or something like that.

Exactly. This is more interesting as an example of how to use the balenaCloud software to deploy code across a RPi fleet. It isn’t very exciting for an airplay server as that code is provided by rpiplay.

It’s all about setting expectations. I saw this title and was excited because I thought there might be a new airplay server available (airplay 2 even). Then I saw what the project really was and I was disappointed.

The history of airplay he gives on that page under the 'AirPlay protocol versions' heading is worth a link all by itself.

There's so much technical debt and conflicting versioning with AirPlay it's unreal. It's amazing it works at all at this point. It's also why the developer documentation is awful.

Wow, what's even the actual work besides creating some wrapper config files with other names for the parameters?

The wrapper itself? Isn’t Unix philosophy to build up software from simpler components? The project is also quite prominently attributed.

It seems like the original project is easy enough and does not need a wrapper. Building a wrapper this thin reminds me of the Hacktoberfest "contributions" to projects.

Maybe the problem with posting this instead of the original project is akin to posting a homebrew formula github repo instead of the actual tool. However many projects now use github as a way to have canonical paths to stuff so here we are. You need to host the wrappers somewhere right?

When you need to create some software, I guess you start by writing your own OS first? This is how all OSS works - you build on top of other projects.

I think what people are complaining about is the fact that the linked project is not the project that actually solves the problem stated in the title. This linked project did not enable “using a raspberry pi as an airplay server,” it just packaged someone’s project that already did that.

If you're not melting your own sand into silicon ingots and slicing them into wafers, are you even a real programmer?

Having someone smoothing over the out of box experience for a lot of OSS is of value to me. A lot of projects I undertake get bogged down or stymied by setup instructions that trivialize or one-line non-trivial tasks (e.g. setup OpenCV, configure a reverse proxy in Nginx, etc).

A lot of this comes down to the fact that software moves quickly and instructions are written for a given piece of hardware on a specific version of a distro.

One of the benefits of having a common platform like the Raspberry Pi or shipping Docker Images is that you can ship a MVP that anyone can easily setup like Hassio, Pi-Hole, or PiWebcam.

If open source maintainers or producers don't owe anything to their users then I don't see why people building projects with open source material/code should do more than the bare minimum required by the license.

Are an open source license terms ignored here ?