Month: March 2009

Posted on

Don’t go out quietly!

Grandma
This is my grandma. She requested that her funeral procession not go around town and not take back roads. She wanted her funeral procession to drive straight down Main Street honking! When the priest read her request at her funeral mass, he said it was one of the funniest requests he'd ever had.

Her family and friends were more than happy to make sure she didn't go out quietly! We drove straight down Main Street blaring our horns for Grandma! (And we made quite a racket. Grandma left behind 11 kids, 21 grandkids, 23 great-grandkids, their spouses, a sister, cousins, and lots of lifelong friends and neighbors. The kids especially enjoyed honking the horns – Grandma would have appreciated that. Tickled her pink is what she would have said.)

My grandma was an awesome woman. While everyone had their stories to share, I think three main qualities come to mind:

1. Learning. Grandma loved to learn. She did her first years in this one room school house. She then talked her father into letting her attend not just high school but college. For a women born in 1917, that's quite a feat. She never stopped learning. She read a lot and she asked lots of questions. She was always interested in other people and not afraid to ask about topics most people would shy away from. She asked me if I felt guilty for not going to church. (She wasn't trying to pressure me at all. She shared that she felt terribly guiltSchoolhousey if she missed mass, even if it was to help out preparing food for a family after a funeral mass.) She asked Frank about raising a kid as a single dad. (That was after she said she couldn't understand how people who had kids could get a divorce. Frank said "I think I should probably tell you then that I'm divorced and have a kid." Grandma just said "I sure stuck my foot in my mouth on that one." and then proceeded to ask him lots of questions.)

2. Enjoying life, playing games and fishing. My first memories of grandma are of sitting around her dining room table eating chocolate chip cookies and playing cards for days at a time. She always had time to play with the grandkids. Later, as her eye sight started to go too, we had to spend our time doing her other favorite things like going for drives and fishing. Or watching people fish. She was always disgusted that Frank would release the fish – he was throwing away a perfectly good dinner! (FishingAlthough she lived through the Great Depression, Dad said it didn't affect her or her family much. They were very frugal to start with. They grew everything they ate, saved everything, spent very little. Their main entertainment was always things like fishing and playing cards.)

3. I'm not sure what to call this one. Good negotiator, good at making friends, good caregiver? Although she appeared extremely indecisive, over the years, I realized that Grandma always got what she wanted and nobody ever got mad at her for long. She consulted with the whole world on every decision – a characteristic that often drove her kids nuts – but she usually had a strong opinion and went with it. Like driving down Main Street with your horns blaring! 

There is lots, lots more to say about Grandma but I think I'll sum it up by saying she will be missed very, very much.

Posted on

Twittering from conferences

I like twittering at conferences. It's a way to take notes, share insights and start interesting conversations. However, I'm always forgetting to append the event hashtag and I eventually get tired of manually typing it, so I wrote a Greasemonkey script to automatically append a hashtag.

To use it, you have to:

  • install Greasemonkey,
  • install my script,
  • use Firefox as your browser,
  • set your hashtag with the Tools/Greasemonkey/UserScriptCommands/Set hashtag. (Note you have to be on Twitter.com to see the commands.)
  • tweet directly from Twitter.com.

Some notes:

  • Thanks to @marnanel for suggesting I use a Greasemonkey script.
  • I had much bigger plans and started out writing a Ruby program with the idea that I'd create a Ruby on Rails app but I soon realized that I didn't really want to write yet another Twitter client. If Gwibber, Tweetdeck or Twirl would add some nice hashtag support, that'd be great.
  • It's been a long time since I wrote code and I've never written any javascript so this took probably 10 times longer than I think it should have. And it doesn't have enough error checking or any number of cool features I would like but it does what I want it to.
  • While I was looking at Greasemonkey scripts for Twitter, I found a couple of other useful ones like updating your twitter home page without refreshing, endless tweets so you don't have to page, seeing @'s to another user, …

I'll be twittering this week at #osbc.

Posted on

Companies: fostering or controlling communities? An interview with Kim Weins

IMG_3907
Kim Weins is the Senior VP of Marketing at OpenLogic. Kim spent three years as a principal in CMO Strategy Group and helped companies such as Atomz (acquired by WebSideStory), TuVox and
RedSeal to significantly accelerate their marketing efforts. Prior to CMO Strategy Group, she was at PeopleSoft where she was responsible for driving PeopleSoft’s CRM business strategy.

I had lunch with Kim Weins from OpenLogic. We had an interesting discussion about open source companies and how they can either dominate or foster communities. In addition, we also talked about what it’s like for an open source software developer to work for an open source company. She works with many open source developers on a contract basis as well as many open source companies on a partner basis. Her insights were interesting.

Kim, “open source companies” come in many types and flavors – how do you characterize them?

We see two main variations of open source companies – differentiated by the level of ownership and control over their IP. This level of control is important, because it tends to drive their business models.

The first type what I’ll call “IP owners”. These are companies that own and control all of the IP that goes into the open source product. This would include companies like MySQL, Alfresco, SugarCRM, etc. These companies typically have some variation of a dual licensing business model that requires that they control all of the IP in order to license an “enterprise version” of the product in the way they want – often not under an open source license. For these types of companies, typically only employees can commit changes to the project since the company wants to maintain control of the IP. In
some cases, the companies may allow contributions by outside committers, as long as the developer gives IP rights to the company.

The second type is what I’ll call “non IP owners”. This type of open source company typically builds up around an existing open source project that has many committers. The IP is owned by the open source developers or by a third party such as the Apache Foundation. Examples of this type of company would include Enterprise DB, Acquia, or Red Hat (around Linux). Since the company often does not own or control the core IP for the project, the business model changes. These companies typically either sell support and services around the project or create add on functionality that they can then license. Often the companies will hire some or all of the committers on the projects, but typically the projects are open to contributors and committers outside the company to participate. However, there are some cases where these companies try to gain control over the IP by hiring all of the committers so that they can determine the direction the project takes.

While it’s great that developers can get hired to work on their project, sometimes it seems like the open source company hires everyone in order to control the product. Can an open source company hire too much of the community?

When the developers working on a project are limited to people employed by one company, it eliminates a huge part of the value of open source development. The ability to build new capabilities is then limited to what can be funded by one
company – just like for proprietary software. Although some open source companies would argue that they help to support and fund the project in this way, the reality is that they also gain control. If their sole interest was in supporting and funding the project, they would open up to committers outside the company in order to improve the project more quickly.

Many open source software developers do quite a bit of contracting or consulting work, like for OpenLogic’s Expert Community. Does working for an open source company make that easier or harder
for them?

We work with the OpenLogic Expert Community on a contract basis. They are not employees of OpenLogic, but we pay them for the work they do to help support our customers. This allows them to continue to work on other projects (whether for pay or volunteer) as they see fit. However, in recruiting these open source developers, we find many cases where their employer, whether a proprietary or open source company, tries to limit their ability to work on open source (whether for pay or volunteer). Companies do this through employment agreements that specifically limit a developers ability to work on outside projects, either by requiring IP assignment of anything they develop to their employers or by explicitly forbidding certain kinds of outside work. These restrictions may make it harder for developers to participate in the open source community as they see fit.

Do companies often foster open source developers? i.e. if you want to get going working in open source software, is getting a job with an open source company a good way to get started?

In some cases, companies do foster open source developers. However, the companies that do so by trying to tie developers hands are doing a disservice to the developers, the open source community, and eventually themselves. When going to work for an open source or proprietary company, open source developers need to be careful to negotiate the freedoms that are important to them – such as having the right to work on other open source products and the ability to retain IP rights in the work they do.

As well as the ability to work on non-related open source software projects in their free time!

Can you give an example of a company that you think is doing a really good job of working with the community or maintaining an independent community?

I would cite two examples that represent how companies can be successful while maintaining an open community. The first would be RedHat around Linux development. Linux is not controlled by any one company – rather it is contributed to by multiple vendors as well as independent developers. Obviously full credit for this can’t go to RedHat, since they need to work within the constraints of how the Linux project is structured, but they have done a good job of demonstrating that you can make money and be  successful without controlling the IP.  It remains to be seen if that same model will be true for JBoss.

The second example would be Mozilla around Firefox. Mozilla has developed a business model that seems to work without limiting community involvement.

Many companies have open source products but not an external open source community, what benefits of open source software do you think they are missing out on?

There are several benefits of open source, but some of the most important benefits come from having a broad, diverse and open community. By doing so, there are economies of scale by sharing the development and maintenance efforts. There is also a breadth of requirements and a breadth of technical solutions that may be limited when all developers are internal to the company. Companies that don’t stay open to a community that extends beyond their employees will really be returning to some of the limitations of proprietary software.

Thanks, Kim.

Anybody else, thoughts to share on open source companies, communities and employment?

Disclaimers: I used to work at OpenLogic and I still occasionally do some writing and consulting for them. OpenLogic pays open source software community members to support open source software projects on an issue by issue basis for Global 2000 companies. I approached Kim about doing this interview.

Posted on

Book Review: Why Work Sucks and How to Fix It

Why Work Sucks and How to Fix It
is a great book.

I've always thought that traditional work would eventually transition to contract work where people get paid to produce certain results. The problem with that is not all work fits contract work. Cali and Jody have envisioned (and implemented!) a workplace with traditional employment instead of contract work where people are measured by results, not time. I think that's pretty amazing. They call it ROWE, Results-Only Work Environment and they've implemented it at Best Buy.

The problem with most work environments today is that they reward the amount of time we work, not the amount of work we get done. The authors suggest a couple of strategies:

  • Stop making negative comments about time, "Sludge". So don't joke about how late someone got in, don't apologize for getting stuck in traffic, don't note what time email was sent. "Stop using the words early and late and antiquated terms like by the end of business today. Stop talking about how many hours you work or how hard you're working."
  • Make sure you are results-orientated. Every employee should know what their goals are and be measured on their results, not hours worked or time in the office.

By doing this, you treat employees like adults, they'll be happier and they'll do more real work as opposed to more made up work to look like they are working. (Like arriving at 7:30am and reading the paper online for the first hour.)

While the authors had a lot of good advice and how to, I wish they'd spent less time talking about how great peoples' personal lives are in a ROWE environment (I buy it but I think their examples just made ROWE seem like a boondoggle.) and more time on how much more work gets done. Because in order to get companies to buy in to ROWE, they need to understand that much more work will get done. Or at least the same amount of work will get done and employees will save hours and hours of "being in the office" or attending unnecessary meetings.

I also think that open source embodies the results-only model. In open source people only see what is done. They don't care how many hours you spent sitting in front of your computer. They don't care how many meetings you attended or how many conferences you went to. You are measured by what you get done. (I also think they are pretty good at recognizing non-code type work, but that's for another blog post.)

FYI, I liked the book Why Work Sucks and How to Fix It: No Schedules, No Meetings, No Joke–the Simple Change That Can Make Your Job Terrific much better than I liked the authors' blog.

Posted on

Trains, trains, trains!

We recently rode the train in Napa. Our two year old was just delighted. (Especially since the conductor gave him a lollipop every time he came around.)

Train-med

But then it got to be too much:

Train-sleep-med

We all enjoyed the scenery:

Flowers-med

Posted on

Open source enables companies to collaborate

Dave Neary gave me his speaking slot at OSiM USA. I have two challenges, make a talk to fit his title and abstract (although you can almost always safely ignore the abstract) and give a good talk in 20 minutes of time. Here are some thoughts I have. (The title of the talk is Increasing Ecosystem Collaboration through Open Source but I'll let Dave blog that talk.)

Open source software has proved that collaboration between individuals, regardless of geography, time and management structures, can work really well. The open source software model works:

  1. Self motivated. Open source software developers get things done. They don't need to be reminded of what's important or how much work they should be doing.
  2. No management. There are no managers in open source software. There are leaders but people don't work for a manager who tells them what they need to work on first. (A friend of mine once worked all weekend on a customer problem only to have his manager tell him on Monday that if he was going to work all weekend there were other things he should have been working on!)
  3. No time clock. Nobody cares if it took someone 10 minutes or 10 hours to write that patch. They just care if it works and when they can get it.
  4. No performance reviews. There's lots of peer review and lots of feedback – perhaps more than anyone wants – but there are no annual performance reviews tied to raises and promotions.
  5. Fast. While it may not always seem so, things get done very quickly in the open source model. Someone has a good idea and they just do it.
  6. Bad ideas die. On the other hand, bad ideas just die. Nobody keeps pushing for them – or if they do, they can't get other people to waste their time on it.
  7. Evolves. Ideas and projects in open source software evolve as the world changes and new people join the project. (And nobody is paying big money to keep it the same.)
  8. Work gets done. Even without anyone telling them how to do it and what to do, work just gets done.
  9. Communication is great. While it may not always be friendly, communication in an open source software project is great. Everyone knows who is doing what, what decisions have been made and everything is publicly disclosed and documented. In a completely virtual and global environment. If communication isn't great, the project usually doesn't last.

Some companies have figured out how to work well with open source software. Now we need companies to figure out how to work together in an open source way. While some companies have figured out how to work together, either through consortia or through their employees that work on the same open source software projects, others are still figuring out how to collaborate and still keep a competitive advantage. Open source enables companies to collaborate.

Take GNOME Mobile. Many companies are working together, producing very different products, all built on GNOME technologies that are being adapted to new mobile devices. They collaborate on the technologies. On their ideas. And avoid reinventing the wheel. Not only are they using existing GNOME technologies, but the changes they add to make it work well in a mobile environment (whether it's netbooks, scientific devices or phones) and can be used by others who share the burden of maintaining and developing it. Without losing their competitive edge.

So how can companies get involved and cooperate with other companies effectively?

  • Join any consortia or group related to your project, like GNOME Mobile and the GNOME Foundation. This is a good first step as it enables you to meet all the players and often you can find friendly mentors and people to help. Sometimes this is as easy as joining a mailing list. Other times it means paying a membership fee or going to an in person meeting or a conference.
  • Join the discussion. Join the mailing list, irc channel, comment on blogs. Listen and participate. Become part of the community. (You might want to do this before you officially join.)
  • Hire developers or contract companies. Open source software works because lots of people work on it. You'll get a lot of good stuff for free, and people will be glad you are using it, but you'll want to have some technical resources to fix a particular bug, add a specific feature or adapt the open source technology for your product.
  • Use the software! Use the open source software out there. By using it, asking questions, suggesting changes, you'll become part of the community.
  • Let people know you are using it. Several of the products using GNOME Mobile technologies have never told us. We've "discovered" them. We'd be more than happy to work with them.

Any other things companies can do? (As people who have seen my more recent talks can attest, I use the ideas people leave in comments. Thanks!)