Here's my notes from another long day at the Moscone Center ... more great sessions
Ten ways to destroy your community
- How to open source a project or how not to
- When working on a open source project, you contract a diese ... a community
- kiss your marketing plan good bye
- mess up your product plans, unexpected innovation
- they're never satisfied by any amount of quality ... no satisfying them
- re-define who's a customer / partner, relationships change
- you have to communicate all the time, who has time for that
- Is there a way to address the menace: 10 steps to make it fail:
- difficult tools
- issue trackers
- weird build tools
- single platform
- poisonous people; trolls, damage they can do
- argue with them at length
- denounce them public
- ban them
- argue in other forums
- then allow them back in
- no documentation
- no code
- build methods
- submission process
- release process
- how to install it
- Closed-Door Meetings
- on-line, short notice
- telephone meetings
- meet in person, in secure office
- Legalese, legalese, legalese
- the longer more complex the better
- contributor, website, non-disclosure, trademark
- change these docs all the time
- Bad liaison
- someone reclusive
- someone with no time
- someone with no authority
- someone unfamiliar with the technology
- don't assign one at all
- Governance obfuscation
- follow United Natations model
- decision / election should be complex and lengthy
- unclear what powers community have
- rules nearly impossible to change
- Screw around with licenses
- License == Identity
- Developers have attachment to licenses (emotional)
- Changing it or threaten to change it
- No outside committers
- only employees get to be committers
- if they ask, be evasive about it
- have no written rules about how someone becomes a committer, or criteria is impossible to fulfill
- promtoe an employee who doesn't code to be a committer
- Be silent: this is the most powerful of all
- don't do anything
- this is the easiest one
- difficult tools
- Ten ways to be successful:
- familiar tools
- discourage poisonous people
- document everything
- accessible meetings
- minize legalese
- expert liason
- governance simplification
- treat licenses with respect
- promote outside commtters
- communicate
Growing Open Source Developer Communities
- goal / expectations
- what are you building
- different projects attract different contributors
- product or platform
- products extend
- platforms are core
- great projects do both aspects well, rare
- code is king
- starts with code and documentation
- source code basic unit of open source
- collaboration
- first barrier is getting the source
- make accessible
- buildability
- ensure builds for others
- avoid unfamiliar, complicated tools
- use open source build tools
- document dependencies
- make build work or fail fast
- first impression, is important
- tell the world about it
- announce widely
- freshmeat, osnews, slashdot, digg, reddit
- development blogs
- use blog aggregator / planet
- use hackergotchis - recognition factor at conferences
- who's the public face for the project
- sharing wisdom
- blogs have shared narratives
- communities form around stories
- how you write about yourself is how the world will see you
- remains searchable forever
- don't market project by slagging your peers
- multimedia
- podcasts let people hear your voice
- get ideas into the ears
- developer interviews
- showcase people behind the code
- screencasts, see features in actions
- archive conference presentations
- associate faces to a project
- ubiquity
- available to play with
- Live CD, VMware images
- success attracts success
- present at local conferences
- talk to press and analysts
- the first patch is the hardest
- smaller barrier to entry
- make code build well
- learn contributor interests
- first impression matters a lot
- converting volunteers into contributors
- sources: porters, software distros, integrtors
- work in other env
- likely to become power users, try to tie them into the project
- development is based on social trust networks
- trust is earned through ood contribution
- delegate early and often
- encourgage good contributions
- grow the developer pool
- a bit of communication theory
- two-step flow theory
- info moves in two stages
- mass media transmits
- leaders pick it up, break it down, recombine it and disseminate it further
- word-of-mouth
- trust
- the distribution model
- linux distro aggregates open source
- packaging
- power users and marketers
- tearing down the fourth wall
- need infrastructure for collaboration
- remove the committer access barrier to entry
- mailing lists ( developers, users, announce)
- IRC
- bugtracker
- setting priorities right
- review tools
- share results with everyone
- ambient findability
- serarhc engines drive a lot
- social engineering
- people are different
- different strokes for different folks
- keep out trolls
- recognize through their posting behavior
- encourage developers to take over responsibilities
- volunteers to self-organize
- developer audience is largely self-selecting
- responses need to matter, even to the rude
- avoid belittlement, hosility
- it's not all code
- non-programmers may want to help
- docs, web site, marketng
- low barrier to contrib
- real world meetings and conferences
- Governance
- first time, join a foundation FSF, ASF, Eclipse, etc.
- provide framework, legal and admin issues
- pick an initial model (dictator, cliques, voters)
- everyone different
- expect to change over time
- don't
- mastermind and control the project
- they to make everyone happy
- don't fear the fork
- experimental (good) and hostile (bad)
- maybe for marketing
- trademark assurance of code pedigree
- best discouragement is a well-run project
- dealing with legalese
- don't create own license
- stick with what developers know
- prepare to change it
- copyright assignments lets you change your mind
- trademarks
- patents
JRuby on Rails: Web Development Evolved
- Overview of Ruby features
- Overview of JRuby
- Started in 2001
- Java impl of the Ruby language
- Opensource
- Commercail backing, Sun, Thoughtworks
- Why JRuby over Ruby
- performance, scalability, native threads
- integrate with Java libraries
- Easy to use Java
- require 'java'
- Use juby within a Java program
- Ruby on Rails:
- web dev framework
- single threaded, shared-nothing design
- convention over configuration, common case should be the easiest
- don't repeat yourself (dry)
- agile development
- Demo: create a blog application
- Why JRuby on Rails
- Ruby
- Java app server, Java EE platform
- Real world
- mix.oracle.com
- mediacast.sun.com
- mingle, first JRoR product
- Future: Ruby
- rework integration feature
- public api
- better performance
- light weight objects?
- JRuby on Rails
- mutltithreaded rails
- runtime info sharing, avoid memory hit
Ajax and JSF: Natural Synergy
- How to support Ajax without javascript guru
- JSF in action book
- What is JSF, standard framework for web user interfaces
- JSF is a specification, component and event model, basic ui components, application infrastructure
- Extensive tool support, RAD style design
- third party component market
- on top of Servlet API
- Compare JSF and Struts
- IDE effect; different levels and styles, not required
- JSF programming model: View, Event, Backing Bean, out come, navigation
- Pluggable Extension points: Resolver, View, Navigation, Action, State, Render
- Ajaxian Faces: components and renders can be seperated, PhaseListeners can be modified, transparent Ajax support
- JavaScript bridge sends request
- PhaseListener sends changes
- JavaScript Bridge updates page
- some components may not be compatible
- no standard for bridging, resource resolution
- Sprinkling on Ajax
- JSF event listener executed async
- Ajax4jsf (RichFaces), AjaxAnywhere, DynaFaces
- Ajax4jsf: add ajax support to JSF component with javascript events
- Demo: apache myfaces tomahawk
- Ajax inside
- ECruiser Ajax Suite for JSF
- ICEfaces, innovative take on ajax browser/server integration, direct-to-DOM, supports Comet
- Infragistics NetAdvantage for JSF, full ajax support
- Sun Project Woodstock
- Apache MyFaces
- Ajax on the outside:
- what about those cool pure widgets
- jMaki, wrqppers popular widgets, easy to create
- YUI4JSF
- DojoFaces
- Mojarra Scales
- Which one to pick
- pick a component suite
- myfaces tomahawk has some ajax support
- has good JSF support
- how much ajax do i need
- use jMaki for eye candy or Web 2.0 components
- don't forget tool support
- rolling your own, use toolkits to build components
- JSF 1.2: improve ajax support
- JSF 2.0: late 2008, Java EE 6, incorporate more features, bookmarkable
What's new in Ajax
- not long ago the web was not a fun place
- now really nice interfaces
- creating compelling user experiences
- four main frameworks
- jQuery, high level components
- ext JS, thin ajax layer
- dijit, on top of dojo
- script.aculo.us , it's all about the interface
- browser, is a single threaded process
- access to threads outside the browser, google gears; worker pools (message passing)
- Fluid, Mozilla Prism, Adobe Air; access to the desktop
- Fluid: demo with campfire
- userscripts.org uses greasemonkey, lots of javascript
- problem wih ajax, need javascript and another language
- how to create a better developer experience
- Atana Jaxer - javascript on the server
- netscape livewire (javascript on the server)
- deployment
- the cloud services - amazon EC2
- Google App Engine - build code, hit the deploy button
- Aptana Cloud - make cloud computing easy
- moving your apps to a web service
- how do we choose
- dojo / dijit
- jquery / jQueryUI
- google widgit toolkit
- prototype / script.aculo.us
- The New Java Plug-in, 1.6 update 10
- plug-in now out-of-process
- improved applet deployment
- smaller JDK, micro-kernel
- Look into the future
- Safari: css animation, reflections and masks
- Mozilla monkeys, javascript runtime compiling, javascript two plugin for explorer, iron monkey (python)
- constrant to browsers
How to build RESTful Clients with the JavaScript, Ruby, and JavaFX Programming Languages
- RESTful web services
- services are stateless
- have unitform interface
- built from resources via URIs
- exchange representations of the resources
- Building the client
- create request data
- send request
- parse the reponse
- code, header, body
- formats: xml, json, kml, taml, rss, etc.
- Debuging RESTful client
- PUT and DELETE is idempotent
- non-connected
- PUT vs POST
- use POST if URI length issue
- async issues, use XHR
- authen
- caching,
- overloaing POST
- Demo: JavaFX with flickr
- Demo: Javascript with Amazon S3