Edward Finkler http://getspaz.com @funkatron http://funkatron.com

• non-technical talk–“why I do what I do”

  • learned how I define what success and happiness are

• Spaz is a personal project — about 3 years old

  • twitter client — “your special twitter friend”

    • based on original logo people thought he was making fun of mentally retarded people
    • actually is a picture of clay aiken from early american idol

• Early 2007

  • work started on Spaz
  • had done a couple of open source PHP libraries in the past
  • had only done open source for other developers, not for end users
  • started work in RealBasic on Mac

    • also the author of LameBrain, wrapper for LAME

  • started getting interested in twitter API
  • not many other Mac clients for twitter at the time
  • article written up in ars technica about it
  • pownce came along about the same time

    • came out with desktop client, written in apollo (now AIR)

  • RealBasic wasn’t set up to make it easy to make it look non-standard or skin things
  • silverlight was also being released about this time, also Java FX
  • particularly interesting aspect of AIR was that you could make apps in HTML/CSS/JS in addition to Flash

    • looked at using Flex, but not a fan of monotheistic technology
    • Flex community is a lot like the MS development community–one official source of information, not a lot of community sharing going on

      • quite a contrast with something like PHP where everyone shares in a bunch of different ways

    • didn’t like having to go through the official channels to try and figure things out

      • really hard to simply search for things on the internet and find examples with Flex

  • twitter was really flaky at this point–had to write the code very defensively
  • learned a ton by digging into this–crash course in javascript
  • driven because he was interested in it and enjoyed working on it

    • “I liked what it did, and I used it”

• November 2007

  • Adobe had AIR Developer Derby in mid-2007

    • submitted Spaz on a whim
    • got a call in October 2007 from Adobe saying he won

      • got to go to Adobe MAX conference, lots of PR around it

  • Adobe didn’t give a rat’s ass that it was open source

    • they liked it because it was pretty
    • only got about 5 submissions on the HTML side of things

  • was at the AIR booth–people asking tons of questions that frankly Adobe should have been answering

    • turned into evangelist of sorts

  • cool that Spaz got known in the wider world

• 2008-2009

  • started to get emails criticizing the name–“why do you hate the disabled?”

    • happened quite a bit

  • tons of twitter clients released in 2008

    • lots of them written in AIR
    • a few clients were a lot better with marketing themselves — biggest example is TweetDeck

      • people spending full-time on it, went after venture capital, etc.
      • cool if you want a twitter client that fills your whole screen, but wasn’t what he wanted to do

  • seeing success of tweetdeck was hard

    • started seeing comparisons of spaz vs. tweetdeck–lots were kind of nonsensical

  • the thing I like about open source is creating something and getting ideas from people, hearing about how they’re using the product, etc.
  • lots of end users were saying stupid things like “Spaz sucks”

    • big disconnect–creating products for end users is pretty different from creating developer libraries
    • people were dismissive and mean — made it not fun
    • eventually learned to respond with humor to baseless criticisms

      • helped to not get as upset about things

  • started seeing companies that were hanging off twitter and providing services that twitter doesn’t provide

    • twitter has started to stomp out all the ancillary business around twitter

  • started getting offers from companies around spaz

    • people offering money to add specific services to spaz, e.g. twitpic

  • wanted to continue to provide an open source, transparent twitter client

    • in one case took money as a donation to offset overall development time into spaz
    • wasn’t interesting in doing this in general

  • this underlined a specific way that he wasn’t willing or able to compete with other clients that were out there

    • would sacrifice transparency around the project
    • realized how screwed up and evil tech journalism is–fundamentally wrong

      • actively manipulate how people perceive things, don’t give coverage to things that don’t play their game

  • started to realize he couldn’t compete with other clients because of all the extraneous junk that goes on

• palm webos — jan 2009 – june 2009

  • got call to see if he was interested in working on apps for the new webos
  • palm wasn’t really known as an open source company
  • said up front he wanted to keep the app open source–palm didn’t object
  • web development as a rule is pretty open, but palm didn’t really have this understanding in their DNA
  • had to sign really strict NDA
  • palm was rushing things out, documentation was terrible
  • went to a developer event at palm–could talk about things, but couldn’t share the code he had written–against the NDA
  • this six months sucked because couldn’t make something and share it with other people
  • palm didn’t tell him another company was also working on a twitter app for webos

    • found out from someone else–no information sharing going on
    • bunch of secret stuff–wasn’t fun

  • didn’t get a development device–emulator ran 3X faster than the actual phone

    • didn’t write specifically to their proprietary platform so it ran slow
    • another twitter app that did write to the proprietary bits ran faster

  • got email from palm asking not to release source code

    • had told them first thing he was going to open source it
    • lot of wtf moments
    • decided he would never work for another company like this under an NDA
    • palm didn’t get the sharing culture–they get it much better now

  • two guys from ajaxian got hired to better interface with the development community

    • immediate changes for the better–hope HP doesn’t screw it up

  • reminded me of lessons i should have learned the first time around
  • friend recommended book — “ignore everybody and 39 other keys to creativity”

    • the thing that you really like doing, if you rely on it for income, it’ll become less enjoyable and it will change how you interact
    • when spaz became something that was being defined by standard definitions of success, the process became less enjoyable
    • had to redefine what success was

