9 rules for the proper care and feeding of communities and carnivorous plants

A few tips will help keep your community from turning into a little shop of horrors.
335 readers like this.
9 rules for the proper care and feeding of communities and carnivorous plants

Internet Archive Book Images, modified by Rikki Endsley. CC BY-SA 4.0.

In 2016, I adopted my first carnivorous plants, a Venus Fly Trap and a Pitcher Plant, which my Facebook friends named Gordon and Bananarama, respectively. I quickly discovered that the health of Gordon and Bananarama was closely connected to the environment I provided as much as to their ability to catch the occasional bug and get energy from the sun. In this article, I'll pull from my experience working with open source communities—and a few months of experience keeping Gordon and Bananarama alive—to explain how caring for carnivorous plants is much like caring for a community.

1. Prepare before diving in.

Plants meet the catsI should have researched carnivorous plants before impulsively buying a couple in the flower aisle of Whole Foods in Raleigh, North Carolina, but I didn't. Had I done my homework, I would have learned that the Venus Fly Trap is the official State Carnivorous Plant of North Carolina, for example, and only about 35,000 currently grow in their natural habitat along our coastline. Instead, I nonchalantly threw the plants into my basket, right next to a pint of Ben & Jerry's ice cream. I hadn't considered how plants, like open source communities, are living organisms with different needs, and that thrive under specific kinds of care. For someone like me who lacks a green thumb, this was a huge and somewhat costly mistake.

You shouldn't join an open source community before first doing a bit of research, either. Knowing about a community's history, culture, organization, and etiquette will help you avoid inadvertently causing damage. Like species of carnivorous plants, each community is unique and thrives under different conditions.

Luckily I did research carnivorous plants after I returned home with my new purchases. As it turns out, my carnivorous plants need rainwater or distilled water to survive, and they soak up the water from holes in the bottom of their pots. Had I poured tap water over my new plants, I easily could have killed them.

2. A sunny spot isn't enough.

Healthy environments must be maintained. Carnivorous plants and communities can't simply be placed in a sunny spot and then left alone to fend for themselves. They require maintenance, and what kind depends on various factors.

Carnivorous plants need a bunch of sunlight and mild temperatures, and they require a special, somewhat complicated mix of soil. Communities gather around a common interest and set of goals, but to thrive they also need organization, collaboration and communication tools, a recognition or reward system, and regular attention. A neglected community will not thrive or survive longer-term.

To maintain a healthy carnivorous plant or open source community requires observing and listening to feedback. A common mistake organizations make with open source communities is to create or share an open source project and assume that the community will organically form around it and do the rest. Rarely will a plant or community die unexpectedly; instead, they explicitly ask for help or send out warning signs first.

3. If it's not broken, you might not need to fix it.new blue pots

Gordon and Bananarama were happily thriving in my sunny kitchen, but I thought their original brown plastic pots were unattractive and missed a few features I thought my plants and I would like. I thought the plants would benefit from pots that sat in a tray of water, and I thought turquoise pots would look better in my bright kitchen than the drab brown ones. (The turquoise pots only came in a set of three, which is how I ended up with a third Pitcher Plant named Mouse, after the children's book If You Give a Mouse a Cookie. But that's another story.)

Let's say the pots my plants were thriving in were like IRC, and then I moved them over to Slack. That's when I created new problems.

Carnivorous plants, like open source communities, are unpredictable about adapting to change. I knew I had to handle the move thoughtfully and get the soil mix just right, otherwise I'd harm instead of help my plants. The same is true when introducing change in open source communities. If your community effectively collaborates over IRC, are you sure moving to Slack will be an improvement? Or will the change result in a drop-off in communication or community member engagement? Or is it possible to add options, without taking away tools that already work?

My plants continued to grow and quickly outgrew the new blue pots. I'd given them a self-watering tray and colorful environments, but I forgot something: I'd failed to give them any room for growth. This was poor plant-community management on my part. The plants were still young and had a lot of potential, but I'd need to remove obstacles if I wanted them to grow.

4. Plan for growth, then adjust plans accordingly.

I needed to upgrade to a platform that would scale, and in plant terms, that means bigger pots. Bigger pots meant I'd need more soil mix. My $10 plants were becoming increasingly expensive and had needs for which I hadn't budgeted.

