This week I presented at SaltConf21, a conference for the open source project Salt. Salt is sponsored by my employer VMware and I just barely joined this team as their new technical writer.

In this hour long presentation, I share clips from my research with early Salt contributors to discover the secret ingredients that made the project so successful. I also look forward to the future of the project and explore ideas for injecting even more life and dynamism into the community through DevOps.

You can watch the full video here or read the following transcript.

Today I’m going to talk about growing a healthy DevOps community inside the Salt Project.

Magical places

For a long time now, I’ve been fascinated with what I like to call magical places. I’m not talking about fake magical places like Hogwarts and the Land of Oz.

I’m talking about real magical places. These are actual physical locations where communities of people gathered together at some point in history and advanced human society or culture in one sudden leap.

Let me give you an example of what I mean. One of my favorite examples is Café Procope in Paris.

Café Procope opened in 1686 and it was created by the Sicilian chef Procopio Cuto. The café was successful because it was located across the street from a popular theater and because it served sorbet and coffee, which at the time was a fairly exotic beverage that had previously only been available in taverns.

Café Procope was magical for many reasons. One reason is that it attracted people from many stations of life and professions, including writers, musicians, philosophers, and scientists. Think of it as kind of like the bar from Cheers, but imagine that sitting right next to Norm and Cliff were famous intellectuals like Voltaire and Diderot and Rosseau.

Some of the people who rubbed shoulders at Café Procope decided to meet there and work on a project called the Encyclopédie, the first general encyclopedia. It had over 150 contributors and its goal was to democratize knowledge by creating a reference work with articles summarizing everything that humans had learned in the sciences, technology, philosophy, and art up that point in time.

This publication is considered one of the landmark publications of the age of Enlightenment, which was an intellectual and philosophical movement in Western Europe. This movement emphasized individual liberty, religious tolerance, and scientific reason and this philosophy is at the root of our modern democratic governments systems.

From a certain point of view, if you enjoy the freedoms of democracy and basic human rights, then you can point back to Café Procope as one of the magical places that first created the conditions that made those ideas popular and compelling.

That’s magical. Through luck, chance encounters of the right people meeting in the right place at the right time, and then a whole lot of passion and work, something magical happened that changed the world for the better.

And there’s been lots of other magical places in human history.

Just to rattle off a few more, there’s the Café Geurbois, (also in Paris) where the Impressionist painters regularly met on Thursdays and Sundays and basically revolutionized and democratized painting and art forever.

Another magical place is Budapest, Hungary where, for whatever reason, many of the world’s most important scientists and mathematicians were born between the years 1890-1920 and happened to all be in the same education system together. These included Manhattan Project founder Leo Szilard, H-bomb creator Edward Teller, Nobel-Prize-winning quantum physicist Eugene Wigner, and legendary polymath John von Neumann.

This coincidence about Budapest being the training ground for so many of the world’s best mathematicians led Peter Lax to make the joke: “You don’t have to be Hungarian to be a mathematician. But it helps.”

Leo Szilard, one of those prominent mathematicians jokingly put forward a theory that superintelligent Martian scouts landed in Budapest in the late 19th century and mingled there with the local population. After about a generation, the Martians must have decided our planet was unsuitable for their needs and disappeared. The only clue to their existence were the children they had with local women, aka the group of scientists born in Budapest that eventually made up half the brainpower behind 20th century physics.

And to give one final example: another magical place was Laurel Canyon from 1965-1975, a neighborhood above Los Angeles. This neighborhood happened to be a cheap place to live at the time. (I’m confident it is NOT cheap any more.) But because it was cheap at the time, it attracted many of the aspiring musicians that would eventually form the nucleus of the folk rock art movement. Artists like The Byrds, The Doors, Mama Cass Elliot from the Mamas and the Papas, Joni Mitchell, Crosby, Stills, Nash, and Young, Carole King, James Taylor, the Eagles, Frank Zappa, Alice Cooper, Linda Rondstadt, and tons more.

If you like any of the musicians I just named, you have the existence of Laurel Canyon to thank for that.

These are just a few of the many magical places where communities of people gathered together for some purpose and then changed some aspect of the world.

Now, one thing that has been accelerating over the last decade and more is that technology is making it so that we don’t need a physical space to gather any more.

Starting in the 80s with the Linux/GNU open source software projects and then really ramping up with the development of new asynchronous communication technologies like GitHub, Slack, and Zoom, it’s now becoming possible to collaborate with large communities of people without being in the same physical location.

