Why did I create OpenContext? There are many reasons outlined here, but mostly I hate wasting my time.
Hi, I’m Alice. Co-founder and CTO at OpenContext here to talk about why I’m passionate about building a tool like OpenContext for engineers and their teams and organizations. I’m a systems engineer. I went into QA, build engineering, operations, DevOps, and solutions architecture. I got mixed up in all kinds of interesting things. All that different experience meant I had a lot different perspectives.
I realized that in all those jobs, I spent a lot of time telling people where things were, or who to talk to. Who made that breaking change? Who’s responsible for this module? When you’re working with remote teams or teams across the world, it’s even harder because of time zones and distribution. It’s just so much wasted time trying to find out who owns something.
I also think there are just so many proliferating tools that we use. More API tools, more cloud tools, more CI tools, and the open source versions, it’s so much. And in a way it makes sense, because these tools are specialized, or are doing things a new way. But it gets hard to track all these things.
Back when I was at HP, it was a very simple setup, there was just the one tool, but even then, each team might use the same tool in a slightly different way. So if you moved between teams, you still had to relearn it, you couldn’t swap teams seamlessly. It seems like it should be easy, but it almost never is.
It seemed to me like there had to be a better way to understand context.
What's the problem OpenContext is solving?
People don’t have systems context. For example, development doesn’t share language or focus with operations or security. Context in this case is what people are doing and metadata would help identify that work.
A good example of this would be GitHub actions
Typically security or operations doesn't have any insight into the CI process or GitHub actions being done on development, and they don’t need the details, but if they know that seven builds have previously failed, that information might be useful to them and give them context for events that affect them. It’s not necessarily that they need to know the workflow, but having insight into who is doing what, and what tools and teams are involved makes later troubleshooting easier. It’s not easy to keep track of the interdependencies between tools, people, code, customization, delivery, and other variables.
Our processes are applications. Everything is getting more and more complex as time goes on, which means those dependencies get even more complicated.
Rethinking the water cooler for remote work
Work from home is great, and I like it a lot because I get to concentrate a bit more, but one of the things I miss about office life is picking up context casually. Because you're walking around, you're talking to other teams, you're getting coffee and you talk to this person and find out what's happening over there on their team. If you have one of those jobs that is a lot more cross-functional than most people, that kind of awareness is really valuable, like being aware that Team A is running into issues with this or that, or that Team B is trying to create the same kind of service, and maybe they should collaborate.
I used to be part of a combined cloud operations and security team and I learned a lot of security by sitting next to them and hearing what they were complaining about. I came to realize most of their time is actually not spent in finding the problems. Those things get found pretty quickly. It's finding the people, the tools that are affected by it, the code that's affected by the security problem.
They’re trying to express these dependencies as massive spreadsheets, and then contact the general operations or developer teams to find out who is going to fix the problem. But if it’s not a direct request, people tend to think it’s someone else’s problem. It’s not like anyone is assigned to them, because the security team can’t tell who owns that specific code.
There are so many inefficiencies in the whole software development lifecycle, and we keep trying to combine everything down and make it part of a developer’s job. As if, miraculously, all the problems are going to be fixed if we push the responsibility to the developer. We’re saying developers have to worry about finance, security, operation, tools, APIs, and coding. It’s a lot.
How context helps
OpenContext is aiming to add more context or metadata to people’s questions about their system, or show what their actual system versus what they imagine their system to be. Dependency maps are important, but frequently don’t have everything. Part of OpenContext is to discover those dependencies and relationships. We want to show the connection between the person, the code, the repository, and the deployed artifacts. We want to give you a high-level view of the whole system.
Part of the problem with asking developers to do and understand so many parts of our software is that everyone’s understanding of the system is limited to what they know. It’s very hard to see everything when you are in the middle of one part of it.
Security knows security, but they don’t always know how their security recommendations or rules affect operations or development. This isn’t because of malice or laziness, just that everyone is coming from different knowledge bases. Security may not know how code looks once it’s deployed to the cloud. It’s easier to prioritize fixing a bug if they understand that it’s in a front end application, and the bug is SQL injection, and there’s an SQL database that they need to protect.
Without having the context of how operations set up the database or how all the pieces work together, how will they make the right decision about fix priority? And operations experiences these questions as an interruption because they’re trying to handle other emergencies that security isn’t aware of.
We just want help so we can self-serve, and we want the content to be freely accessible across the company. We want to be able to answer questions like “is this expected behavior?” by ourselves, without having to cross team boundaries. Or at least have enough information to ask better questions
We created OpenContext as a way to help teams get high-level understanding of their systems, and give them the opportunity to find answers for themselves. If having context helps people make better choices in their work, then we’re doing what we hoped for.
Top comments (0)