Proposed rule: All centralised tools/data/IP should be optional

[Alex-Yates]

One of the things that the DevOps world seems to have settled on is that centralised and standardised tools can be really helpful, but that "product teams"* should have the final say on whether to adopt them. This keeps the centralised tools teams honest. If there are better tools on the market, teams should be free to use them instead.

May I propose that we adopt the philosophy that all centralised assetts are optional, and that while event owners are free to use them, they are not required to do so.

There are two important consequences of this.

1. When we create website/scheduling/CFP tools, we should not assume that all events will use them, and we need to support event owners who take a different path.
2. It is the responsibility of the tool creator to make their tools useful and desirable to event owners, not the event owners responsibility to use the centralised tools, at any cost.

---

'* I'm aware that it's better to focus on value rather than products, but trying to avoid getting bogged down in terminology.

[way0utwest]

I'm not sure what you mean here, in the specifics. If I decide to run a DataSaturday, as some sort of antwerp.datasaturday.com or datasaturday.com/event/45, I will clearly be using these tools. If I use sessionize or some equivalent as the call for presentations, I would have to upload the data here for scheduling for users.

I think adding to the toolset makes sense, and we ought to support this with feeds/downloads/APIs that allow for other integrations.

I do not seek to limit what people can do, but rather provide a framework that meets most needs and allows for extension.

[Alex-Yates]

I guess what I'm saying is that shared tools should be optional, not required. One of the challenges with SQL Saturday in 2020 is that the centralised website is a pain for event owners to use and that better tools are available for managing schedules and CFPs. The market for "as-a-service" conference organizing tools has overtaken the SQL Saturday site and some organisers find it more restrictive to use the SQL Saturday site than to do their own thing.

I think it's great to provide shared tools - but event organisers should be able to take or leave them. They should be allowed to go off-piste if they want to. And they should be allowed to put their own flair/spin on the thing, if they want.

This promotes innovation and avoids the shared tools becoming a burden rather than a help. It allows us to more easily adopt new tech when we need to.

Perhaps the "Data Saturday" website becomes little more than an archive of links, and the datasaturday.com/event/45 style links simply redirect to each event owners own websites which they have complete control over. Potentially including the ability to pick their own URL/name if they want.

[Alex-Yates]

Basically, I promote giving event organisers maximum control, and providing support to folks to self host as much as possible.

Like I said. Imagine if we had a standard dotnetcore template, that anyone can fork, with a GitHub action or an Azure DevOps pipeline that deploys it to a VM hosted in Azure, which maybe we can persuade MS to cover as a form of Data Saturday sponsorship.

This allows folks to self host down the happy path as easily as possible, but with maximum flexibility to do their own thing if they wish.

[way0utwest]

Good thoughts, and I hadn't considered the idea of a straight redirect, but that might make sense for certain events.

[Alex-Yates]

Thanks, although my comment is a little broader than that.

Basically, I'd like a loosely coupled system, where each event can run in isolation if it needs to with as few dependencies on the central platform as possible. Of course, centralised tools like an easy to spin up website template and some sort of mailing list, would be great, but they need to be optional.

Imagine if the Data Saturday site was more like tsql2sday. We don't host everyone elses blogs after all.

Let's think about what it would take for a new SQL Saturday organiser to set up entirely using their own stuff. Let's say that's the default starting point. All they need from the central site is a link on some archive page, and all the central page needs is a URL to point to. That's it, the sole dependency. And perhaps the maintainer of the lightweight central site effectively becomes the gatekeeper/authority on which of the events are official Data Saturdays.

Now how could we make that event organiser's life easier? Let's help them to do the thing above. Let's help them to easily spin up their own self-hosted site. Let's find someone to sponsor and cover the hosting (Microsoft?). Let's provide a template git repo that they can fork and lets give them documentation on dpeloying the site to Azure/AWS/somewhere similar? Let's help them to find the best tools for handling their CFPs. (Sessionize? Anything else coming along?) Let's help them to find a payment platform that they can run themselves. (Meetup and paypal?)

Let's basically help them to create their own microservice - that they have 100% control over. Let's not build another monolithic system with thouands of contributors who all have their own ideas and where large overhead is required. Let's let each event team make the thing their own. And let's all copy the best ideas from each other as we learn together and iterate one event at a time.

[gavincampbell]

I don't think the problem with SQLSaturday.com is that it has thousands of contributors, it's that it has about 2 contributors, neither of whom is involved in running SQLSaturday events.

I think the intent of having a central site is that not every organiser wants to deal with

deploying the site to Azure/AWS/somewhere similar

or

a payment platform that they can run themselves

I get that some organisers will want these things, but there will be some that won't.

If it's just a link directory, you also get the risk of redirecting datasaturday.com -> myawesomeconf.com -> thejewscausedthecovid.biz

[Alex-Yates]

Hi Gavin,

That's a very good point.

Perhaps let me rephrase. Rather than thousands of contributors, think about thousands of stakeholders, with only a couple of gatekeepers, and a bureaucratic development process. We are all familiar with event owners getting frustrated with the available tools and the challenges associated with improving them.

I'd like to avoid repeating the same mistakes. I would prefer an architecture that allows for maximum autonomy for event owners, with minimal dependencies, where great tools are freely copied and shared, but where the challenging ones can be ignored or easily improved upon.

I take your point about the overhead for folks doing it all themselves. And I'm not saying we don't give people the option of using shared tools/services. My point is that we should create an architecture where all of these shared tools/utilities are optional for event owners, and where event owners are able to do their own thing if they choose.

My final pitch for this sort of architecture is to think about it like a Lean Start Up style Minimal Viable Product (MVP). I would argue that from a technical perspective, the MVP is a tsql2sday style website that just links to various other event sites hosted by the event owners themselves. Most of them are capable of spinning up a basic wordpress site after all. And most would probably prefer to use the tech they are comfortable with. Of course, there will be other non-tech stuff we will need to agree about governance and branding and all the rest of it. But is anything more than a basic archive site necessary for v1? Would it be impossible for "DataSaturday#1" to run without a uniform payment platform?

And as we grow, we can listen to the pains that event owners actually have. And event owners can share their own solutions to these problems and we can iteratively develop optional shared utilities to help folks get set up - but these are v2+ problems.

[way0utwest]

I would be careful of "all" as a descriptor. In my dealings with many organizers, many have some complaint about a particular feature/process, but few want to do much of anything other than run their event. I guess a small minority want to customize anything outside of name/date/location/basic info.

Most people want a platform that provides capabilities and assistance in running an event. They don't want to run software.

The open architecture for integration points isn't a bad idea, but every integration point requested starts to bring in additional development and maintenance overhead, not to mention security issues. Having worked in the software business for a long time, I can continually surprised by the level of overhead across time.

My vote would be for a platform here that provides services, and is adapted and grown over time, with limited integrations for specific services. I would, however, like to see support for a redirect URL for those that want to run the entire system themselves.

[Alex-Yates]

"however, like to see support for a redirect URL for those that want to run the entire system themselves"

I think this is (basically) all I'm asking for. :-)

[SQLClause]

That's how I read you as well Alex. And I agree - enabling the redirect for those who want it is great.

However, we need to make sure there is some sort of data owner/processor transferral set up as well. So that it's clear to the attendee/subject who collects and controls the data in this event.