That’s kind of awesome if you think about because it means that you don’t have to live in Paris or Hungary or L.A. to have access to cool communities that you want to be a part of.

So, why am I mentioning all this? What’s the point? What does my weird fascination with magical places have to do with SaltConf?

Open source software is a magical place

Well, if I may speak boldly, I do believe that open source software communities in general are one of today’s magical spaces in the same large and epic sense as I just defined it.

Now, not all open source communities are healthy and vibrant. But some are. And I believe that Salt is one of those communities. That’s part of what has me so intrigued. I love figuring out why some places are magical. And that’s what I’d like to explore in my talk here today.

My presentation today is going to have three parts:

• In part one, I’ll make my case that the Salt Project is one of those magical places. In this section of my talk, I’ll explain what elements made the early Salt Project a magical place.
• In the second part of my talk, I’ll discuss how we can retain the magical elements that the early Salt community had so that we can have a conversation about how to ensure the Salt Project remains magical going forward.
• In the last part of my presentation, I want to have a discussion with all of you about where to take the Salt community next. As a prelude to that discussion, I’ll mention some interesting magical elements from other open source communities that I think could be inspirational for the future of the Salt community.

The magical ingredients of the early Salt community

So, let’s talk about the ways in which the early Salt community was magical. Salt is part of the larger societal movement known as open source software. In particular, it’s part of the second wave of open source projects that were supercharged by the invention of the GitHub platform, which made OSS more accessible to even wider populations than it had been before.

With that in mind, I decided to put on my Salt historian hat for this presentation and I did some research into the history of the Salt community with many of the people who were part of the community from the very beginning. I had lovely chat with three members of the early Salt community: Dave Boucha, Gareth Greenaway, and C.R. Oldham. I’ve gotten permission to share some video clips of our conversation here in my presentation today, so I hope you’ll enjoy hearing from some of them. I have about six clips to share.

Worked on solving problems that mattered

First off, one of the elements that made Salt magical is that it gave people an opportunity to work on solving a problem that mattered. Tom Hatch originally created the idea for Salt for the simple reason that he wanted to make his own job as a system administrator easier. He wanted a way to collect data and execute tasks remotely using a method that could scale to managing tens of thousands of nodes at a time. He had tried to solve this problem before but wasn’t satisfied with the existing technology at the time. So, he decided to create his own system.

Tom Hatch also decided to make Salt an open source project because he wanted to be able to have access to this tool regardless of which job he was in or which client he was working with. He didn’t want paying for licenses to be the barrier that prevented people from using Salt.

So that was the first element: there was a need to create a tool that could solve a problem that really mattered.

I really liked the way that C.R. expressed the nature of the problem in our interview. He said:“Wrangling servers is hard. We’re going to make [a tool] that will make it so that you can go home at 5.”

I really like that. Freeing up system administrators from the boring stuff that could be automated so that they could focus on the higher-level tasks that they really wanted to work on. That’s a problem that really matters and is worth solving.

Passionately spread the word about Salt

The next magical element of Salt was that Tom and other community members were passionate about spreading the word about Salt to others. I’m going to share a clip from Dave Boucha talking about how Tom worked on getting other people interested in working on this project:

Transcript:

Dave Boucha: To get a project off the ground, some of it is just luck. But part of it is just being in the right place at the right time. And Tom is great about talking about Salt on and on and on. So Tom went to all kinds of conferences. He went down to Gareth’s conference in California and had a booth there before there was even a company. It was just an open source project. I went down there a number of times with him.

He went to programmer’s groups. I met Tom at a Python meetup here in Murray, Utah at the time. He presented on Salt and then at the meetups for the next 2-3 months after that, he just talked about Salt after the official stuff was over and we’d be there until late at night. They’d kick us out of the library and we’re standing outside in the freezing snow talking about Salt. And everyone is just around Tom just talking about Salt, Salt, Salt.

And so there is some luck in just catching some momentum, but Tom was always just out there putting his name out there and the ideas. And people were attracted to that. And that’s just a common thing at all conferences Tom goes to. You’ll find Tom in a hallway, in a big room somewhere circled with people just holding court. Talking about Salt or just technology and geeky stuff. That’s whether it’s a Salt-specific conference or wherever he might go.

