src: https://openclipart.org/image/300px/svg_to_png/87319/stiGNUcius.png

Regular readers may recall previous wieldings on decauseblog of a powerful text visualization tool at our disposal in the CommOps Toolbox--the oh-so-fantastic word_cloud library by amueller


This past week, I ventured forth to "Beantown" to attend the FSF's User Freedom Summit, and 30th Anniversary Celebration. As expected, it was stellar and chock-full of Free Software Standard bearers, friends, and recent joiners.

You can find the raw transcripts from my time at the event, as well as the conglomerated adverts/blogposts used to generate the clouds below, in my decause/raw repo.

Here's just the keynote-y goodness by Eben. Below is an entirely partial transcript. It is incomplete, and is best accompanied by the video above, hosted via FSF's MediaGoblin Instance:

GNOME Accessiblity Develper's Guide: User Interface Checklist

Teaching Through Testing

This is just a list. A check list. You do not need to be a UI/UX expert, you just need to be a user, and you can contribute substantially by just walking through this list sometime, and filing tickets against bugs. You can learn so much about UI/UX just by reading this list. Do it at least once. You will level up so much so fast if you can stick to models like this.

/me <3's the GNOME so much.



This is where my day started: http://decause.github.io/sefroshem

Happy to do it again this year with Bill Bond and Prof. Jacobs in Kenn Martinez's Software Engineering Freshmen Seminar Course.

Polling the Room:

  • How many of you are freshmen? 100%
  • How many of you have heard of Open Source? ~80%
  • How many of you have a GitHub account? >50%
  • How many of you have heard of George Clinton? 0%

I'll be presenting on Thursday as well. Stay tuned!


src: https://openclipart.org/image/300px/svg_to_png/216484/1427445449.png

This post is in response to the article "The Hacker Hacked" by Brett Scott:


"In this context, the hacker ethic is hollowed out and subsumed into the ideology of solutionism, to use a term coined by the Belarusian-born tech critic Evgeny Morozov. It describes the tech-industry vision of the world as a series of problems waiting for (profitable) solutions."

I have mixed feels about this one. Brett's article is a good one, and has some key pieces of history, and proper shout-outs to the giants who's shoulders we stand on. Props Brett. I, however, think I'm just super biased and jaded, and all like "uh, yeah, obvs, duh." I'm a Hackademic, and perhaps a lil bit too familiar with much of this. At the same time, I'm *very* excited for the mainstreaming of hackery, and defanging the old "ski mask" tropes about hackers. I don't see this as a bad thing, or a risk, because of the fail-safe (we hope) of transparency. When SV startups think they are "disrupting" or "saving the world" by creating yet-another-shitty-app, they are going to get the "validation" they deserve when no one buys their product or contributes to their community. From what I can tell, Hackers don't want to solve other people's problems that don't need solving, they want to make progress.

I think we're seeing a super influx of /potential/ legit hackers, and as much as I love a good retelling of the story of Mel as the next guy, the old-guard elitism needs to leave room for the next gen to learn, even if they are starting from a softer more sterile place than the copper-age hackers did. I think that the thing that makes a hacker a hacker is that curiosity, to see how far the rabbit hole really goes, and to be unafraid to trace a thread all the way down the stack to see where it starts. Everyone has to start somewhere, and with the right exposure, even the "yuppiest" of webdevs can find their way to the core of empowerment. The transformation happens not because of the movies, or job prospects, or gadgets, but because of the autonomy. Learning to solve your own problems is a compounding virtuous cycle that ultimately causes you to question every other cycle not focused on rapid iterative improvement. You can get into that cycle whether you are building shitty-apps, or world changing FOSS code, the production process requires openness, and honesty. The important things are that the infrastructure remain neutral, and that copyleft licensing remain the standard.

We'll look back on IP policy of today the same way that the people who used looms to create textiles look back on hand-stitching, or the way that proponents of the locomotive regarded critics who said that speeds above 30 MPH would cause bodily harm. These machines and processes too, were at a time, a threat to the status quo, and subversive, and unnatural, and, and, and... but at some point they became the new standard, which is the era I reckon we are approaching--exemplified by recent developments like the Open Sourcing of certain closely held programming languages and environments, and bottom-line concerned organizations like Wal-mart and Capital One embracing open development practices, and even contributing back upstream in some cases. "Gentrification" and "appropriation" are great sensationalization SEO words, but words like "synthesis", and "merge commit" are more what comes to my mind when talking about the mainstreaming of hacking. Perhaps I'm not being romantic enough?

I'm not afraid that all the "real"* hackers are going to be displaced or that there is no longer a place for merry pranksters. When the source is open, and the platform accessible, and the pipes neutral, and the power transparent, tricking someone into doing something against their own interests is much more difficult. When resources are not allocated in an optimal fashion, it can be made clear, and whether you a suit or a rabble-rouser, waste is in no one's best interests.

