![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
|
Hello!
It's been a while since I last posted here. There's a lot of reasons for this - partially it's my usual thing where I don't post for ages, but it's increasingly getting to the point where I simply don't want to use DW any more.
This post got long, so I'm cutting it to save on your reading pages. Suffice it to say, though, I'm pretty disillusioned with Dreamwidth nowadays.
I used to support Dreamwidth. In some ways I still do. But recent changes have convinced me that the things that Dreamwidth used to believe in and consider core to Dreamwidth's philosophy are no longer important to its staff.
Some background: I used to be the maintainer of the Dreamhacks project. I was removed from this role after refusing to make the transition from IRC to Discord, during an experimental phase where they were testing it out. (It is now official.)
I had many reasons for this, but this is not the place to go into them as I actually agree with the removal and my intent with this post isn't to argue this. If I'm not at the main location where Dreamwidth development is occurring, then I am not suited to be the head of a core part of the Dreamwidth development process where being able to keep up with development is key. This I accept and understand.
However, the Dreamwidth code no longer works properly for non-Dreamwidth.org users, including the Dreamhack machine, because the current version of the code requires that people use Amazon Simple Queue Service, meaning that, at minimum, you need an AWS account with Amazon. This is yet another barrier to entry to getting started with the DW codebase, on top of the barriers that have been added by the changes to the Dreamwidth codebase which are incompatible with the Dreamhack user setup process. (The Dreamhack user setup process could be *made* compatible, but Dreamwidth staff have not seen fit to do this.) Don't like Amazon, or don't want to be beholden to a black box system that falls entirely out of your control? Tough luck.
On top of that, even if someone looking to set up a Dreamwidth installation has an SQS account, there is no sample configuration in the config files for how to set up SQS. The code looks for an %LJ::SQS hash, but this configuration is nowhere to be found in the code. In order to even set up SQS, you first need to work out what sort of configuration the code is expecting and hope that you got it right.
And on top of that, you can't even start the DW code easily on the Dreamhack machine right now, because the UUID::Tiny Perl module is not installed globally. You would need to install it locally and modify your Apache config to add it to your PERL5LIB environment variable.
These last two problems would be extremely simple fixes for Dreamwidth staff to make, and they would at least show that maybe they actually care about having volunteer development or external DW-based sites any more, even if the problem of needing an SQS account would still remain. However, it's been over two months now since the first Dreamhack-breaking change was introduced. This is the commit that introduced the requirement for UUID::Tiny, and since this commit it has been impossible to run DW on the Dreamhack server without installing this module locally, as nobody has seen fit to install it globally.
(For those Dreamhack users who wish to at least have a semi-functioning Dreamhack by installing the module locally, what you need to do is to run the command cpanm UUID::Tiny at the command line (ignore the messages about not being able to write to a directory), and then edit your $LJHOME/apache/httpd.conf file to include this line, replacing my home directory with yours:
PerlSetEnv PERL5LIB /dreamhack/home/8080-sophie/perl5/lib/perl5Note that doing this will prevent global updates to the UUID::Tiny module from taking effect as it will use your own local version. Note also that while this will allow some code to run, any code that relies on SQS code, such as sending emails, will fail unless you have configured a valid SQS account. How do you do that? Who knows, ask Mark.)
(Oh, and while you're at it, you may also want to make sure you've got a valid
config.pl file, because the files were renamed recently and so you have to copy the $LJHOME/etc/config.pl.example file to $LJHOME/ext/local/etc/config.pl if you don't want to get errors. "But wait," you say. "Isn't this what config-local.pl was supposed to be about, by overriding only the changes to the global config file which would be kept up to date?" Yes, yes, it was. Why was this change made? Who knows, ask Mark.)(If you're on the Dreamhack server, you may also want to make sure that your
$LJHOME/ext/local/etc/config-local.pl file has $PROTOCOL = "http"; in it, otherwise it won't work properly on the Dreamhack server. I will take part of the blame for this one because while I was the Dreamhack server admin, I never set it up to support HTTPS. That said, it should still be something that's at least covered by the new user setup process, and it isn't; the change that necessitated this occurred after I was removed from being an admin.)It hurts me that Dreamwidth is no longer sticking to its philosophy of being open and welcoming to new developers. Instead, it's concentrating solely on making sure the code works in production, even if it doesn't work anywhere else. It's not like Dreamwidth are unaware that it doesn't work on the Dreamhack box, either - there's been an issue filed on DW's issue tracker for nearly three weeks now, with no response. Not publicly, at least. (It's possible that there may be a response on the Discord, but as previously stated I'm not part of that.)
I'm not going to pretend I know everything that's going on behind the scenes. I don't. Maybe there are some valid reasons for things to be this way, somehow... but I'm quite honestly having trouble thinking of any.
I'm also not going to pretend that things were perfect while I was the Dreamhack admin. There were many things I didn't do which I could have done to make life easier for devs. (The HTTPS thing mentioned above is a good example, but there were others too.) Being the Dreamhack admin and keeping up with the responsibilities can be hard, and I'll be the first to admit that. It also needed communication with the devs and helping them out, and I suspect that this is where the vast majority of Mark's time is actually being spent.
However, the fact that the Dreamhack server is no longer treated as being core to the development process makes development for Dreamwidth very inaccessible.
I would welcome comment from any developers who are currently developing for Dreamwidth, as well as Dreamwidth staff. (And of course you can comment even if you're neither of those! I just wanted to say that I'm particularly interested in responses from these groups.)