There’s times when I literally felt like Tom’s handler and I would literally go and get food for him because he was starving. He had almost no breakfast, it’s 3:00 in the afternoon, he hasn’t had any food. He’s shaking, but he just can’t stop talking. And people would love him. It was like being with a superstar or rockstar. People would come running, “Oh, it’s Tom Hatch!” He just connected with people over technology and people just wanted to be around him and get involved.

As you can see from this clip, Tom was passionate about Salt and thoroughly enjoyed talking about it with others and people were attracted to his vision for the tool and the energy that he brought to it.

I’ve found that this is often one of the key elements of attracting people to an open source project. From my own experience, I’ve learned that one of my favorite ways to socialize with other people is by working together with them on a project or task that I care about. And I don’t think I’m alone in that. The projects I’ve decided to join have been ones where I looked at the core contributors to the project and said those are the types of people I would love to work with. They seem like fun and they seem people I could learn a lot from.

And for that reason, it’s important to make sure your open source project is doing everything it can to attract those types of people to the project and letting them sometimes be the public face of the project in order to attract other like-minded to the project. Notice also that I’m using the plural term “people” here because you need more than just one passionate and charismatic project member in order to be sustainable. Thankfully Salt does have many dynamic and interesting project members like that in addition to Tom.

Fostered a friendly, welcoming culture

The next magical ingredient I want to mention is that Salt made a very deliberate effort to foster a friendly, welcoming, respectful, and fun community. This was a very conscious effort on the part of Tom and the early community members and this even predated the concept of being welcoming open source community. So that was very forward-thinking at the time.

One way that C.R. mentioned they did was by being really, really open and accepting of all ideas from everyone. For example, they were pretty liberal about accepting pull requests from everyone. There was very low barrier to entry at the time. The next clip I want to play illustrates a humorous example of how open they were to accepting most pull requests in the early days in the early days of Salt:

Transcript:

C.R. Oldham: There’s some really funny history. One of the few pull requests that we didn’t accept was this guy wrote an entire [module] for support for Windows update. And throughout the entire PR, everything was a Hogwarts Harry Potter reference. Nobody could understand it. I remember Tom in the office one day saying, “We so desperately need this, but there’s just no way we could merge it because two weeks from now we’re not going to have the slightest idea what is going on in here.”

Dave Boucha: All the variables were Quidditch match terms.

Gareth Greenaway: All the commands too. I remember seeing that one. I remember laughing and thinking, “Oh my god, they’re going to merge this in. Oh my god! They merge in everything and they’re going to merge this in!” And then they didn’t and I was just like, “Oh man, that’s both good and sad at the same time.”

One thing that this story illustrates is how fun and creative the early Salt community was and accepting of nearly every idea up to that point.

On that note, I want share one more clip on this theme. This next clip features Gareth Greenaway talking about his first pull request:

Transcript:

Gareth Greenaway: I was a community member for a good portion of [the early days] and I still remember the very first pull request I ever put in. If you ever hear Tom on The Hacks or Salt Air where he references a pull request that had… more lines of lint errors than there were lines of code, that was my first pull request. And I always tell people that for any other project out there, if someone saw that, you’d be told to take a hike. Get out of here! This is terrible!

But at this time, Tom still reviewed every single pull request back then. And his response was, “This is fantastic! Thanks for doing this! You’ve got some lint errors. Let’s get these fixed and get this merged.” And that was the reaction I got from every single pull request. And it wasn’t just Tom. It was from whoever was reviewing it that day. It was such a welcoming, friendly community. And that’s what kept me coming back and submitting code. It was just such an enjoyable experience to contribute stuff.

And as C.R. said, you never got turned away. Some of the craziest stuff got in there early on and right, wrong, or indifferent a lot of it is still in there today. A lot of it probably wouldn’t make it in today just because we’re more strict on what gets merged. Because at some point someone realized, “Wait a minute. We have to maintain all of this code!” But I think that attitude that Tom had trickled down to everyone else and then trickled down into the community. Where everyone realized, “Oh, I don’t need to be a jerk. I don’t need to be hostile and harsh to other people. I can be friendly and they’ll be friendly to me.”

In our discussion, Dave Boucha mentioned that because the core contributors really worked on being friendly, positive, and helpful, that set a tone for the rest of the community. He mentioned he could only remember one small incident of a community member making an inappropriate joke on the IRC channel that they had to say was not okay. But when they called it out as being insensitive, the person who had made the joke instantly apologized and that was the only incident they had of that sort.

