Anyone in charge of maintaining an open source project will tell you that the more popular your code gets, the more feature requests you’re likely to receive. Before long, you may end up spending more time addressing developer issues than creating new code. But for many developers, that connection with the community serves as a source of motivation and invaluable feedback to better help others.
In this installment of the On the Platform interview series, Slack open source engineer Alissa Renz chats with East about Block Kit, the advantages of open source development, and what it’s like to build for the Slack API.
The following is a condensed transcript; answers have been edited for length and clarity.
Working in new ways with Block Builder
Alissa Renz: You made a switch from product marketing to product management, and now you’re writing most of MacPaw’s internal Slack apps. How was that transition?
Ray East: Initially, I didn’t know anything about web dev at all. But working with a large development team, I quickly became more familiar with the concepts. The more I dove into the technical side of things, the more interested I became.
During a hackathon in 2016, MacPaw made Fix Bot—a digital tool that gives kudos and recognizes the efforts of teammates in a fun, quirky way. This provided me with the opportunity to work with the Slack API, and it’s just one of the many apps I’ve helped create since.
Renz: Let’s talk about how Block Builder came to be. What was your motivation to make it open source?
East: We were creating a lot of new applications at MacPaw, with a variety of user interfaces, and wanted to find a way to make it easier to prototype flows and shorten the amount of code needed to build them. That’s how I came up with the idea of Block Builder. I figured it might be something others could benefit from as well. That’s why I decided to go open source.
I approached the project the same way I do when building a new product. Get an MVP shipped as quickly as possible, gather feedback and improve it from there.
And that’s when it made sense to invest in improving the underlying code; changing the library’s architecture, using TypeScript and setting up a CI pipeline to make it easier for both myself and other contributors to improve Block Builder.
Renz: What has been the biggest advantage of working in open source software?
East: Your decisions don’t have to be about making money; you have a lot more freedom than with commercial software. And because you’ve invited other programmers to be a part of it, that provides the motivation to do the best job possible. I also love open source because it provides a means of seeing how others think and write code through community interaction, which is a great way to gather feedback, learn and grow.
When you see a pull request, it means someone is really familiar with your project. Not only that, it tells you they use it, find it useful and rely on it. That’s a motivator. If you’re just one person, you’ll always have tunnel vision. Open source can provide a lot of insight on your project and how people are engaging with it.
But once you get it out there, you’re responsible for the pull requests or feature requests. You have to stay on top of it, and you have to be constantly communicating with other developers. It’s an effective way to hone your skills.
Bringing automation and predictability to work through Slack
Renz: What has your experience been building for Slack compared to other services and APIs you’ve worked with?
East: Slack is very predictable. You can focus on what to build instead of how to build. You have a ready UI kit with contracts in place for the front and back ends to interact. Security is also not a big concern if you’re using something like Bolt, especially with Socket Mode.
Slack also makes it easy to reduce overhead by automating jobs and maintenance tasks. It’s faster and cheaper to automate jobs you might not otherwise spend money on. These things make other colleagues’ lives so much easier and free up headspace to make a greater business impact.
At first glance, most Slack apps look simple. But the sky’s the limit for what you can build and how complex you can be. For example, at MacPaw I’ve built roles and permissions that sync with our HR platform so we can build flows for specific individuals or teams. And there are flows in place to manage those roles and permissions, and a lot of other stuff around administrating our apps. But even then, you’re focused on core business logic instead of APIs, UI details, etc.
Renz: Aside from reducing overhead, what are some other challenges that Slack has helped you overcome?
East: We’re growing fast at MacPaw. It can be hard to tell when someone is out of the office or just unavailable. But at the same time, we’re concerned about overstepping each other’s boundaries.
We created a Slack app that syncs directly with our HR platform. If someone is on vacation or out of the office, their status is updated automatically. I’m about to add a setting that allows employees to automatically set “do not disturb” for certain time-off categories. We live in a very chat-centric world, so it’s helpful to have tools that both eliminate confusion and foster healthy boundaries.
Using open source to build like a pro
Renz: What advice do you have for folks interested in open source programming but not quite sure where to start?
East: Just sit down and prototype it. If you have an idea you can’t get out of your mind, get a working version of it as fast as possible.
Open-sourcing code can be a psych-out moment. And if that’s the case, get out there and check out how others are building and documenting their libraries for some guidance and inspiration. Maybe even start by contributing to a few of them to get a feel for the open source community. Then, get the work out in the open and let it evolve from there.
Renz: What tips do you have for those building an app for the first time, or building tools specifically for Slack?
East: First, use GitHub to search for tools that already exist. Block Builder is one, but there are other repositories out there. There’s no need to reinvent the wheel when you get started. Focus on getting things done. As they say, the best code is no code, or as low-code as possible.
Second, get creative about your flows. Slack specifically makes it easy to get around what may at first seem like a limitation, like not having a file picker in Block Kit. But there’s always a creative and intuitive way to get things done. Move away from typical web flows and think more along the lines of how should this work in a chat environment? Cakeday is a good example. It automates the entire process of wishing happy birthday to your team members by producing a video made with various videos team members upload. But instead of uploading the file using a file picker, you just drag and drop them to a message thread. Yes, it’s a different experience. But it feels super-native to the environment.
With the Slack platform, there’s so much flexibility and opportunity to get things done and make lives easier.