Wedge

Even 'improving spiderability' tips I've been shown and recommended tend to lean towards the 'snake oil' category rather than anything solidly useful...

OK, I'll say it again. And I'll be more blunt about it.

I WILL NOT BUILD A WALLED GARDEN. I will not create an environment that forces a single source of mod production.

There are two reasons for this:
1. I did actually design and build my own mod repository for SMF once upon a time, where I could publish what I wanted without any restrictions imposed by any moral majority. I could, for example, have released a mod that allowed for viewing user PMs, if I so chose. Such a mod would have been forbidden by SMF, but the only rules I set for my site were my own. I would be trampling on the very freedom that Wedge was borne out of if I did not allow for choice.

2. Wedge opens a lot of doors, it represents a shift from the past. One of the things I was never happy about with SMF was its lack of premium resources.

The health of an ecosystem is reflected in the community that grows up around it. While I dislike much about WordPress, I respect that it has a lot of contributions from its community, in the form of themes and plugins, and there is a goodly number of premium resources. The platform is considered sufficiently viable that professionals are contributing to it, that it doesn't just represent a loose-knit collection of individuals contributing in their spare time and augmenting it with those who can justify spending professional-grade time and energy contributing to the ecosystem.

My stance is just that: if a platform and its ecosystem actively discourages professional-grade users from publishing premium resources, the sum total of its ecosystem becomes a collection of hobby contributors producing hobby contributions.

This is not, and should not be, construed as an insult to hobby authors - people just contributing code when they feel like it, is the backbone of any software-related community. But there is a glass ceiling of sorts: those who do it as a hobby invariably do not have the time and energy to commit to contributions in the same way paid professionals can do so. Being a hobby, they may not pursue the finer points of programming, and as such it's likely that - objectively speaking - the quality will be lower.

I should note that this isn't true of all ecosystems, nor is it true of all hobbyist programmers vs premium programmers. There are genius hobbyist programmers out there, just as there are absolutely abysmal premium programmers out there. But as a broad rule, if charging for something, the quality curve tends to be higher.

I do not want to design an environment that casts out the premium contributions. If it were true that people valued price over performance, we'd all be using SMF/phpBB/etc and no-one would be using vBulletin or IPB - because they are paid endeavours, there is much more incentive for them to keep developing, plus more incentive for them to add new things, because there's a reward in it other than the pure satisfaction of the thing.

That's another thing that's quite important: the reason *why* people do it. We're up front about why we're doing Wedge: because we're building it to be the platform we want it to be. When I wrote mods, I wrote them because they fulfilled a task I needed of them - but that was it. I didn't want to be dragged into ever-increasing circles of more features just because people asked me to - there was less joy in doing that, and I wrote things to work how I wanted them to, and I've lost count of the number of times I was asked to change what I did because it didn't suit someone else - if I wanted it to work the way they wanted, I'd have written it like that up front.

Paid contributions to the ecosystem actually swing the balance towards users, rather than leaving the power solely in the hands of the developer in their spare time: if there's a demand for a certain function/feature, it'll be written and if the market can stand it being charged for, market economics will allow it to.

There is an implied third reason that sums up the two together: us running a plugin repository that handles paid plugins puts responsibility on us. It brings up who is responsible for payments, who is responsible for security matters, and potentially would put us in legal liability situations that we have no desire to get into in the first place. This is why I didn't end up running smfmarketplace.com as I once envisaged.

Consequently, having an 'official repo' like sm.org has is nice but it removes the potential for premium resources and tying users into it brings a whole world of hassle in terms of walled garden. The last thing I want to do is shoot developers in the foot who like Wedge as a platform but may not care for myself or Nao in terms of personality (hey, it happens, we are perhaps 'abrasive' people)

That all said, I'm inclined to keep package servers in some form or another, but not necessarily updating magically. Any plugin that really needs it (like SimpleDesk, SimplePortal etc.) can implement their own method readily enough.

That's less a fault of the package manager and more a fault of the package serving architecture.

WP has this function, however, WP has it set up so that you are pretty much obligated to use their architecture for grabbing plugins. Consequently, if you're using their architecture you can use it to keep up to date. But the minute you start having any (and I do literally mean *any*) other service, you're pretty much telling users they have to keep things up to date themselves, as one of the caveats of not using the core architecture.

Now, I'm not exactly enthusiastic about having a single locked-in repo. Partly because of all the arguments about the 'walled garden' (personally, I'm not against it since it benefits users but it doesn't help developers much if those in control of the garden change the ruels)

But without a single master repo - and everything else being 'caveat user', so to speak - there's no really good, or reliable, way to manage that kind of update.

The biggest thing that a plugin repo needs to be able to do is harvest the meta data from the XML file in the package and process it. The reality is that whatever process there is for publishing a package (be that upload, or build from SVN or similar, or whatever), that just has to process the XML and display that information alongside the download.

Oh, definitely, I'll agree with that. But this is the sort of thing where we have the opportunity to break from years of established behaviour and I'm going to grab it with both hands :D

(Btw, Core Features will be beaten into submission and removed at some point.)

I can't imagine why ;) Yes, when I wrote that one a year ago I shamelessly ripped it off from Core Features. And it still suffers from the same unintuitive behaviour that Core Features does. This is, amongst other things, one of the lessons I learned since building this originally.

If we're going to do that, are we going to do the whole shebang, of giving users an SVN repo to put their plugins in and be auto-built from that?