OSCON: Instantly Better Vim

The last session I attended on Friday was Damian Conway’s “Instantly Better Vim" presentation. Damian’s sessions are always popular and I made a point to head over the to the session room early. Unfortunately he was given a positively tiny room for a session that well over 100 people wanted to attend. It took a few minutes for staff to magically make a larger room available and even then there were dozens of people standing near the walls of the room. Damian is as popular as ever!

At the risk of dating myself, I’ve been using Vi/Vim for over 20 years and think that I’ve gotten pretty good at it. Yet, there are things that annoy me about it and that there are always new things to learn about Vim, so I was jazzed to see this presentation. I was expecting to not blog this session, since it is really hard to blog what Damian says — his amazing presentations move at a breakneck clip that all but the best bloggers in the world can follow. Not I! But, Damian, saved the day by making his presentation available to anyone!

If you use Vim and want to improve your Vim configuration to become much more effective, then download his presentation:


I would recommend going through this presentation step-by-step and evaluating each section to see if you want to change your setup to include his recommendations. As soon as I have some time, I plan to do exactly that. Let me give you one example to show you the amazing things he conveyed in this session:

Temporal undo: This feature saves your edit history even after you close a buffer (stop editing a file)! You can go back to any version of a given file, since you turned this feature on! If you want to go back 30 seconds in time, type:

:earlier 30s

This trick allows you to make discrete steps in your edit history, without carefully having to undo and later redo a buffer. You can move back and forth with great ease. To go forward, use:

:later 30s

Stunning! You can use seconds (s), hours (h) and days (d) as time increments. This is almost like having a version control system inside your editor. :) Please download his presentation for details on how to turn this amazing feature on.

My favorite quote from Damian about using and configuring Vim:

Vim is infinitely configurable, as long as you’re infinitely evil!

Some of the things that Damian does in his configuration gives people the willies, but they work well and make Vim an even more awesome editor. I highly recommend going through the slides to learn from the master. Thanks for the awesome presentation and thanks for being an aswesome cat herder before the session, Damian!


OSCON: jQuery: Mobile Sites That Feel Like Apps

This morning I attended Anna Filina’s “jQuery: Mobile Sites That Feel Like Apps" session. Anna’s session was loaded with lots of good slides and live demos, which makes her talk hard to blog. But, I learned quite a few things in her session, so I’d like to write up a short blog post covering the most salient points of her talk.

First and foremost, I didn’t know that jQuery Mobile existed — I love jQuery, so I was curious to attend Anna’s talk. Her main point was that you can design mobile HTML5 web pages that load fast, look and act like mobile applications. With jQuery Mobile it is possible to load multiple “pages” in one actual HTML page and have the browser “load” new pages based on user actions. In reality all jQuery merely shows a different <div> for each faux page load. The styling of the CSS makes the applications look like an actual phone app — quite slick! She gave a ton of examples of jQuery widgets, like the accordion control, that can be used to effectively and quickly show more data as the user needs more data.

Anna reminded us that mobile pages need to load fast, be responsive and keep a simple look and feel. A single HTTP request can take quite a bit of time on a mobile device, so reducing the number of HTTP requests in a mobile site will allow the site to load faster. This is the motivation for packing several “pages” into one HTML page. Only one real page is loaded and switching between other pages requires no further requests, which makes a jQuery mobile page act and feel like a native app.

She also praised the use of sprite maps, which are single images that contain all of the icons you may want to use on your mobile page. CSS can display only a section of the image that you wish to display and hide all of the other icons that are in that one image. This requires a little more work, but all of the images for your page load in one HTTP request, which also makes the mobile page load much faster.

Her final point suggestion was to use the officially hosted jQuery and jQuery mobile files. If a user loads another mobile web page that uses jQuery mobile and then loads your page, the browser cache will already contain the jQuery files and one or two HTTP requests can load the entire mobile site. A clever trick for keeping mobile sites snappy — as long as you can get over the fact that someone else is serving portions of your mobile web page. For some geeks who love to be in control of everything that may not be such a comfortable thought.   

