Grant Proposal: Revitalize blogs.perl.org

Category: Grants

Comments (17)


An improved blogs.perl.org that still runs on Perl seems like a good thing. Movable Type is proprietary and seems to be a bit of a dead end. This at least would be open.

That said, a custom one-off fork of an existing project seems a little risky too. If there's no hope of anyone else using this I worry that it just won't receive that much attention (in the form of patches).


The current blogs.perl.org team is all in favour of this project.


I vote for supporting this project.


"The current web host, MovableType has not addressed these issues, and placed the fate of blogs.perl.org in question."

Some slight confusion here that I should probably clear up.

Movable Type is not the current web host. The site is hosted on a dedicated server that Aaron and I rent for the purpose.

When we set the site up in 2009, Six Apart (the owners of MT) donated a professional MT licence and a lot of consultancy time to get the site running. We are grateful for these donations.

The current problems are caused by us being unable to upgrade our version of MT to newer versions - partly because there is no clear upgrade path from the professional version that we are using and partly because we don't know if the new owners of MT (a Japanese company who also bought the name Six Apart) would be in a position to honour our existing licence.

So whilst we do think that the best approach for blogs.perl.org is to move to a new platform (hence this grant proposal) none of the blame for this existing problems should be attributed to either the hosting company or Six Apart.


With regards to Dave's point about the license, I just got the following from Six Apart:

> We are happy to offer the latest version of Movable Type for blogs.perl.org
...
> On the OpenID Connect issue, we will support in the next version or later"

(Note: I am not in the position to say which direction is better and I don't have intention to influence the decision in one way or another. It's just for your information)


A better option may be to do a "call for proposals" so that various perl friendly hosting companies can solicit offers. A company may be interested in having their logo / banner placed strategically, especially if they are trading a common hosting plan for the privilege.

I dont know which software is best (MT, WebGui, others... bespoke?), but using perl seems like an obvious requirement. If an MT license has been purchased it also seems to make sense to find out if this license is still current.


A licence hasn't been purchased. A licence has been donated. And it sounds like Six Apart are happy to donate a similar licence for the latest version.


I don't know enough about the merits of PearlBee or Movable Type to comment on them, but as a non-voting TPF grant manager I'm impressed with the planning involved in this proposal. I would happily manage a grant like this.

Many people have frustrations with the current blogs.perl.org platform. I would like to see TPF support work to overcome these frustrations.


As the main author of the proposal, I apologize to MovableType and SixApart, and never meant to slight them. My discussion with the members of the blogs.perl.org maintenance crew were all focussed on "Where do we go from here?", not worrying about the existing maintenance issues. The existing bugs were never discussed, and I made some incorrect assumptions about why they hadn't been addressed based on other conversations.

PearlBee is a bog-standard Dancer application, so I expect that most of the development time will be shoehorning the existing MovableType data into the PearlBee schema and getting the layout to look how our UI designers want. Any code patches for blogs.perl.org will go back into the PearlBee mainline, and I'll also set about packaging it for CPAN so that it can go into wider dissemination within the community.

Evozon is offering hosting, design, development and maintenance time gratis to the Perl community, and in return we're offering to be as transparent as possible in our development efforts. My abject apologies again to MovableType and SixApart, what I said earlier was based on invalid assumptions.


Dave, we will donate a license of Movabel Type latest version with pleasure.

The current Six Apart is the former "Six Apart Japan" team. Now we own Movable Type and Six Apart treadmark (but no TypePad).


yes++


I really support this grant.
Reasons:
1) blogs.perl.org really needs some love.
2) PearlBee is a good blogging platform. I played with it a bit, it seems to be easily extensible. (Though I'm not at all aware of advantages of Movable Type over PearlBee).
3) This proposal looks very well-planned. Jeff and Amalia are smart & hard-working peeps. I'm very confident about them.

I'm really looking forward to use painless blogs.perl.org!


blogs.perl.org should be ported to Angerwhale.


I personally have no stake in what gets used to develop the site, PearlBee was simply chosen because that's what Evozon developed in-house; before I got involved, PearlBee's author was in upgrade discussions with the site admins. Looking at Angerwhale the last update was made roughly 6 years ago, and paradoxically Angerwhale-NG's last update was 7 years ago. I haven't looked into the code, but if it can be installed and has features that PearlBee is lacking we'll certainly consider it. While I imagine Amalia would want the final word on what actually gets used, I suspect she'd agree that if using Angerwhale saves time, we could use that.


I'm missing a few stages here. It's nowhere defined what feature-set the site needs. MT has lots of features that we don't use, and probably a few that we want that it doesn't have (ease of use being one of them, IMO).

Without that, one can hardly decide if this is a the best approach in theory, let alone in practice.

Also, simple blogs are generally considered easy to implement. I have the impression that, much like MT, Pearlbee was written with a very different feature set in mind and as such it's quite well possible that either writing a custom tool from scratch, or writing a more extensible tool is a better approach.

I may be talking out of my arse here, I'm not in the website-building business and have only briefly looked at the code.

I very much agree with the goal of having a better blogs.perl.org, but I don't think this plan of attack is making sense.


I should explain that I basically had four days to write and vet the proposal in between other work commitments, so you probably had more time to review the PearlBee code than I did. I'm sure PearlBee is missing features that we need to support from the old platform. Given how long b.p.org has been around I'm sure every feature it has *someone* is using. And getting a tick-list of features wasn't as much of a concern as getting a proposal out the door.

And I should point out that by the time I'd been asked to join the project, PearlBee had already been established as the codebase by everyone else. It's Dancer, designed in-house and had people willing to hack in new features for me as needs be. As I've said before I don't care what platform gets used as long as it gets the job done. Going to a Rails implementation might be going a bit far though :-) There probably are other alternatives out there but I was asked to write the proposal assuming PearlBee was the platform.

When writing the document I was focusing mostly on how to support existing users seamlessly and how best to migrate the old database. I'd had a few hours to look over PearlBee at most, before I had to start writing in earnest. Feature parity wasn't as much of a concern as being able to merge the old and new schemas without a headache, and making sure we could use the existing MT authentication code.

I don't know how much time I'll have at YAPC::EU to talk as I don't yet know when I'm leaving, but I'll suggest a b.p.org BOF session, regardless of what happens with the grant. That way I can address these concerns in person and we can discuss what will ultimately happen.


In the description you mention forking PearlBee in order to support MovableType's URLs, and possibly other reasons like better syntax highlighting. I think without looking at any source code or knowing how either MovableType or PearlBee are put together it would make more sense to just contribute these features directly back to PearlBee. Perhaps add an option to its configuration file to pick native, PearlBee, URLs or MovableType-like URLs. I don't know if PearlBee's design is flexible enough to easily support adding such an option to it, but if it is it is much better than forking PearlBee to add only one feature to it. Also, this fork could damage PearlBee itself, because people could wind up using this fork instead of PearlBee itself, because they want to replace their MovableType blog with PearlBee, which PearlBee itself does not support.

Thanks for taking this on.


Sign in to add comment