Invested heavily in first-time contributors

And that brings me to the next magical element I want to discuss: the early Salt community grew their community by investing heavily in first-time contributors. They made a conscious effort to lower the barrier to entry as much as they could and also to mentor new contributors.

Let me play another clip featuring Dave Boucha on this topic:

Transcript:

Dave Boucha: A lot of times people just needed help learning how to interact with an open source community. GitHub was fairly new still at that point and not everybody had opened a pull request or things like that. One of the benefits of being open source was that people would often run into a problem and then they could dive into the Python code. And even if they weren’t very good Python programmers, Python’s often—depending on where you’re at with the code—clear enough to where you could go, “Oh, I think it’s right here.” So sometimes they show up in a Slack channel or send an email or even open up an issue on GitHub and say, “Oh, here’s this one line and you’re missing a dot right here.” And sometimes it was that simple and they were able to find it.

So, at first, I’d open up a pull request and fix it. But then Tom was like, “Hey, help them go through the process.” So, sometimes I would literally say, “Go to GitHub. Create an account. Now go to our repo. Fork it to your account.” And just basically go through all the steps, helping them go through the process of creating their own pull request. Sometimes it was kind of a pain in the butt. But you do that and then you’re enabling them to do the following one themselves. So that whole process goes smoother and you don’t have to babysit them every time.

As Dave points out in this clip, sometimes it’s a heavy effort to take the time to mentor people and set up the structure or the framework that will allow people to make contributions. But as much of a pain as it is, that effort is worth it in the end.

I feel like if you invest in your community members, then they will invest in you and your tool. And everybody benefits from that in many different ways.

Attracted thought leaders from the industry

The next magical ingredient is that because the community was such a great place and because the technology they were building was so useful, the Salt Project began to attract power users and thought leaders from the industry.

And so as a result, it began a positive feedback loop that improved the Salt Project overall.

Transcript:

Dave Boucha: The Salt community really brought together a lot of expertise around the industry. I can’t remember if there was this one time where I was starting a new module from scratch. Or maybe someone was starting a MySQL module and then they just left it. So, I was adding some features to it and fixing bugs. I think I was starting from scratch. But anyway, someone that used to work for the MySQL organization or company happened to see it and was like, “Oh, wait, no. Do it like this. Connect it to the Python like this.” I can’t remember the details now, but it made that module a lot better and faster and more the MySQL way than I would have done it naturally.

There’s a lot of that expertise that’s kind of built into Salt because people are solving real world problems. A lot of our scaling type issues. I mean, we don’t have a hundred bare metal servers to test on. So people at LinkedIn and eBay—LinkedIn especially—did some amazing work helping us scale and test things at scale that we may never have been able to do on our own, at least not without a lot of expense.

And even on smaller modules, we have features in there with things like Ruby on Rails or rbenv that I wouldn’t have even cared to work on. But we have that feature because somebody wanted it and wanted to work on it.

Alyssa Rock: Yeah, because you were solving real world problems. You had that kind of breadth in your community across the industry. That’s cool.

Gareth Greenaway: Dave mentioned conferences. I remember some of the early SaltConfs. The very first one I went to was just such a great experience being in the same space as so many people that had a shared interest in one technology. And all the different stories and conversations you would have with people using Salt. One of the things I remember from my very first one was when I was having a conversation with someone. I wasn’t working for SaltStack yet. In the conversation, they mentioned something that I had contributed and they were so excited and I was so excited to meet someone that was using code I wrote. And then they were really hesitant: “Oh, but we found this bug and it doesn’t do what we’re trying to do here.” And I hadn’t even envisioned that someone would try to use it that way. But that’s an awesome use. We should fix that. And we sat down over the next hour or two prepping the pull request to submit this particular code to tune it to what the community member was doing. Just like that stuff in the early days was just fun.

So, as you can see, this community began to be a magical place where people exchanged ideas about how to use Salt effectively in a variety of contexts to solve practical, real-world system administration problems.

That’s part of what makes open source so special. Normally, that information is kept proprietary and secret. But in this kind of open environment, Python developers and users in Operations came together to build a tool that could better meet the industry’s needs.

I like a quote that C.R. gave in this session where he said: “Even if Salt wasn’t the tool for them right then, [they knew that] it could become the tool they could depend on.”

Empowered community members to make meaningful contributions

