The TurboGears team is proud to present TurboGears 2.1.  2.1 has been in development for about one year with the first alpha released in October of 2009.  If you haven’t been following along, here is a review of the changes that 2.1 brings from 2.0.

• Better performance.  The TG team worked hard profiling to see what could be done to make TG faster.  2.1 is at least 20% faster than 2.0 on page-loads as a result.
• Better Mako support.  (quickstart template now includes a –mako option) If you want a highly performant website, Mako is a better option than genshi.
• Kajiki support.  This template engine is for those who like the XML templating on Genshi, but need much better performance.
• Re-written dispatcher.  Object Dispatch has now become Abstract Dispatch, and the code that decides which controller method should be executed has been refactored and consolidated.  An open API is provided for those that want to create their own dispatch mechanisms by using the _dispatch method in your controllers.
• Pylons 1.0 support.  Those of you still running 0.9.7 can do so as well.  TG 2.1 is cross -compatible, which means if you have a 2.0 application, you needn’t upgrade to Pylons 1.0 until you decide to.
• Reduced dependencies. For those of you who use TG as a service, or do not need database or an admin, TG has reduced it’s dependencies to the low-20s.  The full stack with SQLAlchemy and an admin still has about 40 packages, but the packages which were most difficult to install have been removed (those requiring RuleDispatch in particular).
• Finally, documentation improvements.  The documentation has been visually overhauled, reorganized, and brought up to date.  There is still considerable work to do in this area, but a significant effort has been made to solidify those areas which are most often asked about by our users.

TurboGears is committed to maintaining the 2.x branch for the long-term.  This release is intended not to make significant strides in capability, rather to refine our existing functionality in order to add significant consistency to the codebase.  We have already started working on a 2.2 branch, which continues this effort, and will open up more APIs to the framework.  We look forward to your continued support!

The ultimate sprint incentive would be for companies to put up a bounty to fix bugs, or otherwise provide support for an open source project.  This is the toughest thing to sell I think, but if Google can do it, why can’t other organizations?  I have seen this attempted in the past with mixed results.  I think it was a half baked idea, and that we can do better than that.  The challenge is metrics, and making sure that everyone gets their fair share.  I mean, at that point, sprinting becomes payment for work done, the sprinters are just hired guns for a weekend.

I think the challenge has been, and will always be metrics.  How do you measure the work and who did it, and how much is each thing done worth?  I think the sprint organizer is the greatest asset in this situation.  He usually has the best idea about what needs to be done, what has been done, and ultimately who did what quantity/quality of work.  So you can use him as your metric definer.

My idea is this:  A sponsoring company provides the OSS organization with a certain amount of money, and what they would like to see achieved in an organized sprint.  This money is given to the organization as a donation regardless of the outcome of the sprint.  The donation may also be given to the organization with no stipulation of task, but the sprint organizer must choose a topic of interest in order to guide the sprint.

The sprinters all agree to a set method for dissemination of funding provided by the sponsoring organization.  My suggestion would be to split all of the funding equally, but in a capitalist nation, it is hard to justify giving the same funding for a person who did a little work on a piece of documentation vs. someone who spent 40 hours putting together a full tutorial.  Another method would be to allow the sprint organizer to disseminate the funding as he sees fit, but the sprinters would have to agree to this before work is started.  The work would have to be completed by a certain deadline to obtain the funding, because project organizers do not have time to track down who did what 4 months after the fact, it’s just not practical.  Finishing a week after a weekend sprint seems reasonable to me.

I am sure to see lots of comments about these ideas because when money gets involved, everyone gets uppity. (one of the great ideas behind OSS is that there is no money paid for the actual software)

So, there exists possibilities for setting up a sort of Round-up style sprint.  The goal is to provide sprinters incentive for providing bug fixes, or even to document a part of the code that is otherwise hard to get anyone to document.  I would love to open a discussion about this topic, as I see it as a completely different business model when it comes to software development.

But you have to ask yourself, “What’s in it for the company?”  Well, first I think you have to ask yourself why Google has been running programs where they pay for OSS development, no questions asked, for 5 years now.  But here are some insights while you ponder that.  The easiest reason to understand is that the sponsoring company has some bugs in OSS software they use that they need fixed, and a team of experts can fix them in a weekend, or their staff can submit bug fixes, go through the rigamarole of OSS contribution, and things get done in months.

The next less obvious reason for a company to provide funding for a sprint is that they are using OSS software that could use a little help in the documentation department.  By paying for documentation, they are getting a cut-rate deal on the experts that usually created the software providing documentation for those things that may be crucial to their business’s success.  This also reduces their dependency on any one employee who may have in-depth knowledge on a particular software package.  By ensuring the OSS software that the company uses is well documented, the company ensures that the intellectual know-how for that piece of software remains with the project, not with the employee that may leave at some later date.

