Tag Archives: opensource

Triple Bottom Line in Open Source

One of the more thought provoking things that came out of the OpenStack leadership training at Zingerman's last year, was the idea of the Triple Bottom Line. It's something I continue to ponder regularly.

The Zingerman's family of businesses definitely exist to make money, there are no apologies for that. However, it's not their only bottom line that they measure against they've defined for themselves. Their full bottom line is "Great Food, Great Service, Great Finance." In practice this means you have to ensure that all are being met, and not sacrifice the food and service just to make a buck.

If you look at Open Source through this kind of lens, a lot of trade offs that successful projects make make a lot more sense. The TBL for OpenStack would probably be something like: Code, Community, Contributors. Yes, this is about building great code, to make a great cloud, but it's also really critical to grow the community, and mentor and grow individual contributors as well. Those contributors might stay in OpenStack, or they might go on to use their skills to help other Open Source projects be better in the future. All of these are measures of success.

This was one of the reasons we recently switch the development tooling in OpenStack (DevStack) to using systemd more natively. Not only did it solve a bunch of long standing technical issues, that had really ugly work arounds, but it also meant enhancing our contributors. Systemd and the journal are default in every new Linux environment now, so skills that our contributors gained working with DevStack would now directly transfer to any Linux environment. It would make them better Linux users in any context, not just OpenStack. It also makes the environment easier for people coming from the outside to understand, because it looks more like what they are used to.

While I don't have enough data to back it up, it feels like this central question is really important to success in Open Source: "In order to be successful in this project you must learn X, which will be useful in these other contexts outside of the project." X has to be small enough to be learnable, but also has to be useful in other contexts, so time invested has larger payoffs. That's what growing a contributor looks like, they don't just become better at your project, they become a better developer for everything they touch in the future.

To build a better Keyboard

I can't tell you how excited I am that Jesse and Kaia's kickstarter launched yesterday, and met their funding goal in the first 12 hours. A couple of years ago I caught up with Jesse at reunion and heard about the beginnings of this project. He was experimenting with building his own keyboard, and wasn't really sure where the project was headed. He commented that it was interesting that every other part of Doug Engelbart's Mother of all Demos has come to be a normal part of our technology lanscape, except his chorded keyboard. Maybe we were missing something. Maybe there were good ideas about keyboards that we just left on the drawing table.

Over the last couple of years he and Kaia went down this journey to build a better keyboard. Moving out to the west coast, doing a 4 month stint at a hardware incubator, many trips to Shenzen. All the interim steps have been amazing to watch. And the thing they created at the end of the day just looks outstanding.

They are now running a Kickstarter to fund the production of their first consumer unit, the Model 01. It just looks amazing. If you spend 8 hours a day at a computer, you owe it to yourself to take a look.

On Remote Work

As soon as you get beyond a few people, you are working “remotely”. If you aren’t in the same room you will have your main workflow happening through tooling. Yes, you can get together to meet face to face on topics, but that isn’t your general workflow.

via Why we run an open source program - Walmart Labs // TODO: Talk openly, develop openly.

I've never seen that so crisply and truthfully stated before. The whole article is pretty great.

Easy Planet 1.1 released

We lost a few features moving mhvlug.org from Drupal 6 to Drupal 7, as modules just didn't exist. One of the ones I missed the most was the Planet function provided by UD Planet. This was an extremely simple to use module that let you have an attractive Planet (a collection of user blogs) on your Drupal site. The original authors of the module have long since gone inactive. So this past weekend I decided to just port it to D7 and be done with it. It took about 8 hours, and now we have Easy Planet!

Easy Planet 1.1 is now out. This is a straight port of UD Planet to D7. The only functionality which isn't there is the disabling of aggregator menu items, which I'm not convinced was a good idea in the first place. It's live on http://mhvlug.org/planet, for anyone that wants to see what it looks like.

One of the most important things to me was smooth transition from UD Planet installation. Because mhvlug.org was a D6 -> D7 migration, I still had udplanet tables and settings in my database. I wanted the experience of easyplanet to be: turn it on, all your stuff is back. I managed to get it there last night, so I'd be extremely interested in others that are moving from UD Planet -> Easy Planet to make sure it's as seamless for them.

For more info, and to download the code, check out the project site.

10 Years of MHVLUG

logo-white10 years ago today I was on a plane, back from Portland, Oregon, to experiment on something new. For the previous 3 months I'd been working towards a kickoff for a local Linux Users Group.

We had a venue: the Mid Hudson Library System Auditorium. We had a date and time:  Wed the 5th of March, 6pm. We had a speaker: Michael Kaegler talking on Linux Firewalling. We had a mailing list and a website, and could clearly see there was interest in the group. But we'd never had a meeting, so this was the moment of truth.

But I was on a plane, racing to get back for the meeting. A month prior my job had changed, I'd started working on OpenHPI, and I'd picked up some standards work, and that meant a trip out of Portland for a 2 day standards meeting with a lot of Intel folks. I managed to get a flight which "should" get me back in time, but I had a plan B to have a Mike Salerno kick off the meeting in my absence. I landed at 5:15, was in my car by 5:30. The meeting was at least 35 minutes away, and there was traffic. Plan B was going to have to be good enough.

When I walked in the door I was blown away. The room was packed! There were at least 35 folks when I arrived, and over the course of the meeting it grew to 50. Wow. I was hoping that it would be more than just me and a few coworkers, but never had I imagined this. I wondered how long this experiment would run, fully imagining that after two years we'd run out of steam and interest and move on.

It's been 10 years, and MHVLUG is still running strong, better than ever.

