Tag: open source

Posted on

Be Clear About How Things Work (How Open Source Can Work with Companies)

This post is one of a series of posts about what open source software projects can do (if they wish to) to make it easier for companies to participate in their projects.

When a company wants to get involved in an open source software, often they need some help understanding how things work. Sometimes it’s the developer who wants to contribute that has questions. Sometimes it’s their management who wants to understand what type of commitment they are making and what they can expect.

An open source software project can make it easier for a corporate contributor to participate by being clear about:

  • What the release process and schedule looks like.
  • How long it takes for a PR to be reviewed and how to best position it for acceptance.
  • Who makes decisions and how.
  • What roles people in the project play and how they get to those roles.
  • Where and how to ask questions.
  • Who is working on the project and what their motivations are. (Is this software to make apps run faster on watches or is it to make apps run on car computers?)
  • How to find out and stay informed of security issues.

As an open source software maintainer, the more you can help organizations understand how you work and how to work effectively with you, the more likely they are to engage.

Posted on

What open source governance models are available?

If you are looking for an open source governance model, there are two resources to explore.

  1. Red Hat has published the Project and Community Governance Guidebook on GitHub. It covers things from roles of the participants, to how projects evolve (and governance should evolve with them), to policies and procedures.
  2. The FOSS Governance Collection just launched with a collection of governance docs on Zotero. It is a great place to go see real, live documents used by existing open source software projects. (If you work on an open source software project, or just notice that one is missing, please upload the governance docs!)

Don’t forget, a project’s governance needs to evolve as the project evolves.

Posted on

How Open Source Communities Work

Several happenings over the weekend are case studies in how open source software communities work.

The Dev Behind a Hugely Popular GNOME Extension Just Quit

While the news is about a developer quitting because it’s not “fun”. I think the message – or messages – are deeper than that.

  1. Isn’t it awesome that are free software is developed by people that love doing it? Back when I started the OpenLogic Expert Community, I contacted many maintainers and offered to pay them to fix issues that our customers had. Some of them turned me down because they loved working on open source software and thought payment would change that. (That inspired my Would You Do It Again for Free? talk.) Some of them turned down payment because this was a hobby and if they got payment their family might view it and the time they spend on it differently. They took free tech goodies instead!
  2. Wouldn’t it be great if when what you are working on no longer made sense, you could move on to something better suited for you at the moment? Working on something you love, because you love it, gives you the freedom to say it’s no longer your favorite thing to work on and to move on. You do still have responsibilities but in this case, it sounds like there was good backup.
  3. Feedback. I do hope that the GNOME community takes this feedback as an opportunity to explore how things are going. They should survey other users and figure out if this is an individual problem or a systemic problem and how they might prevent it from happening in the future.

Canonical CEO Mark Shuttleworth makes peace with Ubuntu Linux community

It is a positive sign that the GNOME project – or this part of it – had a clear and positive succession plan.

Again I think the title doesn’t capture the importance here.

Governance is very important to every open source software project. It’s important when you set it governance to determine how councils, boards and advisory boards are going to work. Who is going to be on them? What criteria determines who is on them? What are they supposed to discuss? What do they get to decide or control? How do their decisions get implemented?

And projects evolve. You need to continue to examine the governance structure and make sure it’s still working. Sometimes advisory groups are created to raise money or to make marketing decisions. And later they start making technical decisions. What does that mean? Should the group evolve? Or is a different part of the project experiencing difficulties that this group is trying to fill in for?

While I don’t know specifically what happened with the Ubuntu Community Council, it is normal for projects to have governing structures that change and evolve over time. As they set it back up, it will be important to figure out who is on it, how people get added and removed, what their charter is and how their decisions will be implemented.

Posted on

Join us for the first ever virtual hallway track!

Do you miss the hallway track at conferences? All those impromptu conversations with other people that care about open source software? Me too! So we are setting aside some time to have a virtual hallway track.

Topic:
Growing leaders in open source (Or wherever the conversation goes! It’s the hallway track!)

Location:
https://meet.jit.si/OpenSourceHallwayTrack

Meeting time:

Wednesday, April 22, 2020, 15:30 UTC

LocationLocal TimeTime ZoneUTC Offset
San Francisco (USA – California)Wednesday, April 22, 2020 at 8:30:00 amPDTUTC-7 hours
Denver (USA – Colorado)Wednesday, April 22, 2020 at 9:30:00 amMDTUTC-6 hours
New York (USA – New York)Wednesday, April 22, 2020 at 11:30:00 amEDTUTC-4 hours
London (United Kingdom – England)Wednesday, April 22, 2020 at 4:30:00 pmBSTUTC+1 hour
Paris (France – ÃŽle-de-France)Wednesday, April 22, 2020 at 5:30:00 pmCESTUTC+2 hours
Tokyo (Japan)Thursday, April 23, 2020 at 12:30:00 amJSTUTC+9 hours
Corresponding UTC (GMT)Wednesday, April 22, 2020 at 15:30:00 

If the meeting is too big for a single conversation (kind of like when everyone pours out of a lecture at a conference), we’ll break up into smaller groups.

Posted on

It’s true: because you can travel, you have to

I once sat on an airplane for 20+ hours in order to spend a day in Italy. I spent the whole trip wondering why we had to meet in person when we have all this technology like video calls, email, irc. While having my surreal foreign driving experience where a gazillion lanes merged into a few and all the signs were in Italian, I tried not to let my jet lagged brain wander and I wondered what I was doing.

Why, when we have so much technology, do we have to travel so much to work together?

MDN Hackfest, March 2015

