It's official...I'll be at the Film Festival this year going over some of the basics on how to get an online community started. You can register your interest in the program here, and see my original proposal here.
Here's a rough proposal for a talk at the 2009 CT Film Festival. Let me know if you have any comments or questions!
Being online is a must for any burgeoning content creator, but standing out from the crowd is an ever-growing challenge. As the online community grows and matures, so too must your online persona. In this session, I will go over a pair of tools that anyone can use to create a home for that developing persona. I will also cover ways to get media distributed online and ground rules for interacting with your online community.
The majority of this discussion will cover two avenues for creating an online home. First, I will cover a new, simple solution: Squarespace. Squarespace is an all-in-one modular service where you can easily assemble pre-made components in order to build a community-oriented website. Though not the most flexible solution on the market, it is one that has much appeal for less technical or time-constrained users. I will follow up with an introduction to Wordpress, a more traditional software package with a far greater breadth of use, but one that requires more technical skills to set up and maintain. For both packages, I will cover the basics for integrating video, audio, and photos.
The last part of the talk will be devoted to dealing with an online community. I will cover such basics like moderation and not "feeding the trolls". I will also showcase some good and bad examples of online community management.
When Amazon began reselling their backbone as web services, another barrier to the internet collapsed. Much like the introduction of the LAMP stack heralded the arrival of commoditized web applications, Amazon's service heralded the commoditization of large-scale application deployment. A budding web company no longer needs to choose between initial infrastructure investments (in the form of large-iron servers) or robust prayer (that their nascent website can survive a digg, crunch, or slashdotting).
The problem...or at least my problem...with Amazon's services was trust. As the first large-scale cloud computing service, Amazon was destined to experience growing pains of some sort. Companies that bought into their technologies had to trust that these pains would not prove deliberating, and had little choice but to sit back and hope during recent outages.
Today, Google has launched their own version of Amazon's cloud computing technologies. While currently more limited in scope, Google's histoy suggests that they will eventually be brought up to speed with Amazons offerings, though likely in a slightly different form. Once some form of parity in these services is achieved, purveyers of cloud computing techology will finally have the one missing peice of the web services puzzle.
Once platform developers are comfortable in the niceties of both environments, I anticipate that most smart startups will begin to hedge their infrastructure bets and learn ways to load-balance their offerings across both of these platforms. As each service is pay-as-you-go, the ongoing costs will not be drastically different than the consumption of either service separately, and the ability to leverage the infrastructure of two web giants should outweigh any additional development overhead.
This can only be a good thing for everone involved. Google has found yet another revenue stream that leverages its massive hardware backbone, developers gain the power of choice, and even Amazon should benefit from the growth caused by the expanding market. All in all, it is a good day for the internet.
One of my clients recently overhauled their talent pool. Their staff went from two freelancers with very general development skills to one generalist (me), two php developers, and a CSS/HTML developer. System administration was understandably not in the three new developers' bags of tricks, and so they needed to be given development environments. As the only remaining person with system chops (and what mediocre chops they are), it fell to me to set these up. The project manager and I decided to set up completely isolated instances of the site and database, all hooked together by our subversion system.
Setup took longer than expected. Between minor issues at the host, incompatability between our code and library versions on the new server, and inevitable communications delays, we lost the better part of the week to our setup. This left several of the clients' staff wondering at why such elaborate preparations were necessary. Why couldn't all the developers just work out of a single environment and database?
This confusion left me at a bit of a loss. I remain confident that we took the right steps in getting our new talent up and running on the project, but I had no idea how to communicate the need to a non-technical individual. Most analogies I worked through fell apart in short order. The building-a-house analogy? Doesn't work - you generally don't have one contractor building a roof while the other works on the foundation. The writing-a-contract analogy? No parallellism to reference.
Finally, I started picking apart some variations on the writing-a-story analogy and came up with one that seems to fit. Let's assume several authors decided to team up and write a character-driven, multi-chapter story. Each author would write one chapter that would feature one main character, and that author would be the authority on that character. However, all the characters will by necessity interact at various points during the story.
When writing begins, each author can work effectively in isolation within his or her own chapter. The character develops, and encounters with the other characters are documented. As these interactions unfold, however, they may begin to start interfering with other parts of the story. What if in Chapter 1, Jonny said "Where will we go next?", while in Chapter 3's telling of the same encounter, he says "Let's go to the cave!"? Johnny's author would need to go into someone else's chapter and fix the quotation.
Now you're faced with the prospect of more than one person editing the same document at the same time. Most people can understand that significant issues can occur here - for instance, if two authors are editing the same chapter at the same time, the chapter will ultimatley contain only the changes of whoever saves last. What you need is a mechanism by which each author can edit a chapter and have their changes merged together seamlessly.
That's where version control comes in. Version control takes the different parts of the story and gives the authors the freedom to make changes wherever necessary without impacting one another's work. When you extrapolate the analogy into real development terms, its usefulness becomes amplified by the fact that it enables editing by anyone, anywhere with an internet connection.
There's certainly some gaps in this description, but for the most part I think it holds up. If nothing else, it serves as an interesting intellectual exercise.