When we built the first SQLSaturday it was about 2 pages of HTML. No login, no tools, just get it done. Worked ok. Didn’t work so well for the second event in Tampa as they had to call me to make every change. Clearly we needed to “empower” and as there was no obvious alternative, we started building tools to enable running an event. A bit later, we started working on tools to manage one level up from that, the sysadmin type access needed to administer – back then – 10’s of events a year.
Tools are interesting. I’ve often said that for SQLSaturday it felt like the tools handled about five percent of the effort to run an event, but it was an important five percent. Having some structure, some tools, made it seem just approachable enough that someone who just wanted to run an event could make a go of it. [Even today, think about using Eventbrite or Meetup vs building your own – how many want to build and have time/skill to do it?]
Some were frustrated that the tools wouldn’t do X or allow Y, others wanted A and not B, etc, etc. I’d guess that most event organizers found the tools ‘good enough’, but surely they frustrated everyone at times to lesser and greater degrees – hard to build one size fits all. The answer, obvious now, and perhaps then, was to separate the brand from the platform. Here’s how that might look:
- Option A. Use the tools provided. Think of this as wordpress.com vs wordpress.org. Maybe 80 or 90% would go with this because the tools match the workflow and there are plenty of people that can help you put them to use in the same context.
- Option B. Host your own. Again, this would be wordpress.org vs wordpress.com. Set it up, own your data, change stuff if you want.
- Option C. Build your own. Write it in Java, C#, Go or Rust, React, Angular, even Oracle.
- Option D. Call it something else, find or build your own tools, and make whatever rules you want.
Those are all valid choices. Three of them (A, B, C) are SQLSaturday, one (D) is called something else and might look very much the same or very different, as the organizer prefers.
We’re trying to run and encourage events that enable people to learn. Tools enable that, or at least facilitate it, but the tools shouldn’t be the focus. Think on that some, tomorrow I’ll post again with an idea about going a step or two further down this road.
2 thoughts on “SQLSaturday Doesn’t Have to Be a Platform”
I like what you are saying. I’ll be looking to see how you expand the idea.
Comments are closed.