At Gilt, our open-source contributions generally come in the form of tools that we use internally that we think have value to the rest of the tech community. But like most other companies, we have internal systems that are very specific to Gilt. This makes open-source contributions tricky because our potential projects and tools are so tightly coupled to our systems. We wanted to bridge this gap and decided to do so through a tiny front end initiative we called Open Source First.
For example, our front end architecture consists of over 100 requirejs modules that are bundled and served by an in-house legacy build system that is as tightly coupled as a ball of rubber bands. And, our internal requirements make it necessary that we wrap requirejs which means we oftentimes aren’t using off-the-shelf versions of each module. These modules depend on each other in ways that would make spiders jealous. It works. It’s stable. And once the learning curve is conquered, we defend its design while sipping our orange Kool-Aid. But, it makes open-sourcing any of these individual modules just about impossible.
The Special Operations team (Kyle Dorman, Jose Sanchez, Archana Kumar, and myself) set out to create a pattern by which we could open-source modules that could be used by the greater tech community without sacrificing any characteristics of the module had it been developed internally. We used a project that we had just finished called OAFE (Open App From Email) as the basis of this experiment. OAFE is one of those mobile-web user experiences you see that asks “if you’d like to install the app.” Internally, we have a lot of discourse about whether this is a good experience for our users or not. As a result, our implementation of OAFE is a little complex. It tries to be the best experience for people who want to be redirected and people who want to stay on the mobile web. OAFE was a perfect candidate for an open source project because it needed to be implemented on two completely separate code basis (Gilt and Gilt City).
We created UBAR (Unidirectional Browser App Resolver) as an open-source first module that behaved as OAFE. Our goal was to write a front-end module that could be easily consumed both by our current system and externally. We did so without sacrificing any internal requirements or features. Are we expecting that other people are going to use UBAR on their websites? Frankly, no. So, why go through this exercise of creating open-source modules? This is where the learnings happened that ultimately forced us to think better and harder about our work.
5 Key Learnings
- PRIDE Your code being publicly available instills a sense of pride. This is our work. This what we are capable of doing. This is how we do it. We want it to be great because we want others in the tech industry to appreciate it. As a result, we are quick to make fixes to bugs and quick to make improvements to make it feel better. Since it’s something we want to be proud of, we all felt an energy of wanting it to be great. It has been a great team-building exercise.
- GIVING BACK We shared our creative process for implementing an open-source module so that we could inspire others to do the same. For so long, we have taken from the front-end community without giving back substantially. This is our attempt to give back, just a little. It feels good.
- CODE LEGACY Regardless what happens with the feature, the engineers on the team have a really cool sense of pride for their work. The hard part about working on websites is that features are pulled down as frequently as they’re put up. This is our way of giving some legacy to the code.
- WORKFLOW In the chance someone wants to use our open-source module, they can contribute to it. This allows input on our work from sources that we don’t necessarily interact with on a daily basis. One of our team members left the company during the development of the feature but since it was open-source, she was able to continue tracking its progress.
- BETTER ARCHITECTURE Open-source first completely reshaped the way we thought about architecting this module, for the better. We did not want to remove any characteristics or attributes of the module from the open-source project. We wanted to eat our own dogfood. As a result, we thought a lot about how this module could be consumed by systems that were not our own. We created a patterns for how external users could easily implement tracking analytics, template rendering, deep-link requirements, and design. Through these abstractions, our code is easier to read and less tightly coupled than other comparable modules that we created.
Gilt was fully supportive of this effort largely due to the culture set forth by our technical leadership. And, that really moves us to our last point: this made us really excited about our work. It made us bond well as a team. It made us feel like we were making positive contributions to Gilt, to ourselves, to each other, and to the tech community. It felt like good technical culture.
And since we created patterns and frameworks, it’s a technical culture that we can share both internally and externally. Going forward, we’re going to try to open-source everything, first.
To view UBAR’s source code, please click here.
To read more about UBAR and to see it on a mobile device, please click here.