The last simple reason I can think for a company to sponsor OSS is for recruiting reasons.  Typically the people involved in the sprinting process are the ones that know the most about it.  It is also be a chance to evaluate an employees enthusiasm for work in general.  Those who are sprinters are more likely to work well with others and stay with projects for the long haul, in my experience.

If software development is described as herding cats, gathering and directing sprinters is like herding stray cats.  I once had a stray cat visit me when I was in my potato-tuna days, and I gave it some of my tuna, because it looked in worse shape than was I.  And you know what, that cat always returned for the tuna.  Now, I’m not much of a cat person (current cat count: zero) but I think that if software developers are truly analogous to cats, they might show up at your door once, but it’s much easier to get them to come and visit regularly if you give them some tuna once in a while.

How does one entice people to thrive by sitting and writing documentation?  Rather, how do you reach out to a greater audience of developers that you could enlist for the betterment of your project?  The classic model has been, organize a theme, have the “elders” show up, and get some work done.  This sort of works.

The problem with this model is that I find a ton of people who basically show up to the sprint for a free tutorial.  You get them up and running with your source code, hoping they contribute something useful, and you spend an awful amount of time doing so, because they have some weird configuration or are in way over their heads, and by the time you get them set up, the sprint is over.  Now you just wasted your own time, and that of the project’s.  The only person that benefitted from that situation is the sprinter, who can use the information he gathered to thrive.

The only way I have personally been able to contribute a serious amount of work is to hide in a corner and code for hours alone while everyone else is “sprinting”.  Well, that sort of seems to negate the need for a sprint, since I can do that without the hands-on interaction that a sprint is supposed to encourage.  So, when no one showed up at the last sprint, I had a bitter sweet taste in my mouth, but I closed about 20 todo items.

The main benefit I have seen from a sprint is that it is typically a gathering for the “elders”.  The elders might talk about the future direction of a project.  In the best case scenario they write some test code to see if an experimental idea will work or not.  Sprinting is an incredibly valuable time for this, but often times the elders are held captive by (what we call in the climbing world) “gumbies” who capitalize on the elders’ knowledge of whatever project you are working on.  Often times I will see the elders hide in another room to have a discussion, much in the same way I have done to get code done.

One solution we have come up with to deal with this problem is to institute a “babysitter.”  This person is usually also the sprint organizer, and whether they know it

or not, their drive to have a successful sprint ties them to help the gumbies succeed, even if the chance of such an occurrence may be low.

I have played this role quite a few times, and while I am happy to answer questions at a sprint, I generally point people towards the docs and have them work through our examples.  If they find a problem with the tutorials, they have just found something they can sprint on and be successful!

The other major benefit we get from sprinting is that it is an awesome venue for starting new things.  Since the elders get together and sometimes create some test code, you are often left with a nice base to work off of.  Many times I find myself working the next 3 or 4 evenings after a sprint trying to finish things out.  This is often how new features are added to a project.

So, the question you have to ask when organizing a sprint is not only how to get people to show up, but how to get the “right” people to show up.  I think for this we need to change the way we think about sprinting, and come up with a new methodology for organizing sprints.

This is part two of a four part series on sprinting.   In the next segment, Sprint Organization: New Rules! I talk how we could improve sprinting using our current resources.

A few weeks ago the Front Range Pythoneers decided to organize an “Uncon” where people show up to discuss various topics on-the-spot.  This is the sort of event I really enjoy participating in, so I of course agreed to attend.  At the same time, I was approached by the guys from Developer Day to do a talk on TurboGears.  You can imagine the conundrum I faced, but thanks to the willingness of the DD organizers to be flexible, and some creative planning, I was able to participate in both.

Speaking at Developer Day was a new experience for me because I was talking to folks that were not necessarily versed in Python,never-mind TurboGears.  The conference appeared to be somewhat Rails heavy, but it was refreshing to see organizers reaching out to the greater web community to provide a well rounded conference.  The nice thing about speaking to a wider audience was that I was able to expound some of the history of the Python web, as well as describe TurboGears at a high level without worrying about boring the audience.  I was quite nervous speaking at first, because I have not done so in a few months, but seemed to settle into a groove by the time I showed an example of how easy it is to inject repoze.profile into a TG application and provide a cachegrind display to find any slowdowns in your app.  I hope that this example was able to express how versatile WSGI is.