Thank you for your informative session about jQuery, Anna!


OSCON: How The App Store Killed Free Software, And Why We’re OK With That

One of my favorite speakers at OSCON is Robert “r0ml” Lefkowitz — his talks are always fun and uhm.. informative. Though following his talks with intent blog them later is fraught with peril. If you’ve never had the pleasure of hearing him speak, I would describe the experience like this: R0ml gave a great talk, made us laugh, made some excellent points, delivered a punchline and then took it all back with a giant smile and shout saying: Just Kidding! I’m never sure what I should believe, but I do know that its always entertaining to listen to his presentations. 

Today, I’m going to make an exception — I will blog about his session, but I wont attempt to convey his talk fully. Instead I will share just the main point of his talk because its a valid point and it gives me cause for concern.

R0ml is concerned about the rise of the app store (and this is not specific to any one app store) and the effect it has on the open source community. He started off his talk by asking how many people had downloaded the OSCON app. A show of hands suggested that most everyone had done that. He then asked if any of us had bothered to ask if the source was available. Dead silence in the room. No one had, it appeared.

Next, he posited that many app store users will download multiple apps when trying to find one app for a given task. If the first app works, then few people will even bother to try the other apps they downloaded. R0ml also gave statistics about the number of times apps get used; most apps only get used once or twice before they are forgotten.

These are signs that the app store is changing how we use and interact with software. How does open source fit into this model? Is there a direct danger for open source? R0ml left us with this slide:

"Free Software" is of interest only to the software literate.

For Free Software to remain significant, most people must become software literate.

Is this true? Do you think the app store is endangering Free Software? R0ml will be writing a book about this and is soliciting feedback, ideas, suggestions and criticisms on this topic. Please feel free to post your comments here and I will point R0ml to them later.

Thanks for the thought provoking talk, R0ml!


OSCON: Open Sourcing User Experience Design

The main portion of OSCON started off this morning and I dove right in; my first session was “Open Sourcing User Experience Design”. Last year at the SF Music Hack Day I had the pleasure of working with another hacker and a designer for the weekend. Our hack Huesound clearly benefitted from having a designer as part of our team — our hack was one of the most polished hacks at the entire event. I think the open source world has finally realized that designers have to be an integral part of the software design process, so I was keen on checking out Jeff Gothelf’s session.

I had hoped that Jeff would talk about how to bring the UX design principles to open source projects. However, Jeff’s main point was much more fundamental — that designers need to open the process of design to the technical people with whom they work. Apparently the cooperation between hackers and designers isn’t as far along as I had hoped.

Jeff started out tell us the story of how he graduated from University and then literally the next day joined the circus and started touring. He gave us some background on circus life and how foreign life is compared to university life. He likened the software development process to the circus; its riddled with jargon, nicknames and weird teamwork. He believes that designers relish their creative process as a black box and that many designers revel in the fact that the process is opaque to outsiders. This mystery gives designers power and to an extent makes them heros, but in the end it can stifle the process of creating useful and intuitive software.

The mystery is detrimental, initially to the team, but then also to the project and ultimately the company. It creates an us vs them culture and it doesn’t allow the teams to build a common language which leaves all sides feeling misunderstood. In order to get the project done, the burden shifts to the project managers who have to go out of their way to act as a conduit between the various teams. Without this much needed transparency there is no trust, yet trust is core to the team’s success. To overcome these problems, designers must open source the design process; the onus is on designers to do this.

When Jeff first articulated these ideas, he received very strong pushback from a number of people. One person suggested that Jeff was delusionally thinking that this process could work. Allowing anyone to be involved in the UX design process would create an unproductive mess. “Pandering” to the team and seeking feedback from the team would bring in wayward, uninformed wrong ideas that leads to diluted quality of the work. Clearly, this person giving Jeff pushback had never been part of an open source development effort that thrives with these exact ideals. Another person said: “Doesn’t this make everyone a designer? Is everyone a hero now?” Jeff suggested that we need to move away from the hero model and getting everyone more integrated with the rest of the development process. Designers need get over this!

