Wayfair Tech Blog

A Dynamic Journey to Open Source

Have you considered contributing to open-source software but were not sure what the work entails? Maybe you heard some people even get paid to work on open source and are curious about where to begin. A good first step is to understand the common challenges and pitfalls that come with open-sourcing a new library, so you can avoid them. Come join me and the rest of the Dynamic Services team on our journey...to open source!

Who Are We?

The Dynamic Services team is responsible for providing contextualized product data to Wayfair’s customer-facing e-commerce platform. What does this mean? We take in requests for product data and information on customer context (what category the customer is in, where they are on the site, and how they arrived there) and from there we return product data that is relevant to that customer based on that context. For example, we might prioritize showing details about commercial standards and compliance to a customer who is shopping for office furniture. (Learn more about how we ensure our services are highly performant here!)

How We Started Our Open Source Journey

Our team builds and maintains services written in C#, using .NET 6. Like many other teams at the company, we contribute to shared libraries that are developed at Wayfair. We also count on these libraries to help improve our development experience and add features we all can benefit from. For example, many teams access relational databases in their work: improvements to database access become a shared library re-used across many teams.

While many teams contribute to these libraries, there is no central owner. Instead, they have been maintained through altruism and an appetite for off-sprint work. As a team, we were tossing around ideas for attracting additional contributors as well as expanding the reach and features of these libraries to outside of Wayfair. After all, we couldn’t be the only engineers who needed the useful features our internal libraries offered.

Then, we heard the call…from the OSPO!

The Open Source Program Office

Wayfair’s Open Source Program Office (OSPO) is a dedicated team that helps engineers do the following:

  • Adopt existing open source solutions
  • Contribute back to their favorite open-source projects
  • Open-source existing solutions they have created
  • Build new open-source projects from scratch 

The OSPO’s timing was perfect. They were looking for partners and we wanted to evolve our internal libraries to outside the company where the larger community could benefit from them. We began working together and the OSPO helped us identify a place in the open-source ecosystem where we could provide functionality not yet available. They also helped us select several good candidates for release to the public (more on those in a bit).

The OSPO also offered us an Aux Eng partnership. For those not familiar with the Auxiliary Engineering model, it provides an engineer experienced with open source and who would work with our team for the quarter, helping us adopt best practices and overcome common challenges.

How could we say no?

Putting In The Work

We were feeling very excited about our open-source future, but it was time to roll up our sleeves and get to work. First, we focused on improving the quality of existing internal libraries and ensuring that things like documentation and tests were up-to-date. This work gave us a good reason to publish final versions of each, complete with future deprecation notice. This notification tells those currently using the internal libraries that we are planning to open-source them and if they want to continue receiving updates, they will need to adopt the new open-source versions.

From there we created a “staging” version of each library and got to work ripping out dependencies or implementation details specific to Wayfair. This is an important step because it certified we weren’t exposing details of our internal systems which shouldn’t be shared publicly. We also ensured that the library wasn’t assuming that our users would be interfacing with our internal services or other systems. For example, we updated one library to require the user to specify connection details rather than assuming they’re connecting to a Wayfair database.

Four weeks later, our first library was ready for prime time—we would be migrating it to a public repository on GitHub! The OSPO was a huge help here. They provided us with this great repo template complete with a code of conduct, contribution guidelines, and templates for pull requests and issues. At this point, all that was left was to name the newest library…what should we name it?

Quick Tangent: What’s In A Name?

There are only two hard things in Computer Science: cache invalidation and naming things.
- Phil Karlton

We’re certainly not the first to discover that naming things - or, at least, naming things well - is difficult, and nothing drives up the stakes like knowing your coworkers and the internet at large will be judging your choices. We spent weeks kicking around names, and were guided by these priorities:

  • If possible, the name should give you an immediate understanding of what it does
  • It would be great if the name reminded you of its Wayfair origins
  • It would be nice if it indicated the language/framework, though that’ll usually be obvious
  • …failing to find a good name using any of the above: pick something cool!

While this may seem obvious, it’s also important to check that your desired name is available on the platforms relevant to you (in our case: GitHub and NuGet) before getting attached to it. For one library, we were open-sourcing a solution that improved functionality built into .NET. We had envisioned naming it to match the library it extended, but unfortunately, we learned the hard way that Microsoft had reserved a portion of that name on NuGet. The package failed to publish and our big moment was postponed. From there we scrambled to quickly pick a new name and get our libraries out into the world.

The Big Reveal!

I’m happy to report that we were able to release three new libraries to the .NET ecosystem:

  • WaySON, an extension of the JSON Serialization/Deserialization functionality of System.Text.Json to support additional types,
  • Gossip, which adds to the functionality of Dapper and allows you to perform database queries in .NET quickly and easily, and
  • AeroSharp, a wrapper around the .NET Aerospike client for features like serialization, client-side compression, and policy validation.

It’s very exciting to see these gain traction outside Wayfair: at last glance, WaySON already has more than 15,000 downloads! Now we’re looking forward to seeing feature requests - or even bug reports - from new contributors. While we wait I should also point out that we’re also using these libraries in our day-to-day work, having cut over from and deprecated the internal libraries, so we remain very invested in their quality and usability.

In The End

Getting to really dig in on the work of open-sourcing these libraries was a great experience for our team. We learned quite a lot about the internals of libraries we use daily, and even found and documented some “hidden” features! We also came into the project with varying levels of open-source experience. Fortunately, everyone quickly adapted and was able to contribute with the support of the Open Source Program Office.

With this experience and armed with new knowledge of open-source, we now look forward to identifying additional candidates to release to the world as well as opportunities to incorporate open-source solutions from outside Wayfair in our work.

Want to help us reinvent the shopping experience and contribute to open-source at the same time? Come work for us!