The FileSender project: collaborative opportunities in NREN land

15 pages
4 views

Please download to get full document.

View again

of 15
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Share
Description
The FileSender project: collaborative opportunities in NREN land. Guido Aben, AARNet Pty Ltd. APAN33, Chiang Mai. Talk purpose:. Share our experience with grass-roots, collaborative inter-NREN software/service development
Transcript
The FileSender project:collaborative opportunitiesin NREN landGuido Aben, AARNetPty LtdAPAN33, Chiang MaiTalk purpose:
  • Share our experience with grass-roots, collaborative inter-NREN software/service development
  • Tell you about the availability of a great service that you can run at your NREN for free, without any serious effort
  • Open the door wide for interested contributors (code, translations, testing, funds…)
  • FileSender, very high levelFileSender: User AdoptionStatistics from AARNet’s FileSender installation:
  • <1 helpdesk call per week (mostly re: federation!)
  • ~ 99.995% uptime
  • ~4% of users sending >2GB files, without instruction (seen 67GB in the field)
  • At February 2010, >2000 users& >6 TB uploaded
  • stats are world-viewable at https://cloudstor.aarnet.edu.au/mrtg/FileSender: Existing InstallationsASU Uni LithuaniaAARNet AustraliaARNES SloveniaCESNET* Czech Rep.BELNET BelgiumFCCN PortugalHEAnet Irelandi2CAT CataloniaInternet2* USAOkinawa Institute of Science & Technology*JapanNIIF* HungaryNorth-West UniSouth AfricaRESTENA* LuxembourgSIDN* NetherlandsSRCE CroatiaSURFnet* NetherlandsTERENA* NetherlandsUNINETT Norway
  • 18 known installations across 16 countries:
  • * test installationFileSender: project factsheet
  • Started April 2009
  • 1.0 released 31 January 2011
  • Core team of 5 NREN people in 3 countries
  • Agile, online collaboration
  • Back: php/apache/postgresSQL/simpleSAMLphp
  • Front: Flash + HTML5 (for >2GB)
  • Version 1.5 (beta out yesterday!):
  • http://blog.filesender.org/2012/02/13/filesender-1-5-beta1-released/plugin-free for >2GB uploads; MySQL support
  • Handles hanzi/hiragana/katakana/quốcngữ
  • (W3C, i18n, UTF8; auto language selection support)Splendid isolation: top-down SW dev“Every good work of software starts by scratching a developer's personal itch” – Eric S. Raymond
  • Match personal itch with internal req’ment
  • Run survey;look for clues to back up new service idea
  • Propose swiss army knife to funding body
  • Start in-house development straight away, using toolchain most convenient to developers
  • Run resultant SW on server box of your taste
  • Package what you have on the deadline; declare success*; move on.
  • Patch bugs with documentation
  • *at 100 users, at 200 logins, at 95% uptime, take your pickHow we optimised for collaboration
  • Still started with a personal itch of course!
  • (who would dare contradict Eric Raymond?)
  • But then consulted with int’l eR / NREN orgs, exchanged ideas, inspected similar services and SW
  • Reduced scope of initial planned release
  • Turned our dev group outward, not inward
  • Planned for ease of install, thus wide deployment, thus critical mass and sustainability
  • Resisted urge to use comfortable/hip toolchain;
  • Tested, retested and tested again: refused to fix with documentation; instead fixed user experience
  • Old vs. NewThe start’s the same – a personal itch.It’s very hard to start from requirements taken form surveys or focus groups. You have to trust your instincts somehow.“It's really hard to design products by focus groups. A lot of times, people don't know what they want until you show it to them.” – Steve JobsOld: Run survey;look for clues to back up new service ideaNew: consulted with int’l eR / NREN orgs, exchanged ideas, inspected similar services and SW(even tried to get 3rd party code public-domained; weren’t successful, but would try again)Our challenges are unlikely to be unique.And our survey reach is limited.Increasing the catchment area for “accidental discoveries” helped. Surveying the same people again doesn’t, usually, for us.If your challenge is really unique, perhaps you’re just scratching your own itch? Should that be funded with infrastructure monies?Old: propose swiss army knife to funding bodyNew: Reduced scope of initial planned releaseA tradition exists of promising the world on a silver platter to the funding bodies and then having to push lots of features overboard during the project. This makes planning hard and distracts from the real outcome.Instead we chose to work on a pared-down initial release that we could pay for without funding. Lay the foundations first, don’t get distracted by artificial deadlines.If the resulting product is great, we’ll run a funding application later.Old: start in-house development straight away, using toolchain most convenient to developersRun resultant SW on server box of your taste(script, install binary dependencies, chroot and recompile at will)New: turned our dev group outward, not inward- the full “open source” works: license, bug tracker, project wiki, packaging, releasingPlanned for ease of install everywhere, thus wide deployment, thus critical mass and sustainabilityResisted urge to use comfortable/hip toolchain(decided against java; picked php, forbade ourselves to use external dependencies)We made a conscious choice to sacrifice coding speed for long-term viability.The project was designed as an open source project; to have to be open about internal disagreement was… a learning curve. To have to refrain from grabbing a “more elegant” tool or language was hard at times. Having to wait for consensus… frustratingThe result has been a much bigger userbase, more input, more corner case testing and a much reduced per-user costOld: Package what you have on the deadline; declare success*; move on.Corollary: run service as-is, treat SW as abandonware, patch bugs with documentation*at 100 users, at 200 logins, at 98% uptime, take your pickNew: tested, retested and tested again: refused to fix with documentation; instead fixed user experienceWe like it so farIt’s been a rewarding journey:we have the service we wanted our project looks like it’s sustainableWe’re keen to try more of this:
  • More features delivered for filesender in a modular, collaborative way
  • A new service idea delivered in collaboration
  • Thoughts? Volunteers?More Info:www.filesender.org -- main project siteblog.filesender.org -- news, releasesAnd finally for those of you who’ve really become enthusiastic about contributing:www.assembla.com/spaces/file_sender/wiki/Workplan_2012
    Related Search
    We Need Your Support
    Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

    Thanks to everyone for your continued support.

    No, Thanks