The final point of pushback related to the art of design and that increased transparency would be akin to the design process’ gut showing. That may not be pretty (and Jeff has a great slide of a not so pretty gut — great choice Jeff!) and that it would expose the more subjective side of their trade. Not all decisions are objective — a lot of the designers work is subjective and a designer may say “I thought this looked good!”, when being asked about why something turned out as it did: “There wasn’t an objective opinion that went into this”.

I find it interesting that these arguments parallel the arguments against the open source process — people initially pushed back on the idea of letting others play with unfinished software. The amazing software written by the open source world demonstrates that transparency is vital, even if the details of the process are not flattering. Jeff went on to offer three examples of design in an open manner:

  1. An architect in the UK was faced with a challenging design process for a structure that had to stand on shifting ground. By looking towards nature and bubbles he was able to open his design process to create a design that met all of the constraints for the project.
  2. Illustrator Marc Sheff creates online shows that demonstrate the process of how he creates characters for his art. By exposing his process he is taking an open source approach to design.
  3. The site Typekit exposes some of the jargon of font design by visually explaining the complex concepts behind the process.

Jeff then talked about his suggestions for opening up the design process and suggested these four steps

  1. Draw together: Have everyone sketch solutions and ignore nay-sayers — if everyone can sketch a triangle, circle and box, you’re in. Share trade secrets to encourage participation.
  2. Show & discuss raw work frequently: Retrain your colleagues on this important point. The more raw a work is, the more malleable it is. Work to maintain perception of malleability.
  3. Clarify & define: Opportunistically explain basic design tactics. Ask your designer why they do what they do!
  4. Encourage transparency: Tell everyone what is going on. Use the tools you already have to do this. Avoid strangers in strange lands and level the playing field for all members.

When Jeff started closing, he hit the nail on the head for me! He said: Designers should come to coding parties! Yes, agreed 100%. I’ve seen this first hand and I will make every effort to invite designers to future hack days. Jeff’s final point was to call out his fellow designers: “Designers are not inviting coders (to their design parties). We should be inviting them.”

Well said Jeff — thanks for opening our eyes a little more about the creative process in design. Every software team should have at least one designer who is looking out for the usability of the software. Especially open source software should heed this advice — now we need to figure out exactly how to do that. Maybe thats a topic for next year. :)

Thanks for your talk Jeff!


OSCON Data 2011: Drizzle, Virtualizing and Scaling MySQL for the Future

I’m excited to attend OSCON Data and OSCON in Portland again! This year the O’Reilly team added two new conferences to the already excellent OSCON conference: OSCON Data and OSCON Java. Sadly I wasn’t able to break away from work sooner, so I’ve only been able to check out the tail end of OSCON Data. I have to say that I am somewhat surprised that my data focused MusicBrainz project isn’t really part of the target audience for OSCON Data. It turns out that OSCON Data focuses on large data sets where NoSQL, MapReduce and Hadoop rule the world. A dataset that has maybe 25 million rows (like MusicBrainz) doesn’t really fit into this conference — 25 million rows is small potatoes.

That said, I jumped into Brian Aker’s session on “Drizzle, Virtualizing and Scaling MySQL for the Future" to get an update on Drizzle. Drizzle re-architectures MySQL and is now one of major forks of the MySQL project; Drizzle focuses aimed to simplify the database and review many of the architectural decisions from the last 10 years. I find Drizzle fascinating since it makes a clear break from its long and popular history all while there is great political upheaval surrounding the MySQL project.

Brian started out talking about the motivations of starting Drizzle. In 2005 when MySQL 5.0 came out and supported stored procedures and triggers, a number of users considered these new features to be anti-features and worked to remove them in their own instances of MySQL. I know I was very much on the other side of the fence — I switched from MySQL to Postgres many moons ago because of the lack of transactions, triggers and stored procedures. This realization caused Brian to take notes about how MySQL users wanted and did not want in a database. Brian also wanted to remove legal obstacles in Drizzle in order to get as many people involved as possible and not to have people get stuck on dealing with complicated license issues. In the end a highly customizable modular database that uses the BSD license was the goal for the Drizzle project.