I stayed the morning at DevDay and I am glad that I did.  Chad Fowler gave an address on what it means to remain passionate as a developer over the life of your career.  I think his idea that providing structure to your life definitely allows you to achieve amazing things.  His real-life examples were poignant and well received.  I’ll be checking out his book soon.  The other talk that I found interesting was Jeremy Hinegardner’s talk which basically discussed the numerous non-relational persistence methods available.  I thought his method for showing examples of the different methods was great. For each one he had a simple succinct example that showed the  benefits for the given persistence framework.  He allowed the audience to choose from the frameworks he discussed in his talk.  Jeremy was an engaging speaker, and I would not hesitate to sit in on one of his talks in the future.

After a bit of DD-provided BeauJos, I headed over to the UnCon.  They too were having pizza provided by Google.  Google Boulder was a great sized venue for the 40 people that attended.  It was exciting to see so many new faces in attendance.  It seemed to me that the “regulars” were doing a lot of demoing, while the new folks watched on, but there was also a lot of discussion that happened.  I showed how to use repoze.profile and runsnakerun to

analyze the results.   Zooko immediately installed runsnakerun and tried it on his app.  It is always nice to have immediate gratification for having taught someone something, even more so when the person voluntarily tries what you think is “so cool.”  I got to show off some of the work I am doing for www.getmvp.com, since much of it is prototypical of the Extension Solution that I hope to provide with a combination of Pylons and TG.  Also on display was TW2.  It was great to show how simply one could express all MVC elements of a widget in one complete package.

Sunday I ran the first TurboGears WorkShop.  If you follow my blog, you may have read a few posts about how I think we can improve sprinting, but I’ve come to the realization that our less-than-stellar sprint performance is really due to a need for improvement in the organization at large.  I have decided to add a WorkShop Series to our tireless effort for improvement of TurboGears, both from a technical aspect, and one of the community.  I was up late on Wednesday creating a basic tutorial-type plan for Sunday, and I finished up with about 80 pages of documentation to provide workshop goers, basically by selecting items from the TurboGears documentation.  My goal for the sprint was to provide sprinters with a working example of TG at the end of the day, with a little bit of work accomplished customizing the Admin.  I asked sprinters to bring their own databases, to utilize sqlautocode as an example database for their new application, and while no one provided the class with one, we were still able to succeed with one that I provided as a backup.  5/6 people succeeded in this, and while there were some rough edges, I think I have an idea that is workable for a 3-6 hour WorkShop that will succeed with a little bit of polish.

I am still formulating the ideas for TurboGears workshops.  I have started to contact folks I know throughout the country, in order to provide venues for these workshops.  So far I have Boston, Dallas, San Fancisco, Atlanta, and Boulder (Denver) lined up.  I think with little effort, I could also add Ann Arbor, and probably Washington D.C.  The idea behind a workshop is that you arrive with a varying amount of knowledge in TG, and you leave with a greater knowledge than you arrived with.  You are encouraged to bring an existing project to hack upon, or to create a new one that we can play with.  I will provide a rough outline of what we might do in the tutorial, but if the group decides to go off in a different direction, that’s okay too.  If you are interested in participating in one of these WorkShops as a mentor, or providing venue space, accommodations, etc. I would love to hear from you.  Right now I am in the organization phase, expect a blog post announcing the official plan in the near future.

Thanks!  Without the efforts of a number of individuals this weekend would have been much less successful than it actually was.  I want to thank Ben Scofield for inviting me to talk at developer day, and for shuffling the schedule so I could participate in both conferences.  Greg Holling put in a great effort to organize the Uncon, and Google provided an awesome venue for us to use.  Three volunteers from Google Boulder provided their time, and even gave a tour of the facility to conference goers.  They weren’t even Python developers…  Jim Baker and Matt Boersma both showed up to provide access to Bivio so that we could have our first-ever TG WorkShop.  Lastly, I’d like to thank Bruce Eckel for making the trip down from the mountains to provide his unique perspective.

I’ve been thinking out how we can come up with new methods to make our sprinting time more productive.  In the first two segments, I went over what our current thinking about how a sprint should run and what is expected of organizers and sprinters alike.  We see that sprinting is somehow broken, because people lack motivation to sprint,

except the folks that rise to the level of elders.

All is lost with sprinting however.  I think that there are a few things that

we can do to make sprinting more productive.  The challenge is that you can’t just make rules and expect sprinters to respond.  You can

’t say, “don’t show up without knowing what you are doing,” or we will lose valuable input from the community, since only elders will show up at that point.  So, the new rules are for organizers, and the elders, not the would-be sprinters.

Organizers need to start offering free tutorials for folks interested in the projects.  This accomplishes two things.  First, you give training to the people that are interested in your project without alienating them.  It would be easy to say “New Rule! You must have done the 20-minute-wiki tutorial to participate in the sprint.”  But this tactic does nothing to help the feeling that people have when they call something elitist.  While you might think it’s not elitist to have accomplished the 20-minute-wiki, someone else might struggle for hours with that task, especially if the documentation is not up to snuff.  These contributors still offer valuable insight, and you want them contributing to your project.

