Why Shared Code Ownership Has to be Real

 As of today, I've decided that I'm basically done with the build.  Not because it lives up to the piece of software that I intended to write.  Not because it has all the functionality that we need.  But because I've had it with doing behind the scenes work where all I hear is other peoples' opinions on how things should be done and NO ONE HAS PAIRED WITH ME ON EVER.  Period.  Exclamation point.  The build isn't a priority.  I mean, having the things that the build does is, but building software isn't sexy so why should we do it.  Everyone has different reasons why they hate what the build does and how to make it better.  But outside of Ian, I don't think anyone has made any patches to topp.build.lib.   I have tried to explain how to use the software the way I use it, but everyone wants it to work their way. 

 
Not to pick on Ian, but his blog post sums it up the best: 

""" 

Still spending time with virtualenv and the build, helping out with problems that come up.  I wish I could feel confident that the build stuff could be truly "done", but I don't feel confident about that at all.  This is very disappointing to me, really; it's not something I want to spend time on -- personally or as an organization.  I want us just to figure out how to do it, and then we can all move on to other stuff.  I'd like us to push more of the complexity out of the builds and into the products themselves.  I think the WordPress build is okay this way -- the Apache configuration is just a tiny bit tricky (because of LoadModule), but there's nothing we can do about that.  All the rest of the complexity has been put into openplans_hooks.py and the WordPress code directly.  TaskTracker still has some database setup problems in the build.  OpenCore is... more complex.  I find we're rebuilding from scratch each time because we don't completely trust rebuilding in place.  What does BuildIt really give us then?  It's not auditing tools.  It's not easy configuration (pfft, quite the opposite).  I don't want to open this stuff up all again, because as I said I really want us to be DONE with building crap.  But I don't know... putting up with problems because you want to be finished with something, while you don't actually have a clear vision of what it will take to be finished given the path you are on, is that a good strategy?  Setuptools' quirks don't help either.  Local mirrors of everything we use would also be quite handy.

""" 

 It is very unsatisfying to work with the builds at this point in time.  Since there is so much to do and our target keeps moving, this is likely to continue much into the future.  So maybe the build doesn't give us much.

 In any case, I'm done with it.  I'll work on the full stack build and the virtualenv integration branch, and then I will do my usual strategy:  having said my piece (usually many many times) on the various things that need to/should/can be done with the build and how to do them, I will shut my mouth until someone else says the train will hit the wall.  Its really a stupid strategy for us working as a group.  But for me as an individual it makes much sense.  Because in essence, much against my will, the build has become "mine" to the point that if anything goes wrong or there are any deficiencies, its "my fault" and i'm the only one that can fix it.

 Which brings me to my larger point.  We have to do more than pay lip service to this shared code ownership.  In some projects (e.g. opencore) we've been good about this.  Sure, we still ask our resident experts (Ra, Whit, now Paul) questions on how to do something in zope when we can't figure it out.  But if something needs to be done for our assigned task, we generally go into the software and make it happen.

 So why didn't this happen with the build?

I'm not sure, but this did happen to me here before, with trac.  It was my job to WRITE THE BUILD for trac, which required a certain amount of knowledge about trac and its configuration.  I made it very clear at the time (or at least did my best trying to do so) that  I wasn't going to be in charge of maintaining 3rd party software.  It was not long ago -- 6 months after I installed trac on flow -- that David told me that I should install the trac private tickets plugin because i was the one that installed the software.  I don't know anything about this plugin.  There are no special skills to install the plugin.  As best I can tell, the only reason that people have asked me to install plugins for trac is because they were lazy, didn't want to read how they worked, and didn't want to take responsibility for them.  This is what really irritates me about the whole thing.  I agreed to install the plugin (now i wish i hadn't), installed it, and was done.  Its not configured correctly and doesn't do anything.  I just passed the buck because someone told me to do something that they shouldn't have done.  The only thing that is changed is that I got irritated and we put a plugin we didn't understand on the system because the installer (me) felt abused, whereas the people (David, Tim) that asked for the plugin didn't care enough to do the research on how to do it.  I offered to sit down with Tim and teach him how to install trac software -- I'm always more than glad to teach men to fish, even if it is time consuming in the short term, because it shows that they're responsible enough to really want it -- but he didn't want to devote the time.  Neither did I.

 If trac is a tool that is valuable to us, as individuals, then we should devote time to learning how to use it with some proportionality of its value to us.  Likewise the build.

I have been trying to be a "nice guy" here at openplans.  I think we should work together as a team to develop software.  But now, realizing again that I have to act selfishly, I am going to push back harder about doing any project where I am the sole coder.  I feel really bad about this, as I feel there should be a path of sharing responsibility for software.  But its not yet there.