The last magical element I want to mention is the Salt Project empowered community members to make meaningful contributions.

In order to be successful, a good open source project needs to attract active contributors. Active contributors (as opposed to casual contributors) are really important to any open source project. Active contributors:

• Make higher quality commits because they have more context for the project.
• Stay with the community over the long term.
• Occupy a position of trust within the community.

But not all contributors are created equal. So how do you attract the good ones?

I really love a quotation from Nadia Eghbal’s book Working in Public: The Making and Maintenance of Open Source Software. If you know a little bit about me, you probably know that I love this book and want everyone to read it. So, hopefully this quote will get you interested in reading more.

She says:

Active contributors might look like casual contributors at first… but their motives are different. During their first month, active contributors tend to exhibit prosocial attitudes, demonstrating a higher level of motivation to help others. …

Active contributors who stick around do so not because they successfully made their first contribution, but because they already came in with the intent to stick around. In other words, they were never really casual contributors in the first place. …

An active contributor is often motivated by a desire for community, but they might have secondary motivations around reputation and learning. They enjoy the social aspects of the project and want to feel as if they’re “part of something.”

I’m going to share one last clip from my conversation with Gareth here and I want you to keep this quotation in mind:

Transcript:

Gareth Greenaway: But one of the things that I remember early on, even as a community member, was that people had—and for the most part I think it’s still there—but you had a sense of ownership over your contributions. For the stuff that you contributed, you were kind of the subject matter expert on that particular area of the code. And so even community members—and we still do this to this day—if someone is better versed in the code than anyone on the core team, we’ll call them out and say: “Oh, hey, you know this code better than we do. What do you think here?” So, that sense of ownership over the project…

Alyssa Rock: Really made you feel invested?

Gareth Greenaway: Yeah. It just makes you feel like you’re part of the team. Like C.R. was saying, when he joined the company, he felt part of the tribe from day one. I think that feeling extended into the community as well. Once you joined the project, once you were involved, once you submitted your pull request, once you were maintaining a bit of it, you were part of the group, whether you worked for the company or not. You were part of the group.

As you can see from this clip, contributors like Gareth have pro-social motivations: they’re motivated by a desire to be part of a community and part of something meaningful.

So, it’s important to the success of the project to be able to ensure that your open source project meets those needs. I’m talking about deeper needs like a need for community, for opportunities to learn and grow professionally, and to make a difference.

And those elements were there in the early days of Salt, which is why it was a magical place. That’s why it:

• Has more than 2,000 contributors.
• Has more than 5,000 forks.
• Has been starred on GitHub more than 12,000 times.

The future of the Salt community: DevOps thought leadership

So now I want to turn my attention to the future Salt community. I want to make it clear that I think that the Salt community still retains many of the qualities that made this early community a magical place.

Yes, a few things had to change about how the community was run in order to reduce tech debt, and to ensure code quality, and to accommodate the sheer scale of the number of people who now use Salt. And some of those changes meant that the barrier to entry for contributing got a lot higher, unfortunately. Still, at the end of the day, many of these magical elements are still here.

But where do we go from here? How do we continue to grow and how do we continue on this trajectory to advance system administrations technology?

One area where I think we have some untapped potential is in DevOps.

DevOps is the combination of cultural philosophies, practices, and tools from software development and infrastructure management (operations). The overall goal of DevOps as an approach or as a methodology is to increase an organization’s ability to deliver applications and services at a higher velocity.

The rest of my slide gives a brief summary if you’re not familiar with these concepts already, but I’ll assume most of you already are.

The field of DevOps is still new enough that the Salt community hasn’t really tapped into this field as much as it has the potential to. From what I understand, the early Salt community seemed to really attract the Dev side of DevOps a little bit more because it attracted a lot of Python developers more than anything. Python developers were interested in Salt because they saw it as kind of a fun and interesting Python project to work on. But as you saw from my little history lesson, clearly Salt has also attracted Operations folks as core users of the tool.

So for this reason, I hope this isn’t heretical to say, but I feel like the Salt Project could be something more than just a community that is dedicated to one tool. It could be a place where folks from Development and Operations could congregate together to share best practices and exchange ideas, just like they have been doing in the first eight years of the Salt project. I’d like to see more of that old thought leadership and collaboration at the heart of the community. And I think that could then inform development on Salt as a tool because we could build the technology that supports the best practices and methodologies that might come out of those conversations.