The second reason free tutorials will help your project is that it gives you an opportunity to increase the popularity of your project.  The more people that are interested in your way of doing things, the more potential sprinters you have.  At the end of the tutorial, you can collect emails or instant message handles, even phone numbers if that is what it takes to grow a list of perspective sprinters.  If you are willing to be generous with your time, maybe 1 out of 10 tutorial goers will be willing to return the favor.  The tutorial would also allow you to open up a method for communication.  Consider setting up an IRC (Internet Relay Chat) channel for your sprint, or using your project’s IRC channel to disseminate information about the sprint.  This will show folks on IRC that you are not only doing a a tutorial (maybe you will get some online participation) but it will show tutorial goers that the channel exists for further assistance.

The free tutorial is a great way to provide a service that costs nothing more than time for the organizer.  However, I don’t think this is the limit of what we can provide sprinters for their time.  What we need to do is provide some sort of incentive other than the good of human kind to sprinters.  The first thing is probably the easiest.  Start holding sprints on a friday, or any weekday for that matter.  This seems counterintuitive, right?  The fact is, most people don’t want to take a weekend day off because they are busy with other weekend stuff.  We all have families, clubs, interests outside of OSS software that we need to tend to.  Also, this provides a monetary benefit to the project without actually costing the project anything.  Many companies which use OSS software, and claim to support it will also be willing to let their employee take a day, or a 1/2 day to participate in a sprint.  The way you sell this idea is

to have the sprinters describe the hands-on and in-depth training they will be receiving in the care of the sprint.  This is no lie, the amount you can learn in an average sprinting day far exceeds the amount you receive on a regular basis.

Hold sprints in a unique location.  Lots of people like to ski.  For this reason zope/plone’s snow sprint is very popular.  I think the reason this sprint is made possible is that people need to take a break from the every day, and getting to a new an exciting place has merit, both from a coding perspective, and a mental aptitude one.  It so happens that I live in Colorado, which is one of the premier places in the US to ski.  If anyone is interested in organizing a sprint nearby, I urge them to speak up.  Also, I would be willing to provide a free tutorial on a weekday, so that hourly employees may be able to justify the cost of a trip to Colorado as an offset to the cost of free training.

It seems to me that the scope of a sprint is essential to it’s success.  If the sprint is just to code something, it is much less likely to succeed than if you are to sprint on something in particular.  Having everyone making a concerted effort on one topic makes it easier for organizers to coordinate folks, because organization can focus on one thing, and therefore tasks can be created ahead of time instead of doing so when everyone shows up.

Lastly, I think we need to reach out to the community of users, and find out if users of your project can support the OSS efforts of the tools they use.  I think that the next logical step is to provide sponsorship for sprints themselves.  Perhaps the sprint sponsor can provide a place to stay, or airfare to bring some of the sprinters together.  Even providing a venue for the sprint, or beer and pizza is something, but it is hard to expect people to show up and spend their time and also their own money to be co-located with a bunch of other sprinters.

This is part two of a four part series on sprinting:  The next [controversial] post is called Sprint Organization: But can we do more ?  This will talk about how we might convince third parties to participate in the concept of sprinting by asking them to donate monetarily.

Introduction

We are ready to start testing the next version of TurboGears: 2.1.  This release is the first of what will be a series of alpha and beta releases before we move into production.  2.1 is not a huge departure from the 2.0 codebase, rather, it’s efforts are to clean up and speed up the existing codebase, both conceptually and technically.  So, if you have some time, install it today and give it a whirl!

Major Differences (Things that affect present 2.0 users)

==================================================

Rendering

The item that will affect most 2.0 users is the renderer.  Json rendering is now not a special hard-coded case, so you will need to add it to your default config.  Most 2.0 apps will have to add the following line to their app_cfg.py if you are using @expose(‘json’) at all::

base_config.renderers.append(‘json’)

If you should forget to do this, you will get an error message reminding you to do so.

TurboJson

Support for TurboJson has been removed.  We have not found many people using this, and in fact, if you still need it, you can still put it into your TG application.  For the most part SimpleJson does a good job of rendering Json for us, and because it is a part of the python default library in 2.6, it makes sense to utilize it.  This allowed us to remove about 8 package dependencies.

Minor Differences (Things that affect folks familiar with how TG already works)

==================================================================

Dispatch

The dispatch mechanism has been completely refactored.  This means that pesky things like requiring *args at the end of a RestController.edit are now not required.  The new dispatcher is much faster, up to 200% faster for RestController dispatching.  It also has the flexibility to add a _dispatch() method to y