• july 2009

  • spaz statement of purpose

    • can keep going back to this and referencing it to remind himself of why he’s doing what he’s doing

  • spaz was built for the sake of building it. it is not a means to an end. however, creating it has had several good consequences.

    • point of it was to build something and build something good

  • spaz demonstrates that making things is good, and sharing how you make them is better.

    • creative endeavor in and of itself is good
    • sharing is what makes me happy

  • spaz is a necessary counter to closed, hidden technologies. spaz must always be open.

    • source code must always be open and have to be transparent about the intentions of the project
    • important that we have options, even if they aren’t the most popular or defeat other projects

  • the value of spaz does not lie in the judgments of others, but in the process of building it, and the enjoyment derived by those who use it.
  • we welcome anyone who wishes to participate in the spaz project with open arms, as long as they understand and respect the purposes of the project.
  • the spaz project values clear and open communication between participants.
  • having the statement of purpose helped keep things going when it was frustrating

• 2nd half of 2009

  • not a lot happened
  • worked on getting webos version better
  • started on spazcore to share common things between all the different platforms
  • discovered didn’t have time to try to keep multiple versions going
  • started working on community building

• diversity statement

  • women are under-represented — 10-15% in IT as a whole, open source it’s more like 2-3%
  • worked with a group called phpwomen
  • largely lifted from python’s diversity statement

• rest of 2010 — cultivating a community

  • initially was using google code for everything
  • have found that github works better

    • a lot of people use git (particularly js people), more social aspects oriented around git (easier to fork, etc.)
    • potentially attracts more people

  • tenderapp.com and lighthouseapp.com

    • tender oriented towards end-user support — offer free accounts for open source projects
    • lighthouse more oriented towards developer issue tracking, setting milestones, etc. — also have free accounts for open source projects

  • if you only have roadmap, etc. in your head it’s very hard to get people to help you

    • need to break things down into issues of various size
    • schedule people’s time for them in the sense that you give them bite-sized tasks

  • hackathon

    • great way to get more people involved
    • helps to have a schedule
    • done online with irc

  • have someone who’s more or less dedicated to doing community related tasks

Ben Dechran, Sputnik Agency (Australia)

• works for a marketing agency, lots of photoshop files thrown around
• file server which works great most of the time unless …
  • people forget to put the files on the file server
  • people forget to rename a file before putting it on the file server and delete the old file
  • people don't put a file on the file server and go on vacation
• dropbox nice solution, but has issues
  • works well for small companies, small groups, unconferences, etc.
• problem #1 — storage space
  • in our case, needed 3TB of space
• problem #2 — need internet connection
  • if connection goes down, you have the files but you lose the sync
• problem #3 — dependent upon third party
  • what if they go down?
• problem #4 — all or nothing
  • every person replicates everything
  • dropbox supposedly doing selective sync
• problem #5 — user management
  • users can't be managed by your company's infrastructure
• problem #6 – big bad world
  • security and privacy
  • it's encrypted, but you're sending data out to someone else's servers
• other options
  • ifolder – open source project by novell, written in .net
    • tricky to set up
    • slow
    • packaged for windows, mac, opensuse
• decided to roll my own–needed …
  • local files
  • monitor for changes
  • versioning
  • conflict resolution
  • transparent — install and forget
• attempted solutions
  • tortoisesvn — people forgot to check in, etc.
  • cron job to push changes to svn
    • some of the changes were hard to detect
    • if someone deletes a directory on their hard drive, deletes the metadata
  • tried git — since it's distributed it solved some of the issues with svn
• for synchronization
  • inotify, inotifywait — in the linux kernel
  • notify-send — could use this for bubble type notifications in dropbox
• for conflict resolution
  • grep the git status
• iizip is the combination of all these various tools
  • currently the project is a bunch of scripts; eventual goal is to have a package that would be deployed/installed on local machines
  • iizip-init — creates git repository and iizip directories
  • the scripts mostly map to the git commands
    • e.g. send checks in locally and also pushes to remote repository
• someone in the audience suggested looking into using couchdb in similar fashion to how ubuntu one works
  • http://arstechnica.com/open-source/guides/2009/12/code-tutorial-make-your-application-sync-with-ubuntu-one.ars
• what's in the pipeline?
  • partial checkout so not everyone has to have every file locally
    • idea of subscribing to specific directories–IMAP already does this
  • push changes from other machines
    • currently there's a cron job that runs on the local machine
    • dropbox immediately pushes changes to all machines
    • considered using xmpp to handle this, but IMAP has persistent connections and also supports directories
  • multi-user
    • currently can't run more than once on the same machine since the directories are hard-coded
• unix tools philosophy — many small tools linked together to achieve a larger goal
  • also makes it easier to port to other operating systems
• unison — would in theory do all of this so worth checking out
• potential issues — git doesn't track empty directories
  • if it's empty you may not care