For example, my colleague Patrick Moffitt often talks about what he calls the Salty Way, which implies that there is a methodology or approach to implementing DevOps in a particular way using Salt. What if we as a community seriously developed out that methodology? That would be an interesting project for us to work on and it would ultimately make Salt a better tool at the end of the day.

What we could learn from other open source communities

Let me take a small detour to talk about some of the good work being done in other open source communities that I think could benefit Salt either indirectly or directly.

Write the Docs

One of the communities that I’m a part of is the Write the Docs community, which is an open source-ish, free community of technical writers and DocOps professionals who get together to exchange ideas and best practices.

One thing that’s super interesting about Write the Docs is that originally this community was meant to support one tool: the open source, Python-based Read the Docs documentation platform. But over time the Write the Docs community evolved way beyond the Read the Docs tool.

Today it’s a global professional community of technical writers that meet together to grow their social network and to improve the craft of documentation. Just to give you some context, a good chunk of the technical writers who have been hired to work on Salt and SaltStack Config have come to us through the Write the Docs community. And it really is where many of the key players and thought leaders in the technical writing profession are collaborating these days.

Could the Salt Project community expand in the same way? Could we become a place where ideas and best practices are exchanged?

The Good Docs Project

Another technical writing community I’m part of is the Good Docs Project. This is a project that is getting together to create templates, tools, and guides to help improve documentation in open source.

And the main thing I want to mention about this community is our mentorship structures. One of the key projects we’re working on is creating high quality templates that can easily incorporated into an open source project by people who are developers and who are not professional technical writers. You may remember how testing wasn’t really considered a baseline for open source quality 10 years ago, but now it definitely is. We’d like to do the same thing for documentation, essentially.

Our project has an interesting mix of experienced technical writers and new technical writers and non-technical writers. And the way we handle that scenario is by having our writers work together in template working groups. These groups are led by an experienced template mentor and they meet together as a group once a week to talk about their template projects that they’re working on. Each templateer has a little space of time to show us what they’ve been working on and get advice from the other writers.

Honestly, these groups are really magical for me. They remind me of poetry circles where poets would get together and share their work together and make new poetry and get feedback on their work together. These template writing groups like a fun way to socialize and improve at the craft of technical writing together while also creating something that would be useful to a larger community.

And if you’ll indulge me, I want to give a shout out to Dee Thompson who is our newest SaltStack Config writer who I met through this group and encouraged here to apply for this job.

These mentor groups are designed to scale to larger sizes as needed. As junior members of the template writing groups participate over time and get at least one template project finished, they’re eligible to become a template mentor and to then lead a template writing group. When template writing groups get too big, we have the ability to then spin out new groups based on the level of interest we have.

My point in mentioning these template working groups is that our project has innovated a really great way to make mentorship models scale for large groups.

The way this could apply to the Salt Project is that DevOps is a field that could use some mentorship. There are limits to what you can learn about system administration from reading a book or taking a class. That’s not to knock the importance of formal education, but in many ways I feel that society could benefit from bringing back older knowledge transfer structures like apprenticeship models, where an experienced sys admin could mentor less experienced admins and teach them the tools of the trade. And maybe Salt could be the kind of community where those mentorship opportunities for DevOps could happen.

Carvel

Okay, the last open source community I want to mention is Carvel, which is actually another VMware-sponsored open source software project that comes from the Tanzu side of the company. My knowledge of this community is still new and raw, so I am by no means an expert, but I see so many possible touch points for collaboration between Salt and Carvel.

Carvel is very much interested in creating the next generation of DevOps tools, so they’ve been in this mindspace for awhile now. And the superficial glance that I’ve given to their tools so far seems really promising in terms of ways Salt could integrate with it.

For example, one of their tools is YTT which is a linting tool for making well-formed YAML code that can also drop in pre-formed YAML structures for doing common tasks. A tool like that could be awesome for writing Salt state files.

And that’s just the tip of the iceberg. Again a superficial glance based on just a couple of conversations with someone from this project makes me feel like Salt and Carvel could team up together to make a truly end-to-end DevOps tool.

So, that’s another open source community that’s worth exploring.

Conclusion

Okay, I’ve thrown a lot of crazy ideas out there, like throwing spaghetti at the wall. So now let’s see what sticks. Let’s have a conversation about what you think the future of the Salt community is and how it could be a community for DevOps professionals or otherwise.