Forem: Maxim Wheatley

An Open-Source Solution to DORA & DevOps Metrics

Maxim Wheatley — Thu, 13 Oct 2022 18:14:35 +0000

Hey Dev.to Friends! We're an open-source project, part of the Apache ecosystem, and today, we're super excited to share a game-changer release for DevLake - the data lake and analytics platform for your dev-data.

You can now implement DORA metrics and benchmark your projects and teams in minutes. Fast. Open-Source. Super Customizable.

We're proud of it, and hope you love it.

https://devlake.apache.org/

WTF IS DORA?!
Created six years ago by a team of researchers, DORA stands for "DevOps Research & Assessment" and is the answer to years of research, having examined thousands of teams, seeking a reliable and actionable approach to understanding the performance of software development teams.

DORA has since become a standardized framework focused on the stability and velocity of development processes, one that avoids the more controversial aspects of productivity measurements and individual performance metrics.

There are two key clusters of data inside DORA:
Velocity and Stability.

The DORA framework is focused on keeping these two in context with each other, as a whole, rather than as independent variables, making the data more challenging to misinterpret or abuse.

Within velocity are two core metrics:

Deployment Frequency: Number of successful deployments to production, how rapidly are your team releasing to users?
Lead Time to Changes: How long does it take from commit to the code running in production? This is important, as it reflects how quickly your team can respond to user requirements.

Naturally, if you are pushing a consistently high tempo, you also want to ensure that the work that is being delivered is reliable, and that downtime and failures are readily recoverable.

Stability is composed of two core metrics:

Change Failure Rate: How often are your deployments causing a failure?
Median Time to Restore: How long does it take the team to properly recover from a failure once it is identified?

To make DORA even more actionable, there are some well established benchmarks providing a simple lens to determine if you are performing at "Elite", "High", "Medium", or "Low" levels.

While DORA isn't necessarily new, implementing it has proven out of reach for many companies and teams due to the challenges associated with obtaining, unifying, querying, and visualizing the necessary data.

An inherent complication to implement DORA properly, is that the required data typically lives in many tools, accounts, and formats, making the process of compiling it difficult, manual, and time-consuming.

Team configurations and processes are often quite unique, using different delivery processes, different definitions, and different standards. Ultimately, meaning that "one size fits all" really means "one size fits nobody" when it comes to many of the existing solutions that claim to deliver DORA metrics.

All of the aforementioned is part of why we built DevLake, an open-source dev-data platform that collects, analyzes, and visualizes data from many developer tools in the most transparent and customizable package possible.

We are also excited to announce today, robust support for the DORA framework, to make it easier and more accessible than ever before for teams of all shapes and sizes to put this powerful data to work!

How to Implement DORA with DevLake:

The Sources You Need, and How DevLake Computes DORA:

Three key entities for computing DORA Metrics:

Changes: For most teams, this is simply Pull Requests (PRs), so this data will come from code hosting tools. DevLake currently supports GitHub, GitLab, and BitBucket
Deployments: This data comes from your CI/CD tools. DevLake currently supports Jenkins, GitHub Actions, and GitLab CI, with CircleCI in development. DevLake also has a custom web-hook that allows you to push deployment data to DevLake if your CI/CD tool isn't yet supported.
Incidents: This is the source for stability metrics. DevLake is going to soon support PagerDuty and Sentry to make this data even more effective.

In just four succinct steps, DevLake can turn you into a DevOps hero:

Setup DevLake: Using Docker Compose and Kubernetes, Helm, or Temporal.
Collect Data: With DevLake's versatile connectors, you can extract the data you need from many tools.
Launch Ready-to-Run Dashboards: DevLake comes pre-configured with many metrics and dashboards, including full DORA support.
Customize: You can personalize and even create brand new metrics and dashboards in DevLake with just a few SQL queries.

Once you have set up DevLake, connected the data sources, and run the necessary pipelines for collection, DevLake will be ready to render a complete DORA dashboard leveraging the power of Grafana.

Whether you want to implement DORA in its standard format, or develop more advanced and specific dashboards, with DevLake, you're only a few clicks and queries away.

Tips for Managing an Open-Source Project (with the Creator of Homebrew)

Maxim Wheatley — Tue, 23 Aug 2022 20:57:00 +0000

I sat down with Max Howell, the creator of Homebrew, one of the most widely used dev-tools ever, and one of the most ubiquitous open-source projects of recent years. In my conversation with him, Max shared some interesting insights on how he managed to maintain and manage a great product and project.

