It’s October again, and that means Open Source folks are meeting at Google in Mountain View, CA.  Last year I had such an enlightening experience that I wanted to do my best to make it even better.  One thing that Ihave realized is that it is hard to participate in a conference without some free time.  Your brain functions better if you arrive, settle in, get your bearings, and then start the real work.

On Thursday I arrived in San Fran, and immediately sprinted to the coast.  I live 1000+ miles from the ocean, and although I see myself as a mountain person, there is something compelling about swimming in the cold surf, emerging with a layer of brine.  After a few hours of work in a coffee shop overlooking the sea, I headed into the interior to meet with my TurboGears pals and get the conference started.

Friday Jorge and I toured San Francisco.  We decided to rent some bikes an ride across the Golden Gate Bridge.  I like this kind of self-guided tour, and we definitely got lost but had a good time in the process.  We arrived in Sausalito after crossing the bridge, and grabbed a bit to eat before taking the ferry home.   Later on we met up with Mark and the rest of the Google Summer of Code folks for some socializing.

Friday night we finally hashed out the json/return type challenges with TG.  Sticking with 2.0 implementation, you may only return a dict from your controller method if you expect the normal TG rendering to occur.  However, if you return an iterable object, the Pylons machinery will take over and stream your content.  This represents a problem because if you return a list and set the exposed renderer to json, it will return your dict in string form.  To protect the developer from making the mistake of creating a CRSF attack, this behavior will now raise a meaningful exception.  Having Mark and Jorge around to make this decision definitely sped up the implementation.

Saturday we arrived bright and early at Google and got started with the conference.  The mentor summit is a self-organizing conference, which means the talks are determined on the spot rather than pre-planned.  More and more I am finding myself drawn to these types of meetings.  They provide a much more interactive approach to conferencing as apposed to the eyes forward norm.

The best session I attended was Recruiting and Retaining Awesome People I had proposed a sprint-related session, and decided it would be best to merge with Donnie Berkholz since his session was similar in scope.  After all, sprinting is just one concept in the scope of recruitment.   We had a large number of attendees, and had to re-arrange the eye’s forward setup the room had because it did not allow for the discussion we both wanted to generate.

There was excellent discussion, and I took a few new ideas away from this session.  To highlight a few:

Toxic People – Placing a label on a person as toxic can be dangerous both to the people involved in the labeling, and to the community at large.  If you can isolate the toxic behavior and catalyze a new response from the person, someone who is viewed as toxic may then become a valuable contributor to your project.  Don’t be quick to label a person unless they simply do not respond to requests for changing of toxic behavior.

Code Review – Providing prompt and complete code review is a reward for the contributors work.  I think this is especially true in OSS where we write our code in a public domain, and are therefore expecting that others will look at our work.  The work in OSS is more than just the final product, it’s the code itself.  By providing feedback on a patch, pull request, or documentation augmentation, you are growing a potential long term contributor, even if your review is critical.  Reviewing code allows you to set expectations for your code project so you can further mold the codebase to meet your organization’s needs.

Socializing – The modus operandi for most technical IRC channels is to focus closely on the topic.  This keeps the signal to noise ratio high, but makes the room feel stale.  By interacting with your users in a more personable manner, it’s easier to build the interpersonal relationships that are required for contribution longevity in a project.

Thanks to Toshio for taking such detailed notes for this session.

For some reason I was having a hard time being motivated by the sessions.  It seemed odd to me that there were only 1/2 of the session rooms booked at any one time on Saturday.  I discussed this with Jim Baker, one of my Python colleagues in Boulder, CO.  He responded by providing a “How to write a Python Interpreter” session that was remarkably well attended.  The group was a mix of Python users, developers, and those interested in interpreters in general.  One of the session members was a major contributor to PyPy.  It seems obvious to me that python is going to move to the next level soon in terms of performance.  One of the things discussed was the usage of language constructs to provide the interpreter information about a class, method, module, in order to constrain execution and therefore provide faster execution.  Consider the use of __slots__ in Python classes.  If you know there are only certain attributes in a class, you have additional information that can be used by the interpreter to limit frame size, etc.  This is great for memory limiting techniques.  Now, apply this idea to performance techniques, and you can see that there are many opportunities to give the Python interpreter hints about execution that would allow it to do less work and therefore increase speed.

When I wasn’t participating in sessions, I was doing my best to share experiences, theories, etc. in the hallway track with other attendees.  I was also working on the TurboGears 2.1a2 release.  It’s funny, because our release process is more manual than I like, and therefore takes a few hours to complete, but if you split it up 10 minutes here, 30 minutes there, you can get a remarkable amount done even in the midst of something else major going on.  I’m not sure if this time usage technique has any merit, but I have used it at previous conferences.  It feels very easy to capitalize on the energy from the conference and get some work done, I’m not exactly sure why yet, but I’ll have to think about it some more.  In any event, 2.1a2 is released and ready for testing/consumption.  I think we are going to have 1 more alpha before we lock down the api.  Mark wants to change lookup to _lookup, so we have to add that and deprecate, deprecate, deprecate.

Sunday was more of the same in terms of sessions, but the attendees seemed to step it up and provide some interesting topics.  My favorite talk of the day was one regarding turning open source into a sustainable profession.  A number of topics were discussed, but this general forum lead us to group open source financial success into three categories:

Software Product Licensing – Turn your OSS project into something that is salable, either by providing a pay-for layer on top, or licensing it in such a way that corporations are responsible to pay for what they use, still allowing the OSS developers to have their way without incurring the costs.

Sell Your Organization – If your organization can offer value to an industry, it is very likely that an industry leader will want to purchase the rights to that intellectual property wholesale.  MySQL is the example of this that stands out in my mind the most.

Software as a Service – Consulting is one of the main ways developers can benefit financially from their work in the open domain.

I actually would like to explore a few of these in depth, and I think the next open-space conference I attend I will try and set up a session about at least Software as a Service to explore ideas about how to give away your software and thrive simultaneously.

Google continues to provide a valuable service to the community with the Google Summer of Code program.  I am convinced their motives for running such a program are noble.  One of the sessions I participated in was the Google Highly Open Participation (GHOP) session, and basically it was just an informative session for me.  I wanted to know more about the program, and the result is that TurboGears will likely work with the PSF in the future to participate in this program.

One of the reasons I get a lot out of conference like the Mentor Sum is that there isa large variety of technologies in attendance.  This moves me out of my normally Python-centric interactions with other developers.  While I think that Python is the best way to express myself as a developer, it is also interesting to see how other developers solve similar problems in their own domain.