Drizzle set out to remove a lot of gotchas that plagued MySQL for many years. This included sane handling of NULLs in the database, an improved 64 bit timestamp, and an overall 64 bit architecture that assumed that 64 bit machines would be standard by the time Drizzle was complete. Drizzle also supports IPv6 and was architected with as a full transactional database from the beginning; assuming full transactional support from the beginning allowed the team to remove a lot of non transactional code and to simply many other things. The team also challenged notions that key caches and query caches were essential to a fast database system; it turns out that removing these core components didn’t have any effect on the performance of the database. Having less code means having fewer bugs! Finally, character set support was challenged: After some research into UTF-8 with Asian data the team decided to support only UTF-8, since UTF-16 use and UTF-8 use proved to have about the same performance characteristics. The web operates on UTF-8, so why not simplify things further by only supporting UTF-8?

The next topic that the Drizzle team examined was replication support. MySQL has had it for a long time, but its always been buggy and a source of frustration. Brain said that the Drizzle team decided to use Google’s protocol buffer for is replication and to only replicate row transformations. Its replication already integrates with RabbitMQ, Cassandra, Memcached and Gearman. Drizzle also opted to remove the binlog and to have only a transaction log — only the transaction log gets replicated, which removes the difficulties in having two logs and greatly simplifies replication overall. Having made all of these decisions, replication in MySQL is now really simple — Brian wrote an initial proof of concept replication system using Python in just half an hour! And even more amazingly, Drizzle supports up to 10 masters in a multiple master replication scheme!

libDrizzle, the library for talking to a Drizzle server, can talk MySQL, Drizzle and SQLite dialects, which allows an application that was architected to use MySQL to use Drizzle without any changes! This asynchronous library uses the BSD license to get around legal problems and other pesky license issues — everyone knows how the license works and its compatible with everything. This allows developers to develop and not worry about legal ramifications and licenses.

Next, Brian mentioned that virtualizing databases via Xen or VMware incurs a 30% - 40% overhead. To avoid this overhead Drizzle added catalog support that separates users inside of one single Drizzle instance. Using only one instance of Drizzle in one OS instance, multiple catalogs provide the same features as running multiples instances of Drizzle using a virtualization technology. There are no actual means for one user to access data from another catalog for security purposes, which makes security between catalogs a non-issue. Users can still use multiple schemas inside of one catalog as they would expect to, which effectively virtualizes Drizzle without the 30% - 40% overhead.

Finally, Brian mentioned that the Drizzle team takes testing quite seriously. Every source code push will not only be tested on multiple platforms, but also performs a complete performance regression test! Each push is also tested on various multi-core machines to make sure that no bugs can sneak in that only appear in certain configurations.

I find the Drizzle project fascinating since many brilliant people working on this major re-work of one of the most popular open source projects out there. With political turmoil in the wake of the Oracle acquisition of Sun and many MySQL developers shuffling around, its amazing to watch this dedicated team of people working hard on the technology simplifying everything including the licenses. I’m a die hard Postgres user, yet I’m very interested in watching the Drizzle development. Re-working a major codebase over a number of years and keeping the project relevant is quite challenging. I have much respect for the work that the Drizzle team is doing. Keep it up, I can’t wait to see where Drizzle will go in the future!


OSCON 2011: Fundraising 101

The last session I attended today was Cat Allman’s “Fundraising 101” or “Free as in Freedom, so who pays for the beer?” session on the basics of open source fundraising. She started out stating that its clear that open source projects need money: Bandwidth/hosting, hardware, travel costs, meeting in person and the all-important t-shirts all cost money. How can OSS projects raise money to support their project?