I didn't want to shock my plants by taking them out of soil they thrived in, but I needed to give them more soil to allow for bigger roots and new leaves. So I took the community-equivalent approach of keeping IRC and adding a couple of Slack channels—I kept the soil they were in, and I added a new mix of soil to help fill their new, bigger pots. I put them in a new window in my kitchen and decided to kick back and watch them grow.

5. Metrics matter.new pots, soil, and window

Growth slowed down. Leaves started to brown. What did I do wrong?

I'd added a new mix of soil, put the plants in new pots, and moved them to a new window all at once. Because I made several major changes at the same time, I couldn't pinpoint which change impacted my plants. I had the metrics to determine growth, but I didn't have the metrics I needed to help point to why growth patterns had changed. (See James Falkner's Community Metrics Playbook column for tips for what to measure for your community.)

On Opensource.com, for example, we look at lots of metrics to help us determine what topics interest readers, when and how frequently to post content or update social media to get the best results, and how site design affects reader engagement. Being mindful of how changes we control affect our metrics helps us determine whether the changes were good or bad for our community, and we also have to think about unexpected changes outside our control (for example, Facebook newsfeed algorithms).

6. Energy and enthusiasm ebbs and flows.

I've moved my plants to a different window to see if they perk up, but I still can't be certain that something I did or didn't do affected their growth. Could the change in productivity be a result of something beyond my control and the timing was simply coincidental? Perhaps.

Plants and communities both go through growth and productivity spurts. Because Venus Fly Traps are adapted to their environment, they go dormant during winter months, starting in the fall. Meanwhile, thanks to community metrics, we've noticed that activity tends to drop slightly on Opensource.com over holidays and at the end of a calendar year, and then readership and article submissions start picking up with fresh energy and enthusiasm in January.

Knowing when there will be bursts of energy before or after specific events or seasons helps when planning the care of communities and carnivorous plants. I can stop worrying that my brown thumb is why Gordon is being quiet now that I know it could be normal behavior for a Venus Fly Trap, and our editorial team can plan months in advance for an expected slow-down in article submissions from our community.

7. Leaving isn't always bad.

People leaving a community, or leaves browning on a plant isn't necessarily a bad thing. For example, a community moderator, Nicole, recently left our program, but that's because she accepted a new role on a documentation team at Red Hat. Leaving our program is a sign of success for her because she has a new job, and she can still participate in our community when time permits.

You see this kind of activity often in open source communities. As community leaders, we need to know why people leave our communities to make sure unexpected departures don't indicate a problem.

When Gordon and Bananarama started getting brown leaves, I suspected that they weren't getting enough sunshine or the soil mix was wrong, so I moved them to a sunnier window to start diagnosing the issue. I noticed that they were still getting new leaves, and I've been monitoring to see whether the brown increases. If that happens, it could be a natural result of old leaves dropping off to make way for new ones. But if new ones aren't coming in, there's a bigger problem to rule out.

8. Watch out for pests and burnout.plants today

Brown leaves can signal pests or mold problems, much like people departing open source projects can signal problems, such as toxic personalities, entering the mix. In either case, the problem probably won't resolve itself. Buying a pesticide to get rid of critters on a carnivorous plant is a lot easier than managing toxic personalities in an open source community because we are, after all, talking about humans instead of critters.

Community leaders occasionally find themselves in a position that requires them to address personalities or behaviors that are damaging—or have the potential to hurt—an otherwise healthy community. Unfortunately, there's no easy, one-size-fits-all solution, but our community moderator (and a seasoned community leader) Jono Bacon thoughtfully addressed this topic in his article on how to fire community members. In that article, Jono explains, "If, through an empathetic, mentored, and considerate approach, we identify that someone is just noise, is bringing down the motivation of the community, and is an inhibitor to innovation, it is our responsibility as leaders to remove them. If we don't, we compromise the very fabric of what makes open source incredible: human relationships connected by a core mission and ethos, and underlined by the spirit and acknowledgment of doing."