(*: regular readers will recall my opinions on dictating hacker identity, and my heavy use of quotation marks here--you are a "real" hacker the moment you pop the hood and pick up the wrench, not when someone else tells you you are)


src: https://badges.fedoraproject.org/pngs/flock-2015-attendee.png

It's finally done, and I've half-way caught up on all the sleep I didn't get during the past week ;) I had a ball seeing all you Fedorans strolling around my regular haunts, and cannot wait to see you all again soon. May your travels home be safe and expedient!

Please be patient with me for the next day or so as catch up on my inbox and all the administrivia and loop-closing that comes along with hosting a conference in your hometown. Once that is taken care of, I'll be spinning up a proper recap and redux blog post for FLOCK 2015 (aka FLOCKchester).

While we wait for that, if you did attend the conference this year, you should

totally fill out the official survey with your feedback thoughts and suggestions



src: https://badges.fedoraproject.org/pngs/proven-packager.png

Another treasure trove discovered this week! Last time, it was all the tasks required to release Fedora. This time, it is the master list of all the packages in Fedora!!eleven!


I still cannot get over how cool it is for my $DAYJOB to be in a community that ships an entire operating system, and the stupendously grand scale on which that type of development occurs... Totally ridiculoustown...


src: https://openclipart.org/image/300px/svg_to_png/223140/1437199221.png

Since I got here, I've been doing my best to create a mental map of all the parts of Fedora. From what I've gathered thusfar, there are 13 subprojects (See: wiki sidebar), along with a number of web properties, and a slew of upstream communities that Fedorans are tapped into. But even after getting the broadest sense of how many moving parts there are, that still doesn't explain HOW, only who. I've said to myself "Gee whiz, if only there were a list of all the things that needed to be done to ship a release..." Today, thanks to jzb, I have found the HOLY GRAIL of "how a Fedora becomes a release" and I'm here to share it with you too!



src: https://openclipart.org/image/300px/svg_to_png/223287/Come-In-Were-Closed.png

I am a license pluralist. I think Author and contributor choice of distribution is important, and we need to have as diverse a toolbox of legal instruments as possible, to fit as varied a field of softwares as we can conceive.


The "Freedom to close" is not a freedom.

The "Freedom to exploit" is not a freedom.

Your organization not adopting copyleft software, is not a failing of copyleft, it is a failing of your organization to participate authentically in an Open ecosystem of innovation. It is your organization saying "I want to keep my options open, in case there is ever a time when it would be convenient to cut you out of the equation."

Folks might say "Yeah, that is what doing business at arm's length is!" or "By nature, people are greedy and/or selfish!"

And that is exactly why we have contracts and licenses! We use them all the time in non-copyleft contexts to ensure that both parties hold up their end of a clearly defined agreement.

So why-oh-why is there some sort of virtue in entering into an agreement that would allow the other party to renege? The freedom to break a social or business contract whenever it is convenient, implies that you think you can outmanoeuvre the other party, and that your strategy's real strength is subterfuge, not what you bring to the table.

That is not what genuine collaboration is. It is an okey doke, and contributors are falling for it left and right against their own interests.

CommOps Toolbox

src: https://openclipart.org/image/300px/svg_to_png/660/JicJac-Parts-Container.png

I can build, but I am certainly not the fastest. Slowly but surely, with help from lmacken and threebean and qalthos, I've been loading up the Commops toolbox.

CommOps Tools in the Box


One of the first data visualizations I worked on after being hired, this was one of the fruits of the PyCon 2015 Sprints. Cardsite displays fedmsg activity as a 3 part grid, with the top pane being messages, the middle pane being users, and the bottom pane being packages. It creates the cell if the message is new and hasn't been seen before, or, if it has been seen, updates the message count, and does a fancy animation. It is a proof of concept, and not what I would call "complete," but it has a number of merits:

  1. Inspired by the EmojiTracker project, that shows real-time usage of Emoji on Twitter
  2. Gulp/Bower to install JavaScript/CSS dependencies in a programmatic way
  3. Deployed to GitHub via gh-pages branch: http://decause.github.io/cardsite
  4. Uses Websockets to provide real-time fedmsg updates to the page
  5. Uses the semantic-ui framework for the front-end


The idea is, take an RSS feed, or a list of RSS feeds, and generate a word_cloud for each feed, and the aggregate content from all the feeds, like so:

python gencloud.py config.json