Cat says: “Asking for money is hard”. Therefore you should have a basic plan for raising funds. You will need to determine what your project needs and setup a budget to carefully examine on what you’re going to spend money. Remember to add a bit of cushion into your budget to cover unforeseen expenses. You should set quarterly, annual and long term fundraising goals to support your budget. But, raising funds isn’t all about asking someone to give you money; you should consider if your project has something to sell. Can you sell schwag with your project logo? Can you sell CDs with your software? Anything you can create that people are willing to open their wallets for are fair game. Be creative, but make sure that you have buy-in from your community when deciding what to sell. When fundraising, make sure that you have responsibilities for bringing in funds carefully assigned to people who are helping you fund-raise. People need to step up to the responsibility for raising funds in order to reach your goals.

Cat continued on to tell us that there are many forms of sponsorships: From small amounts of money to large amounts of money; in-kind donations, grants and software bounty programs. Though, Cat cautions about bounty programs that reward certain features with financial rewards. They can work in some cases, but its also easy to have your project turned into a code-for-hire project that may distract from your goals. It all depends on what your project goals are. One easy way to accept sponsorships is to setup a PayPal account — whether or not you like PayPal, its easy and relatively cheap to use. However, she cautioned against trying to accept credit cards over the net, since that has many pitfalls and has quite a few costs. Note: You can easily and cheaply accept credit cards with a PayPal account.

There are many types of sponsors as well: Individuals contributors like friends or fans of your software; small businesses in your communities or businesses that use your software. Look at your download logs to see which businesses use your software and consider approaching local, state or federal governments and foundations. And as most open source developers have day jobs, you might try and ask your employer for financial support.

Sponsors will likely be interested in buying visibility in your project, like having their name/logo on your website. You may also opt to sell ads on your site (for products, companies or help wanted ads), but you will need to be careful about your community. A lot of open source communities do not look kindly on ads, so be careful. Cat also suggested that you stay away from selling your email list of your users — many open source people hate this and would not look kindly on being spammed.

Once you’ve managed to get someone to commit giving you money, you’ll need to arrange how money will be accepted. There are tax ramifications that relate to accepting funds, and Cat suggests that you get professional help in determining how to best do this. Don’t put funds into your personal checking account, since that will surely create a nightmare come tax time. You’ll also need to keep careful records of what is happening with the money your project received. Again, getting professional help from an accountant will save you a lot of trouble later. Cat warned to not procrastinate on collecting your funds — all too often people forget to collect their money. Be prepared for the process of billing a large company for the donation to take quite a while — don’t procrastinate.

If you do not have a non-profit company that can accept donations you may want to consider working with an organization that specializes in helping smaller open source project accept funds. The Software Freedom Conservancy, Software in the Public Interest and the Apache Foundation work with open source projects in this manner. Cat also cautioned about starting your own non-profit company since the IRS may not consider all open source projects fit for being a non-profit. The question of wether or not you should start your own non-profit was beyond the scope of this talk and Cat encouraged the audience to hold talk about this at the next OSCON.

When you’re making a pitch to a company, you should be well prepared. Most important, put yourself into the shoes of your sponsor — does sponsoring your project make sense? When you submit materials to a company, make sure that your contact info is on the materials and make sure the name of the project and URL are clearly visible. Consider giving a brief background on your project and offer to provide more information on request. Make sure to convey what your project does, how many people are involved, who it helps and why it matters to the world. Finally, Cat stressed that you should never expect that people owe you anything. Just because these companies are using your software doesn’t mean that you are entitled to anything. You don’t get to demand a pony and you don’t get to pick the color.

If you’re trying to get a sponsorship for an event, Cat stressed that you should provide complete information on your event. Provide online materials and a PDF for the company to evaluate you proposal. As with other materials, make sure you mention the name of the event, the URL, provide your contact information and state where and when the event will be. Also provide information on the expected audience and how many people you expect to attend your event. If your event has a program committee, provide details for the committee; if there are different levels of sponsorship for your event, make sure to include details about the different levels of sponsorship. When throwing an event, make sure that you consider the following things: Conference networks, insurance, first aid (some venues require this), unexpected costs, an anti-harrassment policy and bathroom capacity.