Now back to the brown leaves analogy—they can also be the sign of a healthy plant that is merely shedding older leaves to make way for new ones. In communities, people departing a project could also be a healthy sign of growth—for example, if they're moving on to new challenges—or it could be in response to burn out. As I told a former employer years ago, once a person is burned out, it's too late. Although it's possible you could retain them in your community or see them return later, seeing the signs of burnout in advance and addressing the issue before it turns into a problem is a better approach.

Preventing burnout for yourself or a community takes practice. For example, earlier this year I spoke privately with a writer who was contributing a lot of great content to our site, which raised a red flag for me. From a personal perspective, I was thrilled to get the articles and wanted him to keep up the pace. But from my experience, I saw that he was working at a pace that would be hard to maintain for long, and that he was creating an expectation for himself that he had to keep up that pace. I scheduled a phone call with the writer and we talked about my concerns, and I encouraged him to take a break when he needed it... and maybe even before he needed it. He confessed that he had been feeling early signs of burnout and was relieved to have the preemptive talk and be reassured that I (and my colleagues) value, respect, and encourage self-care.

Seeing the signs of burnout in advance and addressing the issue before it turns into a problem is a better approach.
I'm happy to report that he still writes for us, and he takes breaks from writing for us when he needs to. For great tips on dealing with burnout, read Jono's practical guide for avoiding burnout and living a happier life.

9. You can't take care of a community or carnivorous plant alone.

If you're charged with caring for either a community or carnivorous plant, you'll need help. When I'm not home to care for my carnivorous plants, my pet sitter is charged with caring for my cats (Maggie and Buffy), and for Gordon, Bananarama, and Mouse.

I've yet to see a community leader who can care for an open source community alone. Community leadership requires a team of people who are invested in the health and maintenance of a project and the people contributing to it. For example, on Opensource.com, members of our writing community are familiar with at least one or two other people on my team, including our content manager, Jen Wike Huger, and Jason Baker, who specializes in our OpenStack and container content and manages our Resources collection.

Opensource.com also depends on help from our group of community moderators, who help our editorial team recruit writers, promote our calls for proposals, and answer questions over social media, at events, and in our Freenode IRC channel (#opensource.com).

To learn more about how to get involved in our community, see our Participate on Opensource.com page, which includes links to our social media accounts. To learn more about caring for carnivorous plants, check out mycarnivore.com, because I'm still not sure I'm doing it right.

User profile image.
Rikki Endsley is the Developer Program managing editor at Red Hat, and a former community architect and editor for Opensource.com.

5 Comments

Great article. You are a very gifted writer and I love your analogies. I shared this with another community I am a part of which is not an open source community but a community nonetheless. :D

About metrics. I think what you point out is that in addition to metrics, you need method.
As I have often told patients not doing as well as I liked, I like to make one change at a time. This way I can see what this one change caused, whether it be good, bad, or indifferent.
If you change several things and they do well, you're stuck, and you don't feel you can change anything. If they do badly, all you can do is undo everything you did and start over, a real time-waster. If nothing changes, then you may have done good and bad things that cancelled each other out, in addition to the possibility that nothing you did made any difference (a real ego-booster, plus the patient gets the idea you don't have a clue).

Here is something I would add to your list: Expectations.
I see this mistake made all the time, and we're talking about with physicians and patients, with hospital administrators, and even outside healthcare.
Take some time to flesh out some realistic expectations about what might happen. Set up some sort of time frame for those expectations, and of course maybe your time frame will be a range - "Ok, the earliest I might see results is _____, but I will surely see something by ____." Be your own devil's advocate, and be prepared to argue with yourself that maybe the positive things that happened had nothing to do with what you did (this also helps with realizing that bad things can happen in spite of your best effort).
If you can't set expectations, maybe you're not qualified to do what you're doing, and you need to enlist help.

Expectations are just the flip side of doing research in a new community. Hopefully your communities publish their expectations of behavior, technical work expected/accepted, and how to gain more access or merit within the community.

This is an area historically hard to get right in open source communities built by technical experts - who already know how their stuff works. The point is your community welcome message needs to appeal to newcomers.

The lifeblood of any FOSS community is new contributors. Making it easy for newcomers to start contributing is the most important thing we can do for our projects.

In reply to by Greg P

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.