with config files that look like this:

    "feeds": [
    "mask_filename": "fossboxlogo-mono.png",
    "output_dir": "feedcloud",
    "output_image": "feedcloud.png",
    "stop_words": ["http", "https"],
    "each_corpi": true,
    "max_words": 1000
  1. Individual word_clouds for each rss feed AND the aggregate cloud of all posts combined!
  2. Uses a config file written in json for easy parsing
  3. Once it is set up, it is very easy to create multiple configurations to create many visualizations with ease.
  4. easy to use blacklist within config file for easy tweaking.


  1. word_cloud is a very powerful, but also very heavy-weight stack to stand up and run. After many attempts, I finally got my first virtualenv working, and I've been using the same one ever since in all my word_cloud related projects :/


Arguably the most complete of the tools in the box, it builds upon the work of feedcloud and word_cloud to deliver fancy wordcloud visualizations via Twitter each time an IRC meeting ends and sends the logs message across the fedmsg bus! This tool is "deployed" on my machine locally as a systemd service, but will hopefully be deployed to Fedora Infrastructure in the near-ish future (packaging the word_cloud stack for Fedora is low on the priority totem pole for me personally, but def a goal I'd like to deliver on in the next 120 days (but probably not the next 30/60/90.) You can glance the fruits of wordcloudbot's cycles on the Fedobot twitter account.


fedora-stats-tools is a breeding ground for interesting one-off scripts and tools. It is the default place where various CommOps experiments are being pushed to, before they end up in their own repositories. Here is what we've got in there so far:


    This is a very basic script that uses the requests library to get the raw json for fedmsgs over the past year, and pulls out the final field of that raw json response, which includes a total number of messages.


    A jinja2 template that creates links to meetbot activities for each subproject. This is an "artisinal" solution we're using to aggregate datagrepper information prior to the completion of hubs. The challenge is to *not* engineer something, but write as light-weight of a tool as possible to give us raw data. There is also a cronjob running locally on threebean infrastructure to send me a daily reminder to compile the stats from the information gathered by this template.


    A descendant of meetbot-fedmsg-activity, this jinja2 template takes lists of URLs, if they are not empty, and generates a "daily briefing" with things like action items and links generated by meetings and captured by zodbot. Ideally, these lists will be compiled by using BeautifulSoup in the near future, so that every day, the briefing can be shipped without human interaction (and perhaps tweeted by fedobot, but that is another project for another time.)


This particular tool and its purposes was covered at length already in a previous post: http://decausemaker.org/posts/grokkingfedmsg.html

Why a toolbox?

Well, I wanted to include a bit of this in my last post, but for now, here is the gist: The position of Fedora Community Lead has not existed before I had the privilege of filling the slot. There are *many* duties and responsibilities, defined by many stakeholders, and right now, I'm a one-man army looking to deliver on each of them. "Linus does not scale" and neither does decause. I'm working on making each of my contributions "autonomous" so that they do not block on a single person, and can invest the labor needed to deliver on these metrics once, and the deploy/redeploy multiple times as needed. It has been somewhat slow going, but it is my hope that each of these tools can help each problem space or bucket within the CommOps ecosystem of initiatives (see: http://decausemaker.org/posts/proposal-commops-for-fedora.html for the full proposal, and/or contribute your thoughts on the wiki here, https://fedoraproject.org/wiki/CommOps)


Metrics is where we've started. It has been a small core of folks working, but the spirit of the Community Operations team should start to become more clear as these types of tools get built. I'm still learning my way around this massive community of FOSS hackers that is Fedora. I still don't know where all of the corners are, or who all the people that make each of those legs gallop with the whole are, but I sure want to. Someday (150ish days from now) there will be FedoraHubs, which is really the ultimate manifestation and incarnation of Community from the amazingly-sleek-and-powerful real-time infrastructure that is powered by the fedmsg ecosystem, but until then, things are going to have to be a bit more manual until we can get there. If you'd like to help tell the story of your particular corner of Fedora, or would like to help provide the "10,000 foot view" on the project's contributor base, then by all means please reach out in IRC (#fedora-apps on freenode) and let me know. I'm here to help, but I sure could use some too :)


src: https://openclipart.org/image/300px/svg_to_png/3812/FunDraw-dot-com-Girl-In-Rowboat.png

Hi There! It has been a busy couple of weeks! Thankfully I'm done travelling for a little while (and hopefully done with RedEye flights forever too... /me is getting too old for that bizz)


The Fedora Release Engineering FAD (RelEngFAD) gathered 15+ contributors from across a number of projects and teams to discuss the future of "shipping bits to users." As I am still new to this side of the project, I was able to learn more about how this ecosystem operates over those five days, than I had osmosed over the past five years.

https://fedoraproject.org/wiki/FAD_Release_Tools_and_Infrastructure_2015 Etherpad Link

I've got a bunch of inbox and administrivia to catch up on for now, so stay tuned for more granular updates to come!