When you’re getting ready to ask for money, Cat stressed again that you should put yourself into the shoes of your sponsor. Then, you should make it easy to give you money — if its hard to give you money, chances are that it won’t happen. Make sure to give complete contact information on your materials and don’t use proprietary means for making your pitch — Facebook is not a proper venue for asking for sponsorships. While this should be obvious, Cat reminds that you should be polite when making a pitch for a sponsorship. Finally, ask for help and at the same time offer to help resolve any questions or issues that might arise in when the company evaluates your proposal.

To wrap up, Cat offered tips for things to avoid: Don’t put donations into personal accounts! Don’t ask for too much money — it puts off sponsors. Don’t over promise things that you can’t deliver. Don’t forget to send the invoice for money when your sponsor has agreed to sponsor you! Finally avoid the baby ducks problem, where an organization continually pesters potential sponsors all the time. Taking up too much time with one open source project is not a good way for a potential sponsor to spend their time. If you have several occasions in a year to ask for sponsorship from one company, consider rolling up all of the requests into one annual request, so that you don’t annoy your sponsor.

This concluded Cat’s presentation and she took questions from the audience. One audience member had one important point: If you solicit money from the general public and you don’t have a non-profit, do not ask for donations. According to the IRS, only non-profits can ask for donations — and whatever you do, avoid trouble from the IRS. It will only cost you money and waste much of your time!

Thank you so much for your presentation on how to raise funds, Cat! Next time I personally go begging for money from Google, I’ll use your advice to hone my pitch. :)


OSCON 2011: A new era of Community Management

Here is a post from last year that never got posted in time:

After Jono plugged his session in his keynote talk, I decided to attend his full session entitled “A New Era Of Community Management. After reviewing the basic premise of his keynote, he started building his argument by reviewing how community management has evolved over the short life time of open source software. Jono argued that the early leaders of the open source movement never set out to be leaders. Instead it started with people like Linus Torvalds who wanted a technical challenge to write the kernel for an operating system. He didn’t set out to create and lead a global revolution. Today Linus is not only the leader of the kernel development team — he fills so many more roles than that.

Linus set examples for conflict management in open source projects, set standards for transparency and for lightweight processes that get solid code written. Linus also enabled the Linux project to grow at astounding rates to incorporate changes from many people to let the development process move along at an unprecedented rate. Jono went on to talk about Ian Murdoch, the leader of the Debian project, who established new community management practices that allowed Debian to establish itself as an important Linux distribution. Ian set the tone for governance of the community, how to conduct yourself in the community and how to efficiently get things done.

Jono went on to speak about Ubuntu and how metrics and reporting play an important role in the project. If you can’t measure and present the results of your efforts, its really hard to show that the project is moving forward. After all, people get the impression that a project is dead if the project does’t continually show signs of progress. Ubuntu also values creating a buzz about the project and holding events that allow community members to meet and collaborate in person.

Wrapping up his view of the old era, Jono focused on Wikipedia. Wikipedia challenged a lot of the things that the open source community has learned, since the nature of knowledge is quite a bit different than the nature of source code. Wikipedia had to invent a whole new set of community guidelines to allow everyone with some knowledge to contribute to Wikipedia. A sense of community is not limited to technical people — anyone with knowledge in a particular field can be part of Wikipedia.

As we move from the dark ages of community management to the renaissance era, we’re writing down stories and best practices. We’re working to create repeatable experiences to allow people to build communities and avoid some of the pitfalls that early adopters made. In the past 10 years we’ve seen a number of corporations enter the open source space, only to make a complete mess of their community from the start. And today we’re seeing a profession forming: At the recent Community Leadership Summit there were 200 people who work professionally in community management. This didn’t exist 10 years ago!

