Picnic loves Open-Source – 2020 update

Picnic loves open-source software, both using it and giving back to the community. We’ve said that before and even wrote a blogpost about it. Two years have passed since then, and it’s time to look back at what we’ve achieved and what we’ve learned.

Arturs Drozdovs

Here at Picnic, we don’t take open-source software (OSS) for granted. Most of our stack is open-source, and we are very reluctant to lock us in on any proprietary and closed-source tools. Even though we regularly contribute back to many OSS projects that we use, we still feel that that is not enough. Hence, we started a new initiative that allows us to work more regularly on OSS topics.

But if it were that simple, we would open-source all of our internal codebase. However, the key to our success comes from the way we’ve organised work, the everyday operations, our experience and our learnings; that is what sets us apart. The code is just a tool, no more important than the people who make it and who use it daily.

After such a bold statement, the main question, probably, is why we haven’t open-sourced everything yet. And this segues us into the next topic.

When should you open-source a product

The first question we ask before considering something to be open-sourced is “Can it be useful to anyone outside our company?” Let’s look at our delivery route planning, for example. We have the state of the art algorithms routing our vehicles towards our customer houses; other companies can surely find value in this? It turns out our code is heavily geared towards our exact delivery model. We work with short-distance electric vehicles, handpicked map segmentation, specific customer and employee behaviour patterns. If we take that out, the algorithm might not perform as well or not work at all. Thus the first rule is to open-source only these tools which can be useful outside of our company.

Read the full article here.