Working in open source in these modern times is, for me, a lot of fun. The advent of tools like git (and services like GitHub and GitLab), collaborative platforms like Etherpad, and chat services like IRC have made sharing collaborative projects a much more streamlined process than in days past.
But what if members of your team prefer Slack to IRC? Or Google Docs to Etherpad? Is it time to get the holy water and exorcise these heretics from your community? Or can a more ecumenical embrace be employed?
One thing I have learned while attending events around the world is how to at least say four things in the local language: "hello, goodbye, please, and thank you." It’s not much, and I realize its yet-another sign of U.S. cultural centrism that I don’t know more languages than English and some German, but I figure if you’re going to visit someone’s home, the least you could do as a good guest is try to be polite.
Language barriers are not the only thing that can create difficulties communicating, particularly within communities. Personalities, methodologies, and even the most basic goals for a community can put community members at odds.
One of the advantages of traveling to open source conferences around the world is that you get a varied perspectives on how the world can work that falls outside your own worldview.
My recent trip to the Open Source Summit in Prague afforded me many such opportunities, and from very unexpected sources. One of which was from what some of my colleagues informed me was a insidious time waster: Universal Paperclips.
And the fun was just beginning.
How welcoming is the Open Source community? And I’m talking about Linux specifically. I would like to tell you a little bit about my experiences in last year or so. I already touched on this topic at the end of my previous post, but I would like to fully explain the problem and hopefully spark some hope. I will be saying “you” a lot, but I may not mean you. Don’t take it personally please.
I’m a former game programmer, obviously closed-source industry. I’m also a .NET Engineer (yes that is my job title at Red Hat). I work on C# stuff in Linux, I work on the Open Source .NET Core.
“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.
I have been thinking about how size can affect culture and adaptability of groups recently. The topic once again came up today in a talk about what makes a healthy community. The answer to that will depend on the community’s size and maturity. An open source project, in the words of one participant in one conversation I had recently on this subject, should have "the minimum level of structure to allow it to function effectively." I agree—just enough is the right amount. This article contains some ponderings on the relationship between size and communities, and some conclusions we can take from that.
This past September, I gave a talk in PyCon India 2016 titled “Python in Red Hat World”. The talk described the use cases of Python programming language inside of Red Hat.
I started the talk with an introduction to Red Hat–what we do and our main products are. Because the room had many students, this was new information for many of them. But almost all knew Red Hat for our flagship operating system, Red Hat Enterprise Linux (RHEL). When installing RHEL or Fedora (the upstream Linux distribution of RHEL), we use the project known as Anaconda to do so. Anaconda is written in Python. If you are trying to learn how to use Python Mock module and write better unittest cases, you should go through the source code of the Anaconda project.
The Free and Open Source Developer European Meeting (FOSDEM) conference will be held once again in Belgium at the Universite Libre de Bruxelles on February 4 & 5, 2017. For those not familiar with the event, it’s the largest general open source conference in Europe—perhaps the largest in the world—taking place annually in Brussels since 2001. (And, if you want to get pedantic about it, you could say FOSDEM was born in 2000 as the OSDEM conference.)
The conference has always been an important one for Red Hatters, with our employees representing the community in several ways: teaching in the exhibition area, giving talks as part of the main program, organizing of FOSDEM itself and organizing Developer Rooms. This year is no exception, as you can see from all the Developer Rooms we’re helping to organize!
Much of what we do on the Open Source and Standards team is focused on community growth, on the premise that a growing community, by and large, is a healthy one.
Growing a community is never as simple as throwing out your code for the world to see and letting your code’s awesomeness speak for itself. You can build the coolest application on the planet and still have problems getting people to help you with it, even if you have a sparkling personality.
We’ve talked about this before, when discussing onboarding. Onboarding is what we call the process used to get people into a community. That process can take many forms, and there can be more than one path into your community, but the key thing is having a process. Otherwise, you can have a project where you build it and no one comes.
The best deals are those in which both parties come out of the arrangement substantially better off than they would have been otherwise. One of the most significant aspects of Red Hat’s business model is that it represents a mutually beneficial deal between two overlapping groups of people: one that sees the Red Hat model as a powerful way to turn freely available open source software into a compelling subscriber experience, and one that sees it as a way to turn the subscription revenue received from satisfied customers into freely available open source software.
Neither of those groups is more important to Red Hat than the other. The interaction and collaboration between them helped build the company into an organization able to go head to head with much larger competitors. I think the most interesting aspect of this business model is that it is not inherently limited to the organizations we traditionally think of as software companies, or even those we consider to be technology companies. Rather, the model potentially applies to any organization that invests in software development or customization for their own use or on behalf of their clients.