[sldev] Speed of adopting open practices (Re: IJIRA and PJIRA)

[Rob Lanphier]

On 7/11/08 9:22 AM, Matthew Dowd wrote:
> To be honest, it isn't uncommon in the early stages of a closed source 
> project moving to an open source development model for it to have an 
> uncomfortable amalgam of close and open source development models. The 
> frustration from many of the contributors outside of LL, is that the 
> SL Viewer project has seemed stuck in this amalgam for over a year 
> with little signs of progress (or motivation) of moving out.

I'm largely to blame for that.  Those of us administering our public 
JIRA instance have had a tough time making sure it's 
stable/fast/functional enough to actually migrate to it for production 
use.  Thankfully (er, hopefully) the days of nasty PJIRA instability 
issues are behind us, so that habitual excuse is dissipating.  Not to 
mention that we're gradually shifting responsibility for PJIRA work to 
people better at that kind of thing than I am.

Brian Aker of MySQL fame pointed out in a blog discussion [1] with 
Theodore Ts'o of Linux kernel development fame that there's not really a 
successful blueprint for taking projects open source.  It's something 
we'll be discussing more at OSCON on a panel titled "Does Open Source 
Need to Be "Organic"?"[2] where "organic" is (arguably) defined as a 
project which the first release included source, and is generally 
characterized as by a distributed development team with no single 
company truly in control, and "inorganic" is generally code that started 
off life as a proprietary effort.

I realize that this makes participating in "organic" open source 
projects is often more appealing, since they generally start from day 
one with public tools for everything.  It's much more comfortable as a 
community member to at least have the full visibility of a peer from the 
first day you take an interest in a project, even if you probably won't 
be treated as one until you really prove your mettle.  There are many 
companies-driven open source projects that drag their feet at getting 
that level of transparency, and we're no exception, so many people in 
the community get rightfully get frustrated, because they imagine how 
much more they could potentially help with a peer's level access to the 
tools and information.  They are probably correct in thinking that 
companies that don't do it as quickly as possible are squandering a big 
opportunity, and get tired of trying to hit companies upside the head 
with the cluebat.  They retreat back to the organic alternatives, 
because, well, they just aren't getting paid enough for that....stuff.

My take on this is that ushering companies into the open source 
development model is a hard but extremely worthwhile problem to solve.  
This is why I took this job.  I'm not going to argue that I've done the 
best job at this (in fact, I know I've made several textbook errors), or 
that Linden Lab has been without fault.  However, I think that throwing 
the doors open on all aspects of a project and working in a highly 
disruptive way to existing development process is not smart to recommend 
across the board.  For a company that's on its last legs and is failing 
by every objective measure, sure, but not for a company that is still 
very healthy. 

I say this as someone who really, really wants Linden Lab to adopt many 
more development practices of "organic" open source, and trust me, I'm 
working very hard to demonstrate the value of this approach to my peers 
and to make the argument that we need to get more aggressive.  But at 
the end of the day, we are bound by hard business realities, which means 
that we can't pursue every single opportunity and fix every problem 
simultaneously.  As imperfect as our open source efforts are, we've got 
a lot of other big opportunities to pursue and big problems to fix, and 
the opportunities/solutions related to our open source initiative aren't 
always going to make it above the cut line for every planning cycle.

I don't think we're in a unique situation here.  It's really difficult 
when you have to untangle processes and habits that have formed over 
years.  Regardless of whether or not those are the best practices, they 
are the current practices, and the difficulty of process change is often 
underestimated by those with the best of intentions.  Compound that with 
the fact that the open source culture is a very email-centric (or at 
least "text-centric") culture, and how well that works for actually 
gaging goodwill [3], and you have a situation where too many people 
probably draw their cluebats too soon.

Back on the topic at hand.  I forwarded Mike's mail to our internal 
all-dev list (with a glib "yeah, what's up with that...." added in) and 
got the conversation rolling again.  There's a lot of hard problems to 
solve in our public JIRA instance work for more than we're using it for 
today, and those are being surfaced again in our internal dust cloud, 
but we're not ignoring your feedback.  For those of you who would just 
as soon we have that debate out here, sorry, some of the arguments are 
going to be for internal consumption only....it's just the nature of the 
beast.  I share your frustration that we're not yet better at keeping 
our public tracker up-to-date, and agree that the ultimate solution is 
to start using PJIRA sooner than later, but the better arguments against 
aggressive action (mainly centered around picking our battles) are 
arguments I'm not going to be at liberty to ignore, but I'll be pushing 
to make the case as best I can.

That work?

Rob


Links:
[1] Theodore Ts'o: Organic vs. Non-organic Open Source
http://thunk.org/tytso/blog/2008/04/24/organic-vs-non-organic-open-source/
[2] OSCON Panel: "Does Open Source Need to Be "Organic"?"
http://en.oreilly.com/oscon2008/public/schedule/detail/4400
[3] xkcd: "Internet Argument"
http://xkcd.com/438/