As I understand, the snowplow stream collector is built on Akka, and Akka is moving to the BSL. What consequences will this licensing change have for the usage of snowplow collector? Will it mean that snowplow collector no longer will receive security patches, or that license fees will be owed to lightbend when using the collector?
Or is this just a we don’t know what hit us (yet) situation?
Hi @martijnhoekstra, thanks for raising this. You are correct, we are using Akka HTTP and so we’re already looking into it. Once we understand the consequences better, we’ll do an announcement on what this means for our users, and a plan of action on our side, if any.
hi @stanch how can i get my hands on snoplow opensource contribution faster. i am facing difficulties in understanding the codebase.
Hi ujjawal-4664! Please can you make a new thread about your codebase troubles? We can help you better then 
Hi @martijnhoekstra, please see our response here: Akka License Change.
Nice! Do you need/want any community help? I personally wouldn’t stake much interest in an Akka community fork, but if it’s just basic use of akka-http in the stream collector, swapping that our for http4s is something I wouldn’t mind sinking a day or so in.
Hi @martijnhoekstra! Thanks for this kind offer! We actually use http4s in a few other components, so that does sound appealing.
Now, for full transparency, Collector — or its HTTP server part to be specific — is the component that receives all the traffic and also is responsible for the cookie logic that can make or break tracking. So we’d want to be extra sure that there are no regressions in terms of performance or functionality.
The performance aspect means that we might take a while to merge such a PR (or at least to make the new implementation the default) as we carve out time to run stress tests. We might also ultimately conclude that we need a faster framework, but I don’t know if that’s likely. For what it’s worth though, maintainability/familiarity is important, and http4s does match the rest of our stack.
Functionality is trickier because existing Collector tests are using akka-http-testkit and would need to be rewritten as well! A test suite trivially compatible with both akka-http and http4s (or maybe even completely framework-agnostic) would really help ensuring we don’t break anything. On our end, we are working on integration tests (Docker-based) that would define the Collector protocol more strictly. In the meantime, however, migrating the unit tests off of Akka already sounds like a valuable contribution, and maybe could be a good first step in actually replacing Akka.
I am probably making it scarier than it is, but just wanted to set the right expectations If you are still interested in helping out, that’s great! We can take it to Github or discuss more details if you prefer.