This conversation was part of the DevLake community meetup, DevLake is the open-source dev-data platform giving you the power to connect, query, and visualize data from all your development tools, all in a totally personalized dashboard.

So let's get into it!

An important point in being an effective open-source maintainer, is that it is truly all encompassing:

"It's a crash course in everything from product management, to customer service, to design, to DevOps... you really have to be ready to do all these things or recruit and engage people that can." - Max Howell (Creator of Homebrew)

1. Create a list of relevant forums, and pay close attention to the questions and discussions:
As you get started, identify projects with similar use-cases, features, tech-stacks, and audiences, and make it part of your process to understand where things go wrong, what kinds of issues people run into, and figure out how you can preemptively account for these wherever possible.

As you get more traction and a community, you need to monitor everywhere (not just your own community) to ensure you're being as supportive as possible.

2. Get really good at saying NO. With meaning.
Early on especially, there is a temptation to accept almost anything that comes in, but if you do this your project can lose purpose, vision, or quality. As the maintainer you need to be comfortable saying no, and providing feedback and guidance to ensure the next contribution is worth saying yes too. You also need to be extremely clear about what is acceptable, what the purpose of the project is, and what the roadmap should look like. The less guessing contributors have to do, the better the project and product will be.

3. Don't leave things too polished.
There is always a temptation towards perfection. However, if you don't leave opportunities for users and community members to find bugs, issues, or opportunities to polish the project, you'll overly constrain the 'hacking' opportunities for people to get their hands dirty.

4. Keep your documentation as simple and consolidated as possible.
Think about the user-experience of your documentation and ReadMe as a product unto itself, try to reduce the number of pieces that are necessary, consolidate where you can, and optimize to make things interesting and easy to read.

5. Less features = Better product.
Be disciplined with your roadmap, use-cases, features, and goals. The more this grows, the less coherent the vision will remain, and the chances of shipping seriously buggy or unstable releases increases dramatically.

6. Don't be afraid of becoming a leader and 'figurehead'
Many new maintainers feel a sense of "Imposter Syndrome" and as a result shy away from the spotlight or from taking charge of their own project. In Max's words "Every great project ever, there's been some clear person, a clear leader who can set the goals and make the decisions."
There has to be somebody who leads the project and does so publicly to set the tone, be accessible, share the updates and insights, and make the decisions.

7. Be comfortable with the 'thankless' nature of OSS.
Many new maintainers struggle with the reality that for the most part, their users won't have an opportunity or motivation to reach out and thank them or share their stories. Once you're growing, you have to accept that the joy and satisfaction is in building something great, and with the faith that you are enabling others to build great things, and that ultimately it will indeed be worthwhile.

In my next blog, I'll be sharing Max's thoughts on the future of open-source, and what he believes the current challenges (and future solutions) will look like!

Follow along for the next post!

Join me this Thursday where I will be discussing open-source sustainability with Joseph Jacks (Founder of OSS Capital and the Open Core Summit): https://twitter.com/i/spaces/1BRJjngEvqNJw?s=20

*Learn more about what we're up to with DevLake: * https://github.com/apache/incubator-devlake

How to Build Great Open-Source DevTools: With Max Howell (Creator of Homebrew)

Maxim Wheatley — Mon, 15 Aug 2022 21:40:00 +0000

I sat down for over an hour with the creator of one of the world's most successful developer tools, the near ubiquitous Homebrew package manager. This is the first in a four-part series that dives deep into our conversation to share some of the most actionable insights with the community.

In today's blog, I get into the thoughts, advice, and lessons that Max shared when it comes to building and managing great open-source developer tools.

Thank you to the Apache DevLake community for making this event possible, and to Max Howell for his time, wisdom, and generosity! DevLake is the open-source Dev-Data platform bringing all your DevOps tools into one customized, transparent, powerful dashboard!

"I think part of what allowed Homebrew to take off so quickly, was that by design, but also somewhat unintentionally, it was really easy to start hacking on, without needing to invest a massive amount of time or effort to get going." - Max Howell

Here are some of the most interesting and actionable insights he shared with us on building great open-source developer tools:

Figure out how to make error handling and messaging as informative as possible. The more you can help your users help themselves, the more readily your project can scale. Responsiveness is essential to build a great community, community is essential to building a great open-source project, if you aren't in a position to remain responsive as you grow, you'll be challenged to really scale.
Start small, and with a clear use-case and workflow. If your project is too large in scope and ambition, it can be challenging for developers to figure out the codebase and even harder to get started. Even if you have a grand vision, reduce it to the most essential ingredients.
Put together a ReadMe that quickly gets new people up to speed on several key things:
- What is this, and what makes it new and different?
- Who is this for, and what will they do with it?
- How do they get started and how do they use it?
Don't make your releases "too polished" and be mindful of achieving a balance where there are clear areas and opportunities for new contributors to fix and improve things. There are levels to becoming even more strategic with "good first issues" etc.
From a product/project strategy perspective, be cautious about adding too many features, if you make it easy for the user to "shoot themselves in the foot", it's less likely that they are going to keep using the product. Reliability in both implementation and execution are critical to obsess over. If people 'hurt themselves' or their project with your tool, they'll never come back.
As a project leader, you need to stay focused on how you're really empowering your end-users to work more effectively, seamlessly, and quickly on the things they care about:

"They don't care about your project, they're probably grateful for it, but they care about what they are building, what they are working on, and that your project helps them do that better." - Max Howell
Be obsessed with reducing the number of steps and the number of proverbial "hoops" to jump through to get to the key distinguishing feature.

"90% of developers don't want to spend excessive time tinkering with things, figuring out something that they may or may not end up finding valuable, the power users will hack their way through regardless, but to get real momentum it has to be easy and FAST."

Find ways to really work with the major ecosystem tools, platforms, and infrastructure "open source developer tools are always incremental, and built on the shoulders of giants." You don't want to build something that requires some fundamental shift in how they are already working, to succeed you have to be harmonious with existing behaviors, and require the least amount of behavior changes to adopt.

In my next blog from this interview, I'll be sharing Max's thoughts on how to maintain and manage an open-source project effectively as it goes from initial community-pick-up to global sensation. Follow along for the next post!

Join me for my next interview with Sharan Foga, Board Member of the Apache Software Foundation this Thursday!
https://lu.ma/01lv9yy0

Learn more about what we're up to with DevLake: https://github.com/apache/incubator-devlake

Interviewing The Creator of Homebrew! What Should I Ask Him?!

Maxim Wheatley — Tue, 02 Aug 2022 21:06:28 +0000

Hey Dev.to Fam! I'm excited to have the chance to interview long-time friend and mentor, Max Howell, the creator of Homebrew!

*He's an open-source icon, and a great product thinker. I want to make sure I cover some interesting things. What do you think I should ask?
*

All are welcome to join us! The link for the live interview is here:
https://lu.ma/a86n488w

"There's a Dashboard for That" New Open Source Template for Bug Tracking

Maxim Wheatley — Mon, 25 Apr 2022 22:03:36 +0000

We built DevLake to be the most transparent and personalized solution to make sense of development data. DevLake unifies the fragmented and heterogeneous data inside your development tools, and makes it easy to query that unified data, all within a customized dashboard.

We've succeeded in building the technology, but it's only the beginning of the journey!

We are now on a mission to continue growing the capabilities of DevLake, to make it ridiculously easy and effective to implement, we are creating highly specific dashboard templates.

A totally custom development dashboard is just a few minutes away for anybody!

Want to improve code quality?
Want to accelerate delivery?
Want to identify bottlenecks?
Want to improve technical retros?
Want to improve observability?
Want to improve on SLAs?

To paraphrase our friends at Apple: "There's a dashboard for that."

Every. Single. Week. We will be releasing a new open source dashboard template.

We want to help the world of software development become one that is more data-driven, all while celebrating the often hidden accomplishments of the people building that software. We're confident this is one practical step we can take to bring this vision to life!

If you want a particular dashboard or set of metrics, or need support to get something set up, let us know, we'll make it happen, at no cost to you or your company.

To kick things off this week, we built a weekly huddle dashboard for evaluating and triaging bugs.

What new bugs were created last week?
What bugs got fixed last week?
How does that compare to the previous week?
What are our oldest bugs?
What's the average age of bugs in our backlog?
How many new bugs do we create each week on average?
How many bugs are we fixing each week on average?

We built this dashboard inspired by conversations and use-cases with our friends at Scarf and Coder (both awesome teams building great developer tech!)

The template is ready for you to customize in the current DevLake release, available right now on GitHub for everybody.

With each update, we will be making more templates available to empower you to spend more time doing what you love: building.

More Dev. Less Ops.

**GitHub Link: **https://github.com/merico-dev/lake

An Open Source DevOps Toolchain Manager

Maxim Wheatley — Wed, 02 Mar 2022 17:07:00 +0000

Hey Dev.to Family! Forgive my shameless promotion, but I'm proud of my teammates and want to share, and hoping you'll help!

