<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Heya ...<br>
<br>
To give you all some context, here are two mails I've sent at the
beginning of January to my fellow team members and which have
started the discussion that lead us to set up the upcoming all-hands
meeting. These mails itself were inspired, amongst other things, by
some preceding ImpDev meetup discussions, the last one being the <a
href="http://wiki.kokuaviewer.org/wiki/ImpDev_Meetups/2012-01-04">one
on 2012-01-04</a>.<br>
<br>
On 01/05/2012 11:33 PM, Borun (a.k.a. Boroondas Gupte) wrote:
<blockquote cite="mid:4F06253E.60605@kokuaviewer.org" type="cite">
Heya fellow team members<br>
<br>
I think we have to get the discussion going on how to proceed (or
maybe not proceed) with our well-loved little project here. It
seems to me that development of our two viewers, Imprudence and
Kokua, has nearly ground to a halt.<br>
<br>
I'd like to hear everyone's opinion on the following points:<br>
<br>
<ul>
<li>Is the above impression correct, or did/does significant
development go on in areas where I didn't see it?</li>
<li>If so, what do you think are the reasons?</li>
<ul>
<li>Are these temporary or inveterate?</li>
</ul>
<li>Should we do something about this?</li>
<li>What <i>can</i> we do about this? (What are our options?)<br>
</li>
<li>What <i>should</i> we do? (Which option is best?)</li>
</ul>
<p><br>
I'll follow up with my opinions (where I already have some) in a
separate email.<br>
</p>
<p>Cheers,<br>
Borun<br>
</p>
</blockquote>
<br>
On 01/09/2012 12:21 AM, Borun (a.k.a. Boroondas Gupte) wrote:
<blockquote cite="mid:4F0A24FA.3030504@kokuaviewer.org" type="cite">
Hi again<br>
<br>
[First of all, sorry for the wall of text below.<br>
Second, although I do comment in the following on some of your
individual behaviors, I don't want to blame or even judge you.
These are meant as just observations, not critique.]<br>
<br>
On 01/05/2012 11:33 PM, Borun (a.k.a. Boroondas Gupte) wrote:<br>
<blockquote cite="mid:4F06253E.60605@kokuaviewer.org" type="cite">
<p>I'll follow up with my opinions (where I already have some)
in a separate email.<br>
</p>
</blockquote>
<br>
So here we go. To me, it seems like our development is stagnating.
And by that, I don't mean the break we took over the holidays.
This has started much earlier, I think. Didn't we want to have
another Kokua test build out by Thanksgiving? Now, I don't know
about you, but for me, the reason I haven't done much recently (or
ever) isn't that I've lost interest in this project. It's just
that my RL job (since August; before that, as you might remember,
the thesis I had to do to conclude my studies already kept me
busy) and the (few) free time activities I have besides viewer
development have left me with little time to work on the
viewer(s). The few times each week I'd <i>have</i> time, I'm
usually lacking the energy to do any coding. (Probably because I
develop software in my job, too. Fortunately, I don't feel a lack
of energy to do other stuff.)<br>
<br>
This would probably be OK, if the rest of the team was dragging
the project forward and I could contribute by doing code reviews
and maybe some little code changes here and there. But I don't see
that happening, especially not recently.<br>
<br>
But this shouldn't be about me. As has been noted in <a
moz-do-not-send="true"
href="http://wiki.kokuaviewer.org/wiki/ImpDev_Meetups/2012-01-04">this
week's meeting</a>, users won't wait forever for Kokua. Though,
if we continue as we currently do, I guess we won't have anything
to give them for quite a while.<br>
<br>
As some of you might still remember, Arrehn (the lead of the
Firestorm project and <a moz-do-not-send="true"
href="http://wiki.kokuaviewer.org/w/index.php?title=Special:Search&ns0=1&ns1230=1&ns1232=1&ns1234=1&redirs=1&search=%22arrehn+oberlander%22+%22ImpDev+Meetup%22&limit=50&offset=0">a
regular guest</a> at our ImpDev Meetups) would want us (the
Imprudence/Kokua team) to collaborate more closely with them or
even join them. (See <a moz-do-not-send="true"
href="http://lists.kokuaviewer.org/private.cgi/kokua-team-kokuaviewer.org/2011-July/000003.html">Jacek's
mail from July</a>.) Closer collaboration without joining might
improve things a bit (not re-inventing the wheel), but probably
not much. (Collaboration between teams also takes some time of its
own.) Joining their team (or altogether team) might be an
interesting option, as one of our problems might be that our team
is just too small to pull off developing and maintaining two
viewers in parallel. Arrehn's vision, if I've understood him
correctly (see e.g. the <a moz-do-not-send="true"
href="http://wiki.kokuaviewer.org/wiki/ImpDev_Meetups/2011-11-30">ImpDev
Meetup transcript from 2011-11-30</a>), is that the current
Kokua team (either as part of the Firestorm team or as an external
contributor) would work on making Firestorm more OpenSim-friendly
and maybe produce a "Kokua" UI mode for Firestorm.<br>
<br>
Another idea I once had (Jacek had a similar one, see the <a
moz-do-not-send="true"
href="http://wiki.kokuaviewer.org/wiki/ImpDev_Meetups/2011-06-16">transcript
from 2011-06-16</a>, [02:44 PM]) , was creating and maintaining
a repository for a viewer source base containing most (or all)
modifications that the majority of third party viewers use, but
that didn't (yet) get into LL's viewer-development. I think such a
repository would make collaboration between third party viewer
projects easier, especially if they all use it as a common
upstream and actively submit modifications that are of use for all
TPVs but that LL doesn't want for whatever reason, or doesn't
support/maintain (native 64bit binaries, anyone?). In the past,
I've thought about leaving the Kokua team for starting something
like this, though I would have needed some collaborators to pull
this off, I think. Now I'm thinking that it might be an option for
the current Kokua team to abolish to catering to end users
directly and instead help other third party viewers by enabling
them to easily share their common parts. I think such a project
wouldn't release application binaries of its own, but would have
to make sure that the maintained source is always buildable for
all supported platforms. It could also make it easier to create
new third party viewers by replacing currently hard-coded
project-specific stuff (names, URLs, colors) with build- or
run-time parameters.<br>
<br>
But enough of prose ... let me get back to the questions I asked.<br>
<br>
<blockquote type="cite">
<ul>
<li>Is the [...] impression [that development of our two
viewers has nearly ground to a halt] correct, or did/does
significant development go on in areas where I didn't see
it?</li>
</ul>
</blockquote>
Well, it's the impression <i>I</i> had, so for <i>me</i> this
question is moot. I'd like to hear your opinion about this,
though.<br>
<br>
<blockquote type="cite">
<ul>
<li>If so, what do you think are the reasons?</li>
</ul>
</blockquote>
Our team is too small and the members who contributed a lot have
either left (Jacek), are inactive (Elektra) or can't do as much as
they used to (McCabe and Armin). Others (like me and (I think)
revolution) never had much time to contribute in the first place
or aren't programmers (Codie and ZATZAi). Dunno about Sergio, who
is still rather new in this project. (Have I forgotten anyone? Our
<a moz-do-not-send="true"
href="http://wiki.kokuaviewer.org/wiki/Official:Team">team
member list</a> isn't up to date.)<br>
<br>
<blockquote type="cite">
<ul>
<ul>
<li>Are these temporary or inveterate?</li>
</ul>
</ul>
</blockquote>
Inveterate, I think: At least for me, there won't be much more
free time to use for viewer development except maybe during my
(short) vacations. I'd like to work less than full time at my RL
job, so I'd have more time and (coding) energy to spend on viewer
development, but at least for the next some years, this won't be
possible unless I change jobs, which I don't currently plan to do.
(I like my job.)<br>
<br>
<blockquote type="cite">
<ul>
<li>Should we do something about this?</li>
</ul>
</blockquote>
Yes. Off course, we could continue at the current pace, but that
almost certainly would make us lose significant amounts of users.
"People won't wait too long.", as Penny said at <a
moz-do-not-send="true"
href="http://wiki.kokuaviewer.org/wiki/ImpDev_Meetups/2012-01-04">this
week's meetup</a>. As getting improvements into the hands of
residents is what makes working on viewers fulfilling, this would
also affect the fun we have with this little hobby of ours, I
fear.<br>
<br>
<blockquote type="cite">
<ul>
<li>What <i>can</i> we do about this? (What are our options?)<br>
</li>
</ul>
</blockquote>
Some alternatives, in no particular order:<br>
<ul>
<li>Decrease the workload, so that we can get at least something
done. And done <i>well</i>, if possible.</li>
<ul>
<li>e.g., drop one of our two viewers, and focus solely on the
other one</li>
<li>and/or make our viewer(s) less different from upstream.</li>
<li>maybe change upstream from LL's viewer-development to the
source base of another TPV, which already has some of the
features we want. (Arrehn <a moz-do-not-send="true"
href="http://wiki.kokuaviewer.org/wiki/ImpDev_Meetups/2011-06-30">has
suggested</a> to base Kokua on Firestorm.)</li>
<li>try to reduce workload through better collaboration with
other teams/projects<br>
</li>
</ul>
<li>Attract more developers (be it new team members or just
contributors), so the workload for each becomes lower<br>
</li>
<li>Merge with another team or give up our viewers and join
another team</li>
<ul>
<li>Firestorm/Arrehn seems to want us</li>
<li>Maybe there are also other teams that would be interested?<br>
</li>
</ul>
<li>Be bolder about distributing binaries, even if we feel our
work is unfinished, so that users have something to play with
and can give experience-based feedback.<br>
</li>
<li>Give up the notion of having to release binaries and become
a source-only project.</li>
<ul>
<li>Maybe maintain a repo that other TPVs can use as their
common upstream</li>
</ul>
<li>Dissolve the Kokua/Imprudence project and team.</li>
<ul>
<li>Some team members might join other projects individually,
others might contribute to several viewers while yet others
might leave viewer development altogether or even start some
new project.</li>
</ul>
<li>Continue as we currently do, however slow the pace might be<br>
</li>
</ul>
<blockquote type="cite">
<ul>
<li>What <i>should</i> we do? (Which option is best?)</li>
</ul>
</blockquote>
This is a volunteer project, in which we participate for our own
enjoyment, so we should do what we <i>want</i>. Though, I'm not
really sure what <i>I</i> want, and much less what <i>you</i>,
the other team members, want. That's why I try to start this
discussion.<br>
<br>
However, I did think about some pros and contras of the options
above and have strong emotions about some alternatives:<br>
<ul>
<li>Dissolving the project and team would be sad, as I really
like you guys and enjoy working with you</li>
<li>Attracting more developers is something we already try.
Though I feel we weren't even really able to show the one new
developer in our team, yet, what we do here and how, exactly <i>because</i>
not much progress was made since he joined us.</li>
<ul>
<li>On a related note, we weren't able to handle the one big
contribution we got from non-team-members (the mesh port by
the two Nickys) in a timely manner. It's in now, I think,
but NickyP must have felt treated similarly as when
contributing to LL.</li>
<li>I'm unsure whether we could even handle more new
(developer) team members at all. <a moz-do-not-send="true"
href="http://en.wikipedia.org/wiki/Brooks%27s_law">Brook's
law</a> is probably still valid today.</li>
</ul>
<li>I'd prefer to merge with a team of similar size rather than
joining a bigger team. I don't know how many active developers
Firestorm actually has. (Arrehn once told us it might be less
than we might think; see <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://wiki.kokuaviewer.org/wiki/ImpDev_Meetups/2011-09-29">http://wiki.kokuaviewer.org/wiki/ImpDev_Meetups/2011-09-29</a>
from [01:45 PM] on.) But it certainly feels much bigger than
our team. And although I like those of their team members I
know close enough to have an opinion on them, <a
moz-do-not-send="true"
href="http://lists.kokuaviewer.org/private.cgi/kokua-team-kokuaviewer.org/2011-July/000004.html">my
concerns</a> that our project cultures might be too
different and that a joint effort would essentially become
Firestorm with some move devs, rather than something with also
Imprudent/Kokua-esk ideas in it, are still present. Though,
creating a "Kokua mode" within Firestorm might be interesting.</li>
<ul>
<li>To me, it'd be tempting to merge with the Singularity
team. Though:</li>
<ul>
<li>I don't know whether they'd be interested in such a
merger. (Maybe we should just ask them)</li>
<li>What would the resulting combined team do? Maintain 3
viewers? Probably not a good idea.</li>
</ul>
</ul>
<li>If we release binaries of unfinished stuff, we have to make
very clear that it is unfinished, unsupported and might eat
the user's homework. And their dog. And even if we have made
that clear, the amount of feedback might be too much for us to
handle at the moment.</li>
<ul>
<li>On the other hand, would the feedback become less at a
later binary release date? More changes would have
accumulated till then. (Some of them fixes of stuff we've
broken, but hopefully also new stuff which might be
feedback-worthy.)<br>
</li>
</ul>
<li>Switching upstream would probably not gain us much. We'd
just chase someone else's repo instead of LL's.</li>
<li>I'd anticipate better collaboration between TPV teams, but I
don't have too high hopes for that to help with our particular
problem.</li>
<li>Cutting back in our ambitions and making Kokua less
different from viewer-development than initially planned might
work. And now that upstream UI design has regained some
sanity, it might actually make sense.</li>
<li>A source-only TPV for end users probably doesn't make a lot
of sense. The fraction of residents compiling the viewer
themselves is rather low, and probably most within it are
either using gentoo or already are developers of another TPV
(or, some few, both).</li>
<li>A source-only project that maintains a repo with everything
common/undisputed between TPVs and maybe serve as a common
upstream might be more needed and useful. Though, this would
require a very close cooperation with other TPV teams and
would need us to merge in LL's changes on a very regular
schedule. Also, to not be perceived as competition but a
complement to other TPVs, we might need to drop the Kokua and
Imprudence names, brands and logos and go for a more <a
moz-do-not-send="true"
href="http://en.wikipedia.org/wiki/White-label_product">white-label</a>
approach. We also would have to be very open to their needs,
wishes and contributions.</li>
</ul>
<p>So now, it's your turn. Do you perceive a problem at all? If
so, how do you perceive the problem? What ideas do you have? You
don't have to write long texts like I did here, if you don't
feel like it. Short answers are fine, too!<br>
</p>
<p>I hope for some discussion to unfold on these topics ...<br>
</p>
<p>Borun<br>
</p>
</blockquote>
There were no other on-list replies, but the topic was picked up at
the <a
href="http://wiki.kokuaviewer.org/wiki/ImpDev_Meetups/2012-01-11">following
ImpDev meetup</a>.<br>
<br>
I hope this makes some things more clear,<br>
Borun<br>
</body>
</html>