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.
Memorial Day in the US is traditionally the unofficial start of summer, but ironically it’s also the start of a busy community season around the world.
With more students out of school, code contributions on various projects tend to rise. Conferences also tend to increase in frequency (particularly towards the end of the season). But even as life gets busier, it’s important to remember to pace yourself.
Let’s not kid ourselves: the free and open source community is not all laurel (yanni?) leaves and Kumbaya. There are arguments all the time.
Vi vs. emacs. Restrictive vs. permissive. Open vs. proprietary. Heck, on most days, I have had discussions about one or more of these topics before I’ve finished my morning coffee.
When you add business interests in the mix, the arguments add a whole new layer of motivation because now we’re talking about money and sales.
It’s a pretty violent metaphor, this notion of what happens to your open source software project if one or more of its members might get hit by a bus. Or a truck. Or whatever motor vehicle of doom happens to be barreling down the road of fate. At first thought, one might simply want to urge people to look both ways when crossing the street.
But the bus factor is a real concern for many open source projects, because too often a lot of the work finds itself in the hands of just a few people, who in turn become very critical to the project’s success.
Whether it’s a favorite sports team, a school, or just a group of friends, there is something about human nature that seems to drive many of us to display our affiliation.
We do this, typically, by displaying plumage that is synchronized. If I am a fan or a particular team, and I see someone wearing a matching jersey, then I can identify with that person in some way, even if it’s the first time I have met them.
This week is our annual Red Hat Summit, a time when many of our nearly 12,000 employees put their work down and come together to work with customers and determine how best to work together moving forward.
This may seem pretty antithetical to the goals of a team like ours, where free and open source projects are the focus, not commericial support and training. But actually customers get just as much benefit talking with the community projects as they do the sales and engineering teams.
It’s been about four years since it was announced that CentOS, the once-rebel Linux distribution that was a full-on, free-as-in-beer clone of Red Hat Enterprise Linux, was getting acqui-hired by the very company it was "competing" against.
It would be the end of CentOS, many people predicted, speculating that the hired CentOS team would be quietly redistributed to other duties and the once-mighty competitor to RHEL would vanish under the evil mechanizations of the Shadowman.
(Cue maniacal Vincent Price laughter.)
Yet, four years later, CentOS is not only still alive, it is playing a critical role in Red Hat’s ecosystem, working hand-in-hand with Fedora and many other upstream projects to make all the software better.
This was the topic of today’s DevConf.CZ keynote: "What Does Red Hat Want from Fedora and CentOS?"
Last week, I was interviewed by an academician who was doing a study on community metrics. During the conversation, the topic of diversity in a community arose. Specifically, the question was "why is diversity important to a community?"
I have to admit, I did freeze for a moment. Not really because I didn’t have an answer, but because that’s like asking "why is the Sun important?" and you don’t want your answer to sound stupidly obvious ("because we’d all be dead"), as opposed to more thoughtful ("because 3 degrees Kelvin is rather chilly").
The diversity question is frustrating to me because my knee-jerk answer is "because we don’t live in an all-X world" and "it’s the right thing to do" can seem like platitudes. Thinking about it a little more, a more compelling reason dawned on me: creativity is directly proportional to diversity.
There is a curious thing happening in customer relations in the United States these days. The use of the response "you’re welcome" seems to be getting replaced by "my pleasure."
Growing up, saying "thank you" meant getting a "you’re welcome" immediately afterwards. Like "day" and "night."
When this first happens in an interaction, it’s pretty disconcerting. There are certain language cues that become very ingrained in our consciousness, to the point where, if some thing different happens, it’s like tripping over a mental crack in the sidewalk. If I casually use the greeting "How are you?" (or somesuch variant of the phrase), predictably I’m going to get something like "fine," "good," or (if the person I’m talking to is having an actual good day) "great!"
The best thing about open source is watching people from different backgrounds and skillsets work together to create something bigger than something they can could have done alone.
And, sometimes, the worst thing about open source is watching people from different backgrounds and skillsets work together to blow something up.