*Quick demo video at the bottom of the post!
*

DevStream, is an open source DevOps toolchain manager that we developed to make it fast and easy to configure, launch, and manage a workflow in just a few minutes with a single command.

https://github.com/merico-dev/stream

As we've built DevOps tools, it became clear what a headache it was for teams to set up new workflows (and many don't really have them because of this!) So we wanted to do our part to solve this.

No more manual curl/wget download, apt install, helm install; no more local experiments and playing around just to get a piece of tool installed correctly.

DevStream does the hard work for you so you can focus on building (the fun part!)

You can define your desired DevOps tools in a single human-readable YAML config file, and at the press of a button (one single command), you will have your whole DevOps toolchain and SDLC workflow set up.

We've already integrated GitHub Actions, Jenkins, ArgoCI, Grafana/Prometheus, and Trello, more tools on the way!
We'd love your feedback, ideas, contributions, anything is most welcome. We hope you love it and find it as helpful as we intended, and that if so, that you'll help us spread the word!

GitHub link HERE: https://github.com/merico-dev/stream

An Open Source DevOps Dashboard

Maxim Wheatley — Wed, 24 Nov 2021 23:01:05 +0000

Hey Dev friends! Forgive the shameless promotion, I'm so proud of my teammates and want to share, and hope you'll help!

DevLake, is a free and open source tool, it brings together all the data from many of your dev tools (GitHub, Jenkins, GitLab, Jira, etc.) and provides analysis and visualization with a personalized dashboard filled with the metrics that matter to YOU.

https://github.com/merico-dev/lake

We saw how much time and energy it takes to make practical sense of DevOps data. "NO MORE!" we said, and so we built DevLake to make it easy for developers everywhere to make their data work for them.

Our motto is: More Dev. Less Ops.

We hope DevLake helps you achieve exactly that, and we hope you'll join us by contributing, sharing, or simply by making use of this. Thanks gang!

(We built DevLake making the most of Go, Grafana, and Docker, among other things! We'd love to chat about our experience building this if anybody has questions or ideas!)

GitHub link HERE: https://github.com/merico-dev/lake

We Just Open Sourced our Tech!

Maxim Wheatley — Tue, 15 Jun 2021 18:49:53 +0000

We believe that OSS is the present and future of great developer-led tech, so here we are.

Merico Build is an open platform to quantify and articulate developer contribution and accomplishment, it's powered by novel static analysis techniques, and now open to all!

https://merico.substack.com/p/open-source-and-developer-first

We hope you'll follow us on this journey, or better yet, join us!

"Glassdoor" but for Remote!

Maxim Wheatley — Mon, 08 Mar 2021 18:51:51 +0000

Hey Dev.to friends! Today we released our love letter to remote work: "Glassdoor" but focused 100% on the factors that make-or-break the experience for remote employees.

https://remoterated.com/

We know that things like transparency, remote-leadership, tool choices, and remote benefits can be game-changers, but none of the ratings websites were paying attention to them, so that's what we've built here!

I'd love your thoughts and feedback, and if you're feeling generous, I'm incredibly grateful for a share or shoutout! :-)

Thanks gang!

What is most difficult to articulate in an engineering interview?

Maxim Wheatley — Tue, 05 Jan 2021 20:54:21 +0000

In job interviews, what elements of your development experience/expertise do you find most challenging to articulate, prove, or demonstrate?

We just released free analytics to empower OSS!

Maxim Wheatley — Thu, 17 Dec 2020 16:40:05 +0000

You write code for more than just work, but how do you translate those contributions into growth, career outcomes, or skill development? We've created a product to solve exactly these challenges, articulating hidden value!

We started Merico to empower developers, and we can think of no better way to do so than to release a version of our product specifically geared towards the individual developer, at no cost, so that's what we've done.

https://www.producthunt.com/posts/merico-build

I hope you'll try it, and if you like it, that you'll share it! Thanks DEV family! :-)

How do you measure productivity?

Maxim Wheatley — Tue, 15 Dec 2020 17:58:49 +0000

Hey Dev community! Maxim here from the Merico team. We spend a ton of time thinking about engineering productivity:
How to measure it? How to define it? How to improve it?

All simple questions with tricky answers. I'd love to hear from you on what you have used in the past that has worked whether tools, metrics, or techniques!

Hope to hear from you, and look forward to the conversation!

Disclosure: On Thursday we are releasing a free version of our analytics product to give developers better insights and data into their own performance and productivity. We are on a mission to help people articulate their accomplishments to become better coders and achieve more in their careers!