And the secret is to flip the question around. It’s because we have all this technology that we have to travel. Because we can communicate and work with anyone around the world, we do. And when you work with people, you need to meet them. You don’t need to see them every day, but you need to understand how they talk, how they hold themselves, what’s important to them, what makes them raise their voice in excitement. Once you meet them, you’ll read all their emails differently. You’ll get what they are trying to say in that pull request so much faster. You’ll be a team.

Once you’ve met them, had a beer with them and learned that they too have a five year old kid, you’ll be more likely to be willing to get up at 6:30am for a meeting with them. You’ll be more likely to tell them you think something’s wrong with their idea and believe that they’ll really listen to you. You’ll be more likely to ask them for help. Because of how the human brain works, you’ll be more likely to remember them in another conversation where something they are working on will go together wonderfully with the idea a new friend is talking about.

Meeting in person is key to working well together. Technology lets us work with more people in more places and so now we travel further to meet each other.

Posted on

10 Ways Community Managers Make Sure Projects are Healthy

Community managers must make sure their projects are healthy. Before they can help foster and grow a community, they have to make sure it’s a well functioning, welcoming place.

Photo from the Library of Congress.

While community managers and project leaders often don’t explicitly talk about what’s not working well, you will often find them doing a wide variety of things. They are doing whatever is needed — filling in the gaps — to make their project work well so that new people can join.

Here are some of the things that an open source software project needs in order to be healthy and grow community.

  1. Getting Started. In order for new people to join, here has to be an easy way to get started using the project and an easy way to get started contributing. Usually 30 minutes is the maximum amount of time someone will try to install and use your product for the first time.
  2. Clear Goals. A project needs clear goals before its community can grow. New members need to know what problem the project is trying to solve and how they plan to do that. Without a clear vision and set of goals for the project, someone who hasn’t been involved with the project won’t know what contributions might be welcomed.
  3. Target Audience/Market. As part of its vision and goals, a project needs to know who it’s for. Is it for enterprise software developers or elementary school kids?
  4. Project Lead. The project lead can be a single person (like Linus Torvalds) or it can be a small group of people (like Samba) or it can be a group of people (like Apache) but it really helps the project identity, the decision making process and the goal setting to have leadership.
  5. Release Management. Every project produces something and there needs to be a way that “something” gets produced and published for people to use. And a place where people know to find the latest version.
  6. Project Infrastructure. Every project needs some amount of infrastructure. Most projects need source code control, bug tracking and mailing lists. They also probably need a website, a place to publish documentation and a way to manage finances.
  7. Roadmap. Sometimes a project’s roadmap is simply a backlog of issues. Sometimes it’s a Trello board. Sometimes it’s a detailed 2 year roadmap. Whatever form it takes and however much detail it has, it’s important to the project to know what’s next.
  8. Governance. A well-defined project has clear processes for how decisions are made and who gets to make them. Some projects have well developed governance processes. Others have light weight, undocumented processes. But without some sort of governance, the project is likely to stall often.
  9. Advocates. In order for a project to grow, someone must be talking about it. These advocates may be users or contributors. They may be spreading the word on the internet or at in person events.
  10. Events & Outreach. More advanced projects will start to participate with a talk or a table at existing events and may even start to hold their own events.

If any of the above things is not working, it will be hard for a project to attract new users. A good community manager or project lead will focus on making the project run well first before inviting new people to join.

Posted on

3 ways open source software communities could learn from Crossfit

Photo by Anthony Topper.

This week I am participating in the opensource.com community blogging challenge: Encouraging New Contributors!

Crossfit gyms are great at creating community and welcoming new members. Here are 3 things that Crossfit boxes do that open source software communities could also do to encourage new contributors:

  1. Say hi to the new person. I drop in at gyms around the world, and no matter where I go, everyone in the class comes up to say hi to me and introduce themselves. How awesome is it that I can go to a gym in Frankfurt and have 10 total strangers walk up and introduce themselves and say how happy they are that I’ve joined them?
    For open source: When you see a new person on your mailing list or IRC channel, stop and say hi. Introduce yourself and tell them they are welcome. You can do it publicly or privately. (If you do it publicly, you might set a good example for others!)
  2. Celebrate daily accomplishments. When we finish a workout at my Crossfit gym, we all post our scores in an app. It gets ordered from best to worst but no matter where you are in the line up, everyone will  give you a virtual fistbump and most of them will notice when you’ve had a spectacular work out based on your skill level and they’ll congratulate you for it.
    For open source: Have a place where people can note what they’ve done, maybe point out what they are proud of or what was hard for them, and get kudos from others. Sometimes this happens on source code control systems. Sometimes on IRC. I think most open source software projects could do better at this.
  3. Allow for off topic interactions. To really build community, you have to know each other. Sometimes that’s hard to do if you just focus on the work all the time. There has to be a place to chat, to share goals, ideas and maybe every once in a while, a non-project focused thing. In my Crossfit box, we do this in a Facebook group. Usually, it’s fitness related but sometimes it’s just chatting about life in general. The group gets noisy and I turned off notifications, but I still visit at least once a day to congratulate, commiserate and just visit. It’s a place new members can ask questions, learn more about the community and get to know each other.
    In open source communities: Find a channel where people can chat. A place where they can ask all their questions, express frustration over a piece of code or complain about the weather. Sometimes it’ll get noisy but usually it will bring people together and, more importantly for the new people, help them “see” the community they are joining. Most open source software projects do this on irc or Slack.

How do you think open source software communities can Encourage New Contributors? What have you learned from the other communities in your life?