A replacement plan/document is a great community resource, even when you’re not being replaced.
A year ago, as the role of RDO community manager at Red Hat was moving from one person to another, that team started thinking about what needs to be in place to effectively transition a role. More generally, the managers started thinking about planning, and documenting, for anyone’s eventual replacement.
The phrase “cookie licking” has become popular in recent years to define a pattern which can be problematic in communities. Its meaning comes from a story: Mom makes a plate of cookies, and sets the on the table for the family. After everyone has had their cookies, there is one left on the plate. The cheeky child of the family wants to have the last cookie later, but has no confidence it will still be there when she comes back, so she grabs the cookie, licks it, and puts it back on the plate, secure in the knowledge that no-one else will want to eat it.
It is a convenient myth for a lot of people in the free and open source software community that our projects have few barriers to entry beyond a base set of knowledge about the project new contributors want to try to join, and the skills need to contribute to a project.
Diversity, to a lot of people who buy into the pure meritocracy myth, is a problem that can be solved by accepting anyone who can contribute. It’s the contribution that matters, not the person’s race, gender, or other identifiable status. Train more people up, the meritocrats will argue, and the diversity problem will be solved.
It takes a village to raise a child, so the saying goes. That is also certainly the case for launching a new tech event, as the attendees of the inaugural DevConf.us have learned this week.
DevConf.us has successfully started in the George Sherman Union on the campus of Boston University, and runs until this Sunday afternoon. Registration is free of charge, so developers from all across the New England area are welcome.
As DevConf.us approaches, speakers are putting the finishing touches on their talks before they set out for Boston University.
In this interview, Christophe de Dinechin takes a break from his preparations to discuss not one but the three talks that he’s giving during the inaugural edition of this conference.
A project roadmap is a valuable document for a community open source project. For growing projects, even when the developers are predominantly working for one company, the roadmap is invaluable and accomplishes a number of things at once:
- It is a great tool for setting shared priorities and setting limits for what is in and out of scope for the project
- It encourages the developer team to be transparent about planning and provides context for more discrete quantities of work
- For engaged community members, it gives an opportunity to contribute to the improvement of the project, by suggesting features which are not on the roadmap, or by volunteering to develop features, which are included but not yet committed by the core team
- Finally, for casual users of the project, and visitors evaluating whether they would like to use the project, it gives an idea of what is coming down the road
2018 has been a big year for Linux. Red Hat is celebrating its 25th anniversary (as well as Slackware!), and we are not the only ones with significant birthdays. This year also marks the 20th anniversary of the Open Source Initiative (OSI) and a touchstone conference in the open source ecosystem: OSCON. And this year’s show is celebrating in style, moving back to where many would say it always belonged, Portland, Oregon.
When you do some site housekeeping, it’s also a good time to do a little content housekeeping as well.
We recently updated our Software participation page after launching the new RedHatOfficial organization page on GitHub. This week, it’s time for the Standards page to get an update.
When I wrote the May 29 blog entry, “Taking a Break,” I really wasn’t trying to be prescient. But what was meant to be a gentle reminder for community members to take mental health breaks, turned into the next-to-last blog posting on this site for over a month’s time.
That’s because when the May 31 post was attempted to publish, we discovered some serious issues on the previous content management system that prevented the automated CI process from clearing content to be posted on this site.
Every once in a while, somebody will come along and highlight that restrictive licenses carry more risk than permissive licenses. I think this is not as big a threat as some would have you believe.
There are two main branches of what is broadly known as free/libre open source software (FLOSS). Free software licenses are restrictive in the sense that if you use software and modify it, and then want to share it with someone else, you must share your changes with the original project.
Open source software licenses are defined as permissive, since there are typically no sharing requirements on the code. You make your changes and then share the code only if you want to.