[kokua-dev] All-Hands meeting about the future of the Imprudence / Kokua Team, Project and Viewers: The Prequel

Borun (a.k.a. Boroondas Gupte) borun at kokuaviewer.org
Tue Jan 24 13:26:56 PST 2012

Heya ...

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 one on
2012-01-04 <http://wiki.kokuaviewer.org/wiki/ImpDev_Meetups/2012-01-04>.

On 01/05/2012 11:33 PM, Borun (a.k.a. Boroondas Gupte) wrote:
> Heya fellow team members
> 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.
> I'd like to hear everyone's opinion on the following points:
>   * Is the above impression correct, or did/does significant
>     development go on in areas where I didn't see it?
>   * If so, what do you think are the reasons?
>       o Are these temporary or inveterate?
>   * Should we do something about this?
>   * What /can/ we do about this? (What are our options?)
>   * What /should/ we do? (Which option is best?)
> I'll follow up with my opinions (where I already have some) in a
> separate email.
> Cheers,
> Borun

On 01/09/2012 12:21 AM, Borun (a.k.a. Boroondas Gupte) wrote:
> Hi again
> [First of all, sorry for the wall of text below.
> 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.]
> On 01/05/2012 11:33 PM, Borun (a.k.a. Boroondas Gupte) wrote:
>> I'll follow up with my opinions (where I already have some) in a
>> separate email.
> 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 /have/ 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.)
> 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.
> But this shouldn't be about me. As has been noted in this week's
> meeting <http://wiki.kokuaviewer.org/wiki/ImpDev_Meetups/2012-01-04>,
> 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.
> As some of you might still remember, Arrehn (the lead of the Firestorm
> project and a regular guest
> <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>
> at our ImpDev Meetups) would want us (the Imprudence/Kokua team) to
> collaborate more closely with them or even join them. (See Jacek's
> mail from July
> <http://lists.kokuaviewer.org/private.cgi/kokua-team-kokuaviewer.org/2011-July/000003.html>.)
> 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 ImpDev Meetup
> transcript from 2011-11-30
> <http://wiki.kokuaviewer.org/wiki/ImpDev_Meetups/2011-11-30>), 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.
> Another idea I once had (Jacek had a similar one, see the transcript
> from 2011-06-16
> <http://wiki.kokuaviewer.org/wiki/ImpDev_Meetups/2011-06-16>, [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.
> But enough of prose ... let me get back to the questions I asked.
>>   * 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?
> Well, it's the impression /I/ had, so for /me/ this question is moot.
> I'd like to hear your opinion about this, though.
>>   * If so, what do you think are the reasons?
> 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 team
> member list <http://wiki.kokuaviewer.org/wiki/Official:Team> isn't up
> to date.)
>>       o Are these temporary or inveterate?
> 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.)
>>   * Should we do something about this?
> 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 this week's meetup
> <http://wiki.kokuaviewer.org/wiki/ImpDev_Meetups/2012-01-04>. 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.
>>   * What /can/ we do about this? (What are our options?)
> Some alternatives, in no particular order:
>   * Decrease the workload, so that we can get at least something done.
>     And done /well/, if possible.
>       o e.g., drop one of our two viewers, and focus solely on the
>         other one
>       o and/or make our viewer(s) less different from upstream.
>       o 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 has suggested
>         <http://wiki.kokuaviewer.org/wiki/ImpDev_Meetups/2011-06-30>
>         to base Kokua on Firestorm.)
>       o try to reduce workload through better collaboration with other
>         teams/projects
>   * Attract more developers (be it new team members or just
>     contributors), so the workload for each becomes lower
>   * Merge with another team or give up our viewers and join another team
>       o Firestorm/Arrehn seems to want us
>       o Maybe there are also other teams that would be interested?
>   * 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.
>   * Give up the notion of having to release binaries and become a
>     source-only project.
>       o Maybe maintain a repo that other TPVs can use as their common
>         upstream
>   * Dissolve the Kokua/Imprudence project and team.
>       o 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.
>   * Continue as we currently do, however slow the pace might be
>>   * What /should/ we do? (Which option is best?)
> This is a volunteer project, in which we participate for our own
> enjoyment, so we should do what we /want/. Though, I'm not really sure
> what /I/ want, and much less what /you/, the other team members, want.
> That's why I try to start this discussion.
> However, I did think about some pros and contras of the options above
> and have strong emotions about some alternatives:
>   * Dissolving the project and team would be sad, as I really like you
>     guys and enjoy working with you
>   * 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 /because/ not much
>     progress was made since he joined us.
>       o 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.
>       o I'm unsure whether we could even handle more new (developer)
>         team members at all. Brook's law
>         <http://en.wikipedia.org/wiki/Brooks%27s_law> is probably
>         still valid today.
>   * 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
>     http://wiki.kokuaviewer.org/wiki/ImpDev_Meetups/2011-09-29 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, my concerns
>     <http://lists.kokuaviewer.org/private.cgi/kokua-team-kokuaviewer.org/2011-July/000004.html>
>     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.
>       o To me, it'd be tempting to merge with the Singularity team.
>         Though:
>           + I don't know whether they'd be interested in such a
>             merger. (Maybe we should just ask them)
>           + What would the resulting combined team do? Maintain 3
>             viewers? Probably not a good idea.
>   * 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.
>       o 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.)
>   * Switching upstream would probably not gain us much. We'd just
>     chase someone else's repo instead of LL's.
>   * I'd anticipate better collaboration between TPV teams, but I don't
>     have too high hopes for that to help with our particular problem.
>   * 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.
>   * 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).
>   * 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 white-label
>     <http://en.wikipedia.org/wiki/White-label_product> approach. We
>     also would have to be very open to their needs, wishes and
>     contributions.
> 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!
> I hope for some discussion to unfold on these topics ...
> Borun
There were no other on-list replies, but the topic was picked up at the
following ImpDev meetup

I hope this makes some things more clear,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kokuaviewer.org/pipermail/kokua-dev-kokuaviewer.org/attachments/20120124/af16fe5f/attachment-0002.htm>

More information about the kokua-dev mailing list