For everyone that was part of our first decade, making MHVLUG successful: Thank You. This is a community first, and it's the people that make this awesome.

For everyone that hasn't checked us out yet, our 10th Anniversary meeting is tomorrow. We're going to be talking about: Linux where you least expect it. There will be cake, coffee, and conversation. There will be time for socializing and mixing, to become part of this dynamic community. Join us as we start decade number two.

Source Forge Open Source Again

Apparently Source Forge has gone open source again, and even is an incubated project at Apache. The source code is in git, and the new source forge looks like it's all written in Python instead of PHP.

Source Forge has had a pretty storied history. It started Open Source, all those years ago, then in the dot com collapse they stopped releasing source and instead tried to sell an onsite hosted solution, Source Forge Enterprise Edition. The Linux Technology Center was one of their few customers, providing an internal source forge for the rest of IBM. I had the "opportunity" to help debug some of that code for performance reasons, and discovered that a lot of Source Forge's slowness was due to a major lack of understanding by the development team on how database indexes work. Those fixes flowed upstream.

Later, one of the key developers from Source Forge forked GForge from the last open source release. So we had Open Source "source forge" again. Then a couple years later the GForge team pulled the same stunt as Source Forge, tried to monetize, and seal off the source code.

Then git happened, and all these CVS / SVN based hosting solutions looked really quaint. A couple years later we had github, and the center of gravity of Open Source has been migrating ever since.

Source Forge's current owner is Dice, the job search company, so the economics of keeping it Open Source are a little different. "What's your github id?" is now a standard job interview question, so I can imagine the new Source Forge team has a pretty broad brush to just make Source Forge as good as they can.

I wish them luck.

Refactoring LibreOffice

The FOSDEM 2013 talks are up now, and this one of LibreOffice Refactoring really hit an interesting mark. The LibreOffice team has been aggressively rebuilding a culture of rapid change as a road to quality, bringing in a test and test automation culture, and leaving nearly no parts of the code as sacred.

It's interesting that LibreOffice seems to be doing a much better job than OpenOffice at removing technical debt. I think we're already seeing the effect of that cultural split, and I expect that in the future this is going to get far more obvious.

I can't wait to get the Android remote working for future presentations. Will be a lot of fun to drive my presentations that way.

OpenStack Talk at MHVLUG

On Wed, Sept 5th, I'll be giving the talk on OpenStack at MHVLUG. The last six months working on the project have been really spectacular, great learning curve, really good community members, and a very exciting potential for where the project is going to go. I'm quite looking forward to going back to work next week after this summer holiday, because I can't wait to get back into the code.

I'll provide my personal take with current trends in cloud computing, and hopefully create a lot of in room discussion. We'll go from that industry lens, to a deeper look at OpenStack. I'm a big believer that like operating systems, web stacks, and virtualization, the essential infrastructure of cloud computing needs to be open source.

If you are in the Mid Hudson Valley next Wed, come check out my talk.

Consumers only have control of the past

There is a popular saying:

If you’re not paying for it, you’re not the customer; you’re the product being sold.

This frames our relationships with Google, Facebook, etc. All those "free" web services that are trading in your data.

But there is a corollary:

If you don't have the source code, and are willing to use it, you're not in control of your future; consumers only have control of the past.

This is a lesson lots of large and small companies and governments have learned. It's been a driving force in the rise of Linux and Open Source in general.

Recently, the new "app economy" has started to get hit by this, as this is a broad new consumption market. The sparrow acquisition by google has been a recent flash point.

Hopefully people participating in the app economy are going to start realizing that it does matter whether or not you have source code, and the right to use it to these apps.

Unity and Pidgin

One of the things that happened once getting to Ubuntu 12.04 was that gnome-do started acting up on me. Given that it's a very minimally maintained project, I decided it was time to move on. Ubuntu's dash provides a lot of the same functionality, so I finally started using it. But, I missed a few things.

Gnome-do isn't just a launcher for programs, it's an actions engine. It has support for Pidgin buddy lists, an I even wrote an NX launcher for it. I didn't really want to give either of those up, so I started trying to figure out how to add those to Unity's launcher itself.

Unity lenses, the plugins that support results, are written in either vala or python. Given that I'm trying to reflex my python muscles now, I decided that was my way in. After a few false starts I found the One Hundred Scopes project, which is an attempt to build a whole set of Unity lenses to add functions and examples for the world.

The wikipedia example is a good starting point. It gives you an idea of how to build a custom search and return results. That enabled me to build a basic launcher that fed up file urls for launching nx sessions, and I created an pushed unity-lens-nx that implements that.

But, pidgin is a little harder. There is no file to open for pidgin, this is about communicating with another program over dbus, and catching the action to do something else with dbus. Fortuntately through the help of David Callé I figured it out. Also, once I had it I found some good tricks (and a couple of undocumented dbus methods) here -  https://github.com/gregorl/Unity-Pidgin-Lens which I used as inspiration.

The net result is unity-lens-pidgin.

2 key MHVLUG people online right now

Super + b and search you buddy list. It only displays currently online buddies, and available buddies are preferred over unavailable ones. You can get it via ppa here.

There is plenty more to do. The search results should be smarter, especially taking into account most recently contacted buddies, which means integrating with zeitgeist or something equivalent. Ideas floating around there. I'd like to do some overlays with status icons, just to give a visual clue on either protocol or current status state.

If anyone else wants to help, or has their own ideas, I'd encourage you to join in on the conversation. The One Hundred Scopes community is pretty cool, and I'm happy to make their vision a little closer to reality.