For some people in the IT sector, attending conferences is par for the course in learning more about technology and networking with people in their area of interest. But while many people take attending such events for granted, in reality, it can be a struggle of time, resources, or finances to get to a tech conference. The organizers of DevConf.US have recognized this and have made significant efforts to try to remove the barriers that are preventing attendees from getting in the doors.
For Marina Zhurakhinskaya, Senior Program Manager for Diversity + Inclusion Outreach at Red Hat, the key is to focus on all elements of diversity and inclusion. (more…)
We know you may have questions about what the new IBM and Red Hat relationship means for Red Hat’s participation in open source projects. The short answer is nothing, but we’ve gathered a few specific questions below that you may have. In addition, I will host an online Q&A session in the coming days where you can ask questions you may have about what the acquisition means for Red Hat and our involvement in open source communities. Details will be announced on the Red Hat Blog. (more…)
In the early days of open source, projects did not have community managers. Collaboration among developers was a given, and if you were lucky, some people in your community enjoyed tasks other than software development, like tending to infrastructure, organizing events, or leading a marketing team. As open source has matured, there are many more projects created from within large companies, and these things are no longer a given. Increasingly, people inside those companies are designated the Community Manager or Community Architect, and are tasked with ensuring that projects run well as collaborative, multi-vendor efforts.
Much has been written here (1, 2, 3, 4, 5, 6) about what a community manager may or may not do–but if one thing is certain, it is that projects evolve, and the role of community manager evolves with them. In the life of a project, a time may come when the original community manager is moving on–to a different job, a different role in the project, or just taking a back seat because of life.
At its beginning, every open source project starts with code, and one or more developers. What turns that project into a community are the people who engage with each other around that code. No matter what the maturity level of your project, one of the most important things to encourage and maintain is engagement with the users and contributors of your projects.
When a user of your project makes the effort to engage with the developers of the project, treat it as you would a gift from someone close to you. This person has taken time that they could have spent on something else, and they have chosen to spend that time contacting you. Whether it is a bug report, a feature request, or a pull request, these first interactions are critical to whether that person will have a positive or a negative impression of your project. (more…)
In order to increase the community outreach of Red Hat in Brno I, together with Jakub Čecháček, decided to organize a meetup that would bring together a community of people with a common interest in open source and cutting edge technologies in the enterprise software world.
Our goal is to bring the latest open source libraries, frameworks, and projects closer to technology enthusiasts. This meetup is aimed at all kinds of audiences, including software and quality engineers, architects, product managers, and evangelists. (more…)
There is a saying in the legal profession that you should never ask a question you don’t already know the answer to. Despite how this sounds, it is actually a rule most people follow in life. This is the source of that feeling you get when you’re too scared to raise your hand and ask a question. In Open Source we need to make sure that contributors feel like they already “know” the answers, so they will feel confident in making the request.
As a university lecturer, I always encouraged my students to first think about what they thought the answer was and then ask the question. In some cases, I encouraged them to actually write down what they thought the answer was. In this way, they could judge both their skills and their ability to grow based on what the answer turned out to be. It created an additional feedback loop.