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

[Rob Lanphier]

On 7/11/08 3:15 PM, Mike Monkowski wrote:
> Rob, thanks for forwarding my question to the internal list.
>
> I wasn't asking out of frustration; I was asking out of curiosity.  It 
> seems like you're missing out on a major benefit of being open source, 
> and I can't guess what the reason might be.  You don't have to go full 
> PJIRA all at once.  Read-only IJIRA would be a big step forward, 
> though (and there'd be a lot of people keeping PJIRA up to date then).
Agreed.  It's both a big step forward, and really tough to figure out 
how to do correctly.  We have a lot of internal systems that are wired 
together for our internal toolchain that are tough to untangle.  For 
example, we're doing our reviews today, for which we have a tool which 
automatically pull statistics from our internal JIRA instance.  We've 
grown dependent on accessing the internals of that database.  For 
reasons that are long and complicated, we can't use the same mechanism 
for pulling from PJIRA.

That's just one example that I'm thinking of.  There are lots of 
others.  We intend to get PJIRA integrated into the overall system, but 
LLJIRA is more tangled into our internal workflow than you might think, 
and we really can't move the whole mess to one publicly accessible system.

> My curiosity was sparked by a project within my company that I am 
> participating in as an "outside user" even though I work for the same 
> company.  They call it a "community driven commercial development" 
> project.  See http://www.projectzero.org/about/zerofaq.php  The source 
> is available and the bug tracker is visible, and they accept 
> suggestions, but they do not accept code contributions, so it's not 
> really an open source project, but they do make it easy for people to 
> fix bugs.

That's very cool.  IBM has a pretty sophisticated approach to open 
source and hybrid models.

> I'm not suggesting Linden Lab adopt the same model; I'm just wondering 
> why Linden doesn't make the bug fixing more transparent.

Working on it.  Speaking of those reviews, I'm doing my quarterly review 
right now, and one of the things I'm kicking myself for not getting done 
was an LLJIRA->PJIRA exporter.  (And I'm probably going to abandon it 
myself in hopes that another group can take it on).

The naive approach on something like that is to take the importer and 
reverse it.  The problem is that our importer takes a "suck it in and 
fix it up" approach to importing, whereas an exporter should probably 
have a "preview" before going live.

None of this is rocket science, but it all takes time, just like writing 
this email takes time.  ;-)

Rob