Let’s get this out of the way: Yes, I’m old and grumpy. I have more than a few “get off my lawn!” moments. But sometimes… sometimes, they’re justified. Especially when confronted with some of the common communication anti-patterns I run into day after day when working with distributed communities/workers. Here’s a few things you shouldn’t do, or stop doing if you do them.
The story behind the first four – when bears wander into the wrong areas, they can be tranquilized and held for up to 30 days before being released. This is to discourage the bears from wandering into human territory. Then they’re airlifted back to their area.
Still in vacation mode, but wanted to share a few quick photos from the trip. Enjoy!
My position on free and open source software is somewhere in the spectrum between hard-core FSF/GNU position on Free Software, and the corporate open source pragmatism that looks at open source as being great for some things but really not a goal in and of itself. I don’t eschew all proprietary software, and I’m not going to knock people for using tools and devices that fit their needs rather than sticking only to FOSS.
At the same time, I think it’s important that we trend towards everything being open, and I find myself troubled by the increasing acceptance of proprietary tools and services by FOSS developers/projects. It shouldn’t be the end of the world for a FOSS developer, advocate, project, or company to use proprietary tools if necessary. Sometimes the FOSS tools aren’t a good fit, and the need for something right now overrides the luxury of choosing a tool just based on licensing preference. And, of course, there’s a big difference between having that discussion for a project like Fedora, or an Apache podling/TLP, or a company that works with open source.
Fedora is generally averse to adopting anything proprietary, even using things like YouTube or Twitter to promote Fedora tends to generate discussion and questions about whether it’s proper to use proprietary services. Grudgingly, though, most folks have accepted that to promote Fedora you have to go where the people are–even if that means using non-FOSS services. Apache has been more willing to adopt non-free services (e.g., Jira) where acceptable FOSS services exist. Not surprising, because Apache’s culture is more “use open source because it’s pragmatic” rather than driven by ideology. (That is painting with a very broad brush, and I think you can find a diverse set of opinions within Apache, including mine.)
Generally, though, I worry about making too many concessions to non-free software. I worry that we’ve gone too far towards business concerns, and too far away from wanting to change the world for the better. There’s a balance to be struck, I think, where we put food on the table, build successful companies and successful and sustainable communities. Where we use tools we’ve built to do our work, and tools we can improve, but don’t rake people over the coals because of the tools they choose or make bad business decisions out of a desire for purity.
This post asking people not to use Slack really resonates with me. I see this as a wholly unnecessary adoption of proprietary software where there’s a reasonable and serviceable alternative. The good news, I think, is that Slack seems to be spurring some development of better IRC alternatives that might not have developed without Slack. And it’s spurred more people thinking about the tools they use, and whether they’re open, and what that means. Full disclosure, I have a personal Slack account. I’ll use it to chat with friends, just like I’ll use Facebook or Google Hangouts. But I don’t see recommending it for an official channel for, say, Project Atomic.
A piece over on Fedora Magazine, following a talk I did at Flock this summer. The short version: open source projects need all the help they can get spreading the word. Fedora, Apache projects, GNU projects, Debian, etc., all depend on word of mouth to reach users. By reaching users, we find new contributors, and it’s the new contributors that help keep projects going and reaching new users. We don’t have megabucks to throw at ad campaigns, but we have millions of users–and the impact would be enormous if even 10% of those users spent a little time spreading the word about Fedora (or other project).
More users means more contributors. More contributors equals better projects. Better projects mean more users, and fewer people choosing proprietary solutions. Don’t wait for somebody else to spread the word, jump in and lend a hand.
The marketing group was a bit disorganized in the F23 cycle, and we can do much better. I hope to do more in the F24 cycle, but I can’t do it alone, and don’t really want to! So if you want to see Fedora succeed wildly, I hope you’ll find a way to join our efforts. Read the full piece on Fedora Magazine, and feel free to ask if you need help jumping in!
Here’s something I spend a lot of time thinking about: What constitutes “real” open source? Not just the license, I think the OSI has done just fine in defining an open source license. (And the GNU/FSF folks have done just fine in defining a Free software license as well.)
I’m asking, what constitutes a real open source project? What are the specific things you need to say “yep, this is a genuine open source project that really deserves the title”?
Curious what other folks think. It probably comes as no surprise that I don’t consider a project “open” just because there’s a public repository with code that is under an OSI-approved license.
Also curious of any bodies like the OSI have working definition. So many projects and companies lay claim to open source, but I see very little of it in practice.
Question: Why is top-posting evil?
I know I’m fighting a losing battle here, but I occasionally feel compelled to remind people just how inefficient top-posting is for multiple-participant conversations. This is doubly true for people added after the conversation is started.
It takes a little longer, but it’s so much nicer if you can read an email thread from top to bottom rather than having to scroll to the bottom, read, scroll backward, read, scroll backward, read, etc. Yes, it’s the easiest way to reply to a message, but it’s an enemy of comprehension for recipients.
Here’s a pet peeve of mine, because I see it time and time again: Folks work on software or projects, put in a ton of effort, and then do nothing to promote the project or release. (And, for bonus points, complain that they don’t understand why the project isn’t getting more attention!)
This doesn’t mean developers have to do double-duty as marketeers and public relations folks. Well, not if they can pass the torch onto interested contributors who are happy to do it for them, anyway. It requires a little coordination and effort, but why put all the work into a project and then not get the attention of the users (and potential contributors) you’re trying to reach?
Additionally, it really helps to blog, tweet, and otherwise spread the word about projects while they’re in process. If you want people to collaborate, they really need to know that you’re doing something.
This isn’t necessarily intuitive for folks, I understand. But it is absolutely, vitally, necessary. Maybe, occasionally, a project is just so darn awesome that somebody happens to stumble on it via GitHub or whatever and word of mouth makes it a success – but typically, things get out into the world via consistent updates and communications to the right channels to get the word out.
If you work in open source, odds are you spend a lot of time working with people via email. At Red Hat we have internal mailing lists for developers that work on projects, and external mailing lists for projects, as well as internal lists for specific groups, topics, etc. I’m also, less than I’d like these days, involved in the Apache Software Foundation (ASF) and it has user lists and developer lists for projects, announce lists, and a variety of private lists for projects and specifically for members, fundraising, and so on.
I could write volumes about what’s good and bad about various Mail User Agents (MUAs) and mailing list software. But this is not about that–this is about bad habits that people fall into when opening and conducting discussions on mailing lists. Specifically, whether they’re going to the right place.
All too often, I see people opting to go for the least-public list when opening discussions. Part of this, I think, is just human laziness. You get into a routine, and stick with it. This is doubly hard to overcome when an initiative starts “behind the firewall” and then moves into the public.
Part of this is a tendency to stay with a familiar group. It can be “scary” to expose your ideas, commentary, plans, or whatever to a large audience. It can also, honestly, be annoying. Everybody has an opinion, and filtering through all the opinions and commentary can be a royal pain in the posterior. Separating the wheat from the chaff can be tricky when you do opt for openness and then have to filter through all of the digressions, uninformed opinions, and (occasionally) dissent to come to a decision.
I could probably write volumes on this topic, but I promised a quick thought. So, in a nutshell: Think before you start a conversation on a mailing list. Are you sending it to a private list to avoid discussion or exposure, or is there a good reason the conversation needs to be private? (Alternately, are you sure of the audience you’re sending to? Are you sending anything group/company confidential to too wide an audience? It happens infrequently, but it can be a big problem when it does.) If not, then break the habit and opt for openness. You might just be surprised how effective that can be, so give it a shot.
One of the most exciting projects I’m getting to work with these days is Project Atomic. It touches on the full stack–from OS development to storage, to networking, containers, application development, and pretty much everything in between. Red Hat is working hard on the tools to develop, deploy, and manage containerized applications.
As part of that effort, I’m looking to find a lead for community efforts around Project Atomic and our container tools. (Job description on the Red Hat Jobs site.)
Ideally, we’ll find someone with some experience using Linux, Docker, Kubernetes, and so on. Also looking for someone with strong community background, able to work in the open and manage a number of open conversations across projects. Experience with the Fedora and CentOS projects a major plus.
There’s a ton of work to do, and things are moving really fast–so it’s definitely going to require someone well-organized and eager to stay on the leading edge of technology while the container ecosystem continues to move at a crazy pace. But, you’ll have the chance to work with a great team full of smart, friendly folks who are seriously passionate about open source.
Know somebody who’d be fantastic? Drop me a note. Username is jzb, and I work for Red Hat – shoot me an email with a resume! You can also find me on Twitter and occasionally on Freenode if you have any questions.