Innovating in the open: Docusign releases 1FE micro-frontend framework

My engineering team at Docusign recently released as open source 1FE, a new micro-frontend framework designed to enable small-company innovation and velocity in a large enterprise software company. The most common question as we were building it and later when we decided to open-source the code was, “What is the business value of making this publicly available?” followed by, “Isn’t it a strategic advantage for us to keep this to ourselves?” In an enterprise company focused on customer value, these are critical questions and often killers of initiatives that may not be directly tied to the business.

Modernization process

When I first joined Docusign four years ago, our front-end ecosystem was a giant set of unique one-off architectures. Every web app was built on a different tech stack, such as ASPX or AngularJS, used different build tools, followed different design patterns, and had its own custom CI/CD pipeline. No concept of shared code existed, as every app had its own implementation of our logging library and localized string-loading library. The net result was that each app was a unique flower, developers were not transferable between apps without significant ramp-up, and lots of time was spent maintaining all the individual apps because we had no common client platform across our client ecosystem. Worse, in order to fix common bugs, each app had to designate a developer to fix the same bug, but in their own separate code bases.

Luckily, we were at a crossroads. AngularJS was coming to the end of life and Docusign was starting its journey of moving to the cloud and back-end microservices, so we wanted to move away from our legacy ASPX monolith architecture. This gave us a unique opportunity to align our front-end engineering practices and modernize our app architecture and toolsets. We started by creating a set of key principles:

• Common shared base framework: This is designed to load the common libraries all apps needed and a shared frame that apps would plug into.

• Project independence: Each team can roll forward and back their own code without impacting the broader org. Breaks in one team’s code wouldn’t block others.

• CI/CD best practices out of the box: All apps would get best-practice tree shaking, minification, obfuscation, and code module packaging.

• Quality by design: Included are common unit test and integration/end-to-end test frameworks with supporting libraries to ease and encourage shifted left test development.

• Easy to check in good code, hard to check in bad code: The primary opportunity to inject quality or to educate developers on best practices for verticals, such as accessibility, performance, security, or globalization, is at code check-in time. Developers are often well-intentioned and will work to fix issues uncovered by linters. But once a PR goes in, injected issues are often hard to isolate and may not be discovered until a future audit, or even worse, when reported by a customer. We include linters and checkers that enforce validation at check-in time to help the developer catch these issues, along with linked documentation to educate and assist in quickly resolving identified problems.

Finally, we gave teams the ability to override these principles if they really needed to for some reason. The thinking was that while we wanted to give teams a great initial setup, they could still skip a check or override in favor of trying out a new idea.

Adoption and optimization

The result of all of this was not just our new micro-frontend system, but a whole new toolset ecosystem around our front-end developer experience designed to modernize our apps and accelerate individual developer efficiency. Yet there was no decree at Docusign that everyone MUST move to 1FE. Instead, we started with our Send application and modernized it. As other teams began to hear about the new tools, developer efficiency, app performance gains, and the improvements to the developer experience, teams began to opt in on their own to 1FE. Redundant code was removed across multiple repositories, bundle sizes were universally reduced, app load times came down across our product suite, and developers were finding it easier to “guest develop” in other teams’ code bases, since they already knew the tools.

As an example, in moving to 1FE, our Sign app team saw the minimum time from build to production deployment go from six days to less than two hours. They saw a threefold deployment frequency increase, and rollbacks became 96 percent faster—from over an hour to less than three minutes. Page load reliability went from 99.96 percent to 99.993 percent. More importantly, developers loved working with the new toolset and felt empowered and encouraged to identify and develop further in-team efficiencies as well as contribute their own ideas to 1FE.

Transition to open source

As our engineering teams realized these gains within our own products, it was clear that this was a monumental shift for Docusign, and I began to float the idea of open-sourcing 1FE to the broader industry. I’ve always been impressed by Meta’s release of React, Google’s Angular app framework, and Vercel's Next.js. None of these companies had to open-source their toolsets; furthermore, no strategic or business advantage was directly gained by doing so. These capabilities could have been kept as internal accelerators. Instead, these companies decided that the entire industry would benefit by having them available and that the frameworks themselves would be improved by the community’s funding of additional capabilities and improvements.

Previous Docusign contributions to open source mostly included code samples and SDKs to help partners build third-party solutions, but opening our 1FE framework would be a new type of public contribution. As I pursued the idea of open-sourcing 1FE, I feared the inevitable questions:

• Will investors see us as distracted from our core business?

• How will we maintain and support it going forward?

• Will anyone actually want to use this?

But the reality was very different. Internal departments across the company were supportive and helped us along. Legal helped review the project to make sure that our license was truly open and that we weren’t accidently giving away core Docusign value or secrets. The dev marketing team helped bolster us by incorporating it into their marketing messages and giving us opportunities to speak at conferences. Product and engineering leaders across the company were thrilled, as they had seen firsthand the value 1FE created for us. What we hoped was that other companies in the software industry would adopt 1FE; leverage it for themselves; contribute ideas, fixes, and extensions; and ultimately help improve end users’ experiences of scaled software product suites across the industry. I also hoped that front-end developers might see the innovation we were building, decide that “Hey, maybe Docusign is an interesting company to work for!”, and help us attract more talent.

Ultimately, whether anyone adopts 1FE and deploys it in their own company is to be seen. We may get crickets chirping in the night and not have a single taker. If so, that’s OK. We’ll be proud of what we’ve built and how we’ve re-invented building Docusign client web apps. But we do hope that others find value and start to use it and share feedback with us. Good, bad, or indifferent—we will learn and continue to improve and grow as engineers. It’s a big risk “innovating in the open,” but for Docusign, we’re excited to share.

Additional resources

• 1fe official site

• 1fe open source on GitHub

• Docusign open-source catalog