[DGD] Where did all the players go?

[bart at wotf.org]

I think this is a good idea. 

One of the stumbling blocks for people starting with DGD is the amount of
effort and knowledge it takes to actually get started. Packaging it such that
people can deploy DGD and a mudlib in a 'ready to go' way, and such that the
basic installation and running environment will be similar or identical for
such users can help a lot with that.

While that was a different era, without the ease of pre-packaged containers,
creating a 'just download and run this' experience was one of the things I've
tried to create when I was maintaining Gurbalib. Its why it came with an
installer, included a version of DGD it was tested with, and in general tried
to just get someone running and focus on the mudlib and mud development.

As you mention, keeping the mudlib uptodate this way is more difficult because
of user changes to that lib. I tried to do a few things to reduce this issue:

- Make things 'pluggable', ie: Gurbalib's safun setup allowed for adding and
overriding afuns in a way that should not conflict with updates to the lib
(this is no longer the case in the current version)
- Strictly dividing the lib in a 'kernel', 'lib' and 'user' part. Only touch
the 'user' part (which included the safun dir)? You should be fine.
- Modified the 'lib' part? This should still be relatively easy, but requires
work for merging changes
- Modified the 'kernel' part? You are on your own.

This worked somewhat, but, people find enough reason to modify the lib part to
still make this a lot of work for both the maintainer of the core
distribution, and the users. Additionally, it also meant a fair bit of extra
work to ensure lib upgrades always worked, or in cases where that was not
possible, at least ensure they pointed at the proper way to upgrade (requiring
specific inbetween versions for migrating data).

At any rate, keeping a mudlib distribution uptodate and facilitating in-place
upgrades of muds using it is a pretty big challenge due to data conversion and
having to provide ways to upgrade user data, even when people do not modify
the core lib. 

Part of the issue here is this being a somewhat unusual approach for most
people. Understanding the in-place recompilation of code is already a bit of a
challenge, doing proper data conversion seems a bridge too far until people
gained significant experience with the system.

Another part however is the sheer complexity of supporting in-place upgrades
even when people skip inbetween versions, and making it work with the wide
variety of things people tend to do once they start using some piece of code.
This complexity easily gets in the way of making progress with the lib because
of possibly breaking things for others.

Regardless, a pre-packaged, 'download and run' distribution will imo remove
one of the major stumbling blocks, and seems like a really good idea.

But... be prepared to also provide some form of support to those users, else
it will not get very far. That means helping users dealing with the more
unusual aspects of DGD and their first steps in modifying things to their need.

Bart.

On Sun, 10 Dec 2017 22:48:03 +0100, Felix A. Croes wrote
> DGD's development has always depended on user feedback.  In its 
> heyday, 50% or more of bugreports and feature requests/suggestions 
> came from users, with the remainder coming from myself and from muds 
> that I was associated with.  Right now, that is less than 5%.
> 
> One obvious reason is that users tend pick a version of DGD that 
> works well enough for them, and then don't upgrade.  DGD is quite 
> stable in its core feature set, so these users provide almost no 
> feedback; more recent features are not picked up and go untested.
> 
> This could be solved by releasing DGD as a package, which is kept up-
> to-date along with the remainder of the system.  But I think most people
> want DGD + a mudlib, and a package manager is a poor match for a mud,
> especially a persistent mud.
> 
> For this reason, my thoughts are turning instead to a Docker container.
> The Docker image would provide a startup configuration for an "app",
> that being DGD plus a mudlib.  Inside the container, DGD would be
> kept up-to-date automatically without downtime using hotbooting.
> The same could be done for the mudlib, although this would be more
> tricky since local modifications would have to be handled somehow.
> 
> Forcing Docker containers onto existing users is obviously nog going
> to work, but I'm looking at using this setup for the AC server.
> 
> Regards,
> Felix Croes
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/