But hiring a community manager remains really hard — there are many people who claim to know how to do it, but few can actually live up to their promises. Jono set out 5 tips for what to look for in a community manager and how community managers should do their job:

  1. Hire carefully: When hiring a community manager look for prior experience. See if the person can show that they’ve managed to grow their community over time. And even that is hard; how do you measure this? Number of blog posts or twitter updates? Number of people involved in the project? Then, when you’ve hired a community manager, don’t send the manager traveling all the time. Time spent on the road is valuable for meeting with people in the community, but time on the road equates to not managing the community. Also, be careful where to place the community manager in your company. Community managers thrive when they have close contact to the engineering team that is creating the products. Keep community managers away from the marketing team, since they are two very different beasts!
  2. Build trust: Trust is a two was street between the community and management. A community manager needs to be part of the community and build trust downward to the community. At the same time a community manager needs to manage upward and educate management about communities and how to interact with them. For instance, marketing people will want to send out product updates to the community, which the community may see as spamming. Its up to the community manager to ensure that the company treats its community members with respect. Building trust is hard and takes a long time, but its possible to waste a ton of trust with one simple mis-step.
  3. Governance: When a community grows beyond a few people you need to develop a plan for governance in the community. If you have a 100 people, you’ll need a plan for moving the community forward and how to resolve disputes. Governance defines how projects move forward and its important to have a clear structure so that everyone can understand how the project works. Finally, governance boards need to consist of staffers as well as community members. In the case of Ubuntu there are many more community members on the governance boards than there are staffers.
  4. Build the on-ramp: Community managers need to identify the means to get new people to join the projects and how new people can develop knowledge about the project. Then community managers need to determine what contributions people make to the project (remember, there are many more ways to contribute to an open source project than code!) and finally the glory of growth and success needs to be shared with the members of the community.
  5. Keep score: Keep track of community managers are doing and measure their progress. If you’re not keeping score, it simply doesn’t count! A community manager needs to set out goals for a given time-span and then work to stay on that track. Community managers that do not have an actual plan are not likely to succeed in their goals for the community.

Working with communities is not an exact science and I’ve been following community oriented presentations at OSCON for a number of years now. At first we heard a lot of horror stories about what didn’t work, but we didn’t have many suggestions for what we could do and how companies and communities could work together. I’m really glad that this is slowly changing and that we are now developing a body of knowledge that should allow open source projects to manage their communities better. I agree with Jono that we’re seeing signs that community managers are coming of age and that we’re about to enter a new era of community management. I’m still learning a lot and I deeply appreciate people like Jono who are paving the way and sharing their knowledge with us. Thanks Jono!


Two goodies from the past

I’ve really enjoyed attending Ben Collins-Sussman and Brian “Fitz” Fitzpatrick’s sessions on  social issues in open source. Now that they’ve written the awesome “Team Geek" book that captures this series of talks and more, I wanted to highlight a couple posts again:

  1. Programmer Insecurity and the Genius Myth
  2. Do you believe in the users?

I’m looking forward to the latest installment this year!


Past OSCON posts

In the past I’ve blogged OSCON and ETech for O’Reilly and those posts used to show up in the O’Reilly blogs and on the O’Reilly Radar — there are quite a few good posts in there!

If you’re interested in reading older posts on OSCON and ETech, please read my O’Reilly Blog/Radar posts and my old O’Reilly Blog posts.


Welcome to Awesome OSCON!

I’ve been blogging conferences for O’Reilly since 2001 and in that time blogging for O’Reilly has taken many forms. In the past few years I posted my blog entries to the O’Reilly Radar, but that blog has now taken a more forward looking tone and my blog entries no longer fit there.

In an effort to find a more permanent home for my OSCON blogging, I’ve created this blog. You can expect to find very little activity here, except for when OSCON is happening — like this week. This week I hope to blog quite a bit and give you a taste for why OSCON is so awesome!

I have a few blog entries that I wrote for last year’s OSCON, but those were never posted, so I am going to catch up on those and post those very soon. I’ll also post some links to where my blog posts from previous years can be found.

I hope you enjoy reading my posts on OSCON!