Red Hat's mission: To be the catalyst in communities of customers, contributors, and partners creating better technology the open source way.
After several months of Fine work by the fine ManageIQ team and community, we're proud to present you the ManageIQ Fine release! This sixth ManageIQ release is named after American chess Grandmaster Reuben Fine.
Since the ManageIQ Euwe GA, we’ve had 10 very productive sprints with a total of 1511 pull requests in the main ManageIQ repository and 4880 PRs overall (averaging 76/244 pull requests per week).
Last month we ran a community blogging challenge on opensource.com. People really enjoyed both the writing prompts as well as hearing what others have to stay. Many expressed disappointment that the blogging challenge has ended, so we decided to bring it back! We want to hear what you have to say! We want to make sure that open source software communities have access to the best practices across all projects.
This week the focus is on events! For many of you, May was event month. ApacheCon, Open Stack Summit, OSCON, OSCAL, Read the Docs, Red Hat Summit, and PyCon are just a few of the events in May. So while you are thinking of them, what advice do you have for other open source software communities?
“Our developers are the seed of our community.”—Daniel Veillard
When companies open source products, they often spend a lot of time thinking—and worrying—about creating a community. In reality, they are the community. The product developers are core of the community—its first maintainers.
After the product’s code has been released as open source, they should focus on making sure that community is public and welcoming of newcomers. They can start by working in the open, as the open source community they are.
Inside the world of Red Hat, and other open source-oriented companies, there is a recurring metaphor to try to help explain the relationship between the projects where our source software is created and the commercially available software we ship with support, training, and other value-adds.
The metaphor used is "upstream" and "downstream," where upstream code is the "source" project code and "downstream" is the refined product code. Thus, Fedora is the upstream to Red Hat Enterprise Linux's downstream, to pick one example.
But increasingly we have been noticing a certain problem with this metaphor: very few people outside Red Hat and companies in this sector of IT really understood what the whole "stream" metaphor meant. Worse, when we really looked at the upstream/downstream metaphor ourselves, we realized that it has a fairly big flaw on its own.
Before I moved into community full time, I was a project manager
working on a lot of different things. As a project manager, you tend
to have a large portion of your day tied up in difficult
conversations, and what I learned through is: always deliver bad news
over the phone. Deliver over the phone, follow up in an email, but
give people space to be able to react in person or as near to in
person as you can, and have that hard conversation together.
Since I started this practice, video conferencing has gotten a ton better, and that 'near enough' is sometimes good enough! (I have other thoughts on what to do in days of amazingly bad connections, which is more common than you might think these days!)
The Open Source and Standards team is focused on making open source succeed at every level: community management, development, event management… Every aspect of open source can be improved for any project.
With that mission in mind, a new section of our site is dedicated to hosting "evergreen" knowledge articles and links that will guide free and open source software project participants to better practices.
I recently sent a report to project management containing some numbers that purport to describe the status of the RDO project.
I got a long and thoughtful response from one of the managers—we'll call him Mark—and it seems worthwhile sharing some of his insights. To summarize, what he said was, don't bother collecting stats if they don't tell a story.
One of my favorite things about working in online communities is that you can spend nearly all your time with someone online but have no idea what they look like. I went out to dinner with a friend that I've known for ages from the DevOps community, and he went up to order and put it on the tab I had open—and he couldn't remember what my real name was. He came back to the table and we had a good laugh about it—how we've known each other for some time, we're good friends, but there's some things that you just miss out on.
The face-to-face meetings are really important because you get to know why someone reacts a certain way to ideas that are proposed—in person. It's really hard to hug it out over video chat, even though you can indicate a lot in email, in chat, and mailing lists.
Others have written good general information about how to attract and retain contributors for your open source project. Here, I'm going to focus rather narrowly on one critical factor in growing your contributor base: speed. Since it's what I'm familiar with, I'm going to write with the maintainer in mind.
The moment a new contributor posts a PR or a draft patch, a timer starts. The longer maintainers take to respond to their submission, the lower the chance that person will ever contribute to the project again. While no one has done a specific study on this that I know of, my experience is that it drops by half in a couple of days and it gets very close to zero in only a few weeks. If you're running a young project and looking to attract lots of new contributors, there may be no higher priority than dealing with first-time contributions quickly. Minutes to hours is the target here.
This week's opensource.com community blogging prompt by Stormy Peters includes the question, “should community managers sit in marketing or engineering?” This is a very individualized decision and not an easy one at that.
A lot of companies support open source communities. The Fedora Project is supported by Red Hat. Red Hat’s support is huge and includes infrastructure, engineering and non-engineering contributions, budget for community driven activities and events and community coordination assistance.
