FOSS4G 2009 Lessons Learned

From OSGeo
Jump to navigation Jump to search

See also: the other Category:FOSS4GLessonsLearned

Bidding

  • Find your local tourist bureau to help you bid. The Sydney Convention and Visitors Bureau helped us significantly, providing all the statistics and photos you need to promote your city. It is boiler plate stuff for them.
  • Plan ahead. FOSS4G moves around the world to give everyone a chance to attend locally.
    • Bidding cities should take a long term strategy. If you don't win one year, keep submitting until you do.
    • The bid committee should suggest regions they would like to move to in the near future which will encourage cities in that region to bid.
    • Feedback to unsuccessful bids should include targeted feedback, including rankings, to help cities refine their bid.
    • Cities should engage the local conference industry. They are likely to provide their services for free in order to secure the conference.
  • Network locally. A large, diverse team is attractive to selectors.
  • Be open in your bidding process. While it may allow competing cities to gain advantage, you will demonstrate your strength and openness to the OSGeo bid committee.
  • Talk up your city and local involvement at FOSS4G the previous year. Tim Bowden talked up Sydney's intention to bid for 2009 at FOSS4G 2007 and no other city decided to bid for that year.

Reference: International Conference delivered to your doorstep by Cameron Shorter

Commercial In Confidence Documentation:

  • Open Source developers often expect that all FOSS4G documentation will be Open. Unfortunately, the Professional Conference Organisor (PCO) industry seems to protect all their processes and documentation very closely. Consider this when dealing with them. Request up front for documentation to be made available publicly. Some documents, like Bid Proposals will probably remain Commercial In Confidence, and you need to ensure participants are aware of this.

Contract

  • Make sure that all documents created by the PCO (logos, sponsorship documents etc) are provided to you in source format. You will almost certainly want to update them later based on feedback, and you want don't want to have to pay a designer to make a simple tweak. We had a designer create a beautiful sponsorship prospectus (provided as pdf), but sometime simple and easy for us to change would have been cheaper and easier to change.

PCO Selection

  • Select your Professional Conference Organisor (PCO) earlier rather than later, preferably before you put your proposal in. The PCO should help you put your budget together, and if they put the budget together for the bid, they should be well advanced when you win.
  • Instead of using a PCO, consider using a non-profit organisation like GITA or SSI. These organisations often have expertise in organising spatial conferences, have contacts in the spatial industry, and are not out to make a profit from your conference. We naively expected our PCO to convert our potential sponsors list into sponsors, but almost all sponsors needed to be invited by a member of the Organising Committee.

Technically Savy

Our PCO required training to become familiar with Geek communication practices. In particular, the PCO preferred telephone conferences over email lists, wikis and IRC and was unfamiliar with email voting. This required training and negotiation with the PCO.

Lesson:

  • Ensure PCOs have realistic expectations regarding our communication habits up front by describing them in our PCO tender documents. In PCO selection, include familiarity with email lists, wikis as one of the selection criteria.

Conflicts of Interest

Our PCO offered provided many of the conference services in house. This provides a financial incentive for the PCO to upsell services (like a professionally produced Prospectus which we couldn't edit later without being charged extra), and being over charged for items - eg. We were charged for communication which included the use of email.

Lesson:

  • The PCO should not get to provide services for line items in the budget.

Decision making

  • Collaborative decision making is good, but make sure each committee has a chair-person with the mandate and authority to make decisions on behalf of the committee. (The chairperson should consult the committee and aggregate comments). This should make the committee significantly more effective.

Sponsorship

  • Make sure you have access to, and can edit the source format of the prospectus. We found we needed to pay our PCO every time we needed to tweak our prospectus, and FOSS4G has no shortage of competent geeks who can do most things.
  • Make sure you distinguish between the different sponsorship levels. If a sponsor pays more, then should get more. Development companies will likely want a keynote presentation slot.

One potential sponsor wrote: 

> We've been discussing sponsorships options, but can't really identify any significant
> advantages that justify the difference in price between the gold, silver and bronze
> sponsorships. Could one of you explain in more detail OUR benefits/advantages of
> chosing one of these options as opposed to an other, e.g. gold vs. silver or silver
> vs. bronze?
  • Possible Marketable benefits:
    • Guaranteed presentation slot (for Gold or above)
    • Plenary lightening talk (only if the company has something really useful to say)
    • First dibs on session chair slots (platinum get the plenary session chair slots). Sponsor can project their slide as people file in, and while doing their first introduction. Also get an opportunity to introduce yourself and your company, and maybe advertise a presentation you will be giving later.
    • Logo on website and in conference book (for all sponsors)
    • Access to list of attendees (without emails) to all delegates
    • Access to all delegates who tick "allow my email details to be shared with sponsors" box on registration form. Silver sponsor and above.
  • We used a password protected Google Docs speadsheet to manage the list of potential sponsors. This worked particularly well and I encourage others to do the same. Our doc was at: http://spreadsheets.google.com/ccc?key=0Al9zh8DjmU_RcHU5MDE0Z3lienJjZnpFU05lLW9rUWc&hl=en_GB (Talk to Cameron Shorter if you want access to it).
  • As host/funder/coordinator of the event, treat OSGeo similar to a primary sponsor - due to all rights, privileges and opportunities that other sponsors receive. This does not mean calling OSGeo a sponsor, but remembering to make sure logos are well represented and that booth space, keynotes, and other promotional benefits are included. Liaison with OSGeo Marketing or directly with Tyler or the Board.

Contra deals

We set up contra deals with the Australian Computer Society (ACS) and the Spatial Sciences Institute (SSI), offering a 5% discount and Professional Training points with ACS/SSI to members and ACS/SSI got to share a stand at the conference. In return we received a mention in ACS/SSI email blasts. Afterwards, we hardly got any members make use of this discount. I can guess at the reasons for this:

  • For the ACS, I don't think anyone asked for a discount. The ACS did mention the FOSS4G conference in their communicaiton, but I have my doubts that it attracted any delegates. The ACS was probably not a targeted enough audience, and our conference mention was only a few lines mixed in a mass of material, making it an email blast which doesn't get read by most people.
  • There were maybe 3 SSI members who claimed the SSI discount, and I think all these people were actively involved in the organising of the conference to some extent, and heard about the discount that way.
  • For the SSI, I did see a number of people at the conference who I knew were members of SSI, who had not taken advantage of the 5% discount. It is quite likely they heard about the conference through a SSI press release, but when they went to register (months later) they had forgotten about the discount. Of note, we didn't have a section on the registration website explaining how to use the 5% discount, people would have need to have remembered from the original SSI/ACS email blast.
  • Also of note, the SSI was going through management upheaval while we were dealing with them, with 3 people rotating through the Chief Executive role in the 6 months we were dealing with them. Consequently SSI as an organisation was not running at 100%.

Recommendations:

  • Continue making prudent use of contra deals with targeted organisations. Providing a 5% discount for members provides a cheap marketing technique and will only be used if the marketing works.
  • Ensure that marketing is bigger than a one liner in a list of other conferences. You are looking for a feature article in a newsletter about "GeoSpatial Open Source and FOSS4G" or similar. Also banner add on website would be good.
  • Where possible, tie conference benefits (especially ones that cost the conference like a stand) to the contra deal sponsor. Ie, if the sponsor is able to attract X delegates, they will get a free stand at the conference.
  • Try to collect better metrics about the success of contra deals for use with future conferences.

Venue booking & Conference dates

  • During proposal development, the bid team selected two venues for the conference:
    • The University of NSW
      • Pro: Has accademic ties
      • Pro: Has cheap university accommodation for 500 near by (share bathrooms)
      • Pro: 10 mins bus to beach
      • Pro: Cheaper, by ~ $50/delegate
      • Con: High end accommodation is 20 mins by bus (in city)
      • Con: Would need to bus delegates to the city harbour for an impressive dinner
    • Sydney Convention and Exhibition Center
      • Pro: Professional, classy center
      • Pro: Right on harbor, so easy to ship delegates to dinner location is style
      • Pro: Wide range of accommodation near by.
  • We postponed venue selection till after we won the bid, and consequently SCEC did not hold our preferred date for us.
  • Despite the initial analysis of the dates to be avoided (e.g. due to conflict with cultural or religious holidays, other conferences, etc.), As of early September 2008 we had still not booked a venue and it appeared that the Sydney Convention and Exhibition Center (SCEC) was only available on dates that overlapped with the USA thanksgiving weekend (which is in late November). We were able to salvage the situation by booking the SCEC for dates in October rather than November, however the availability was limited, and restricted our options.

ALBERT Kelly wrote: 

> Hey guys,
>
>     I know I've mentioned that the end of September is a killer time to get US Gov't
> people to come to a conference because their Funding year ends on 30 Sep.  So, thank you for not
> putting the conference on the last week of Sep!!!


Lessons:

  • Ensure that an early decision is made regarding the Venue, and the dates. If a venue can be booked for 'the entire week', the fine tuning of the actual days and rooms required can be done later, but being able to know 'the week' allows for marketing of the event, such as at the prior year's FOSS4G conference.
  • In terms of communication the critical nature of the date should have been better communicated by the Organising Committee to the PCO.
  • When considering cost/delegate, be mindful that international delegates will likely be paying thousands of dollars on travel, accommodation and lost income. $50 price difference in the conference will not effect them much. (It will effect local delegates more).
  • Pick a date that doesn't conflict with national holidays of key markets.
  • Find out when related national and international conferences are being held and make sure you don't clash. FOSS4G 2008 was on at the same time as Europe's biggest Geospatial fair, Intergeo. Here are this list of conferences we watched for 2009: FOSS4G_2009_Marketing_Plan#Related_Conferences.
  • Be aware that PCOs can reduce costs substantially by adjusting the number of rooms used, or using rooms off site for workshops or code sprints.
  • Some venues may have higher public liability insurance requirements than others - this will affect exhibitors requiring insurance and potentially require a substantial increase in exhibitors costs if they do not already have massive coverage (e.g. one quote in 2009 was for around $700 for the 4 day show) and increases the barrier for attracting exhibitors. It was also a bit of a surprise for at least one exhibitor - and should be clear up front or at least as a warning.
    • 2009 event exhibitors, at the SCEC venue, required proof of $10 million public liability coverage to be allowed to exhibit. A 3rd party company was referred to for exhibitors that needed help but a tighter relationship would have helped earlier on, especially since many exhibitors are 'small'. (Tyler looked into getting coverage from several Canadian brokers and was unable to do so for that high of coverage.)

Facilities

OSGeo attendees want access to local facilities and these should be researched before hand, and details provided on the website.

For some things, like printing and CD burning, it helps to set up an account with a trusted local source (as was done for FOSS4G 2008). See FOSS4G_2008_Media_Facilities.

Attendees want:

  • CD/DVD printing
  • Paper printing (for workshops)
  • hire of general IT services, computers, projectors, etc.
  • An address to ship materials/equipment to ahead of time.

Internet

  • Internet was one of our success stories, and one that we were worried about after hearing lessons from the last two years where delegates overloaded the wireless internet.
  • AARNET, the internet provider for Australian Academic institutions provided very fat internet pipe into the Conference Centre for free (as we were an Open Source conference).
  • Steve Walsh, a Systems Administrator who also helps set up Linux Australia conferences set up the internet for us and negotiated getting the internet into both the Conference Centre and UTS for the code sprint.
  • We had a number of comments from delegates who were very impressed with the speed of the network.
  • Steve: Can you please fill in some of the technical details here.

Website

Note that some of the issues related to the website for 2009 will likely not be an issue for 2010 and beyond, because the OSGeo Conference Committee will provide the 'basic infrastructure'(e.g. DNS setup, webserver setup) for the website to the local organizing committee for 2010 and beyond. Though, a decent conference system software needs to be chosen which supports on site management of sessions (like the free Indico which was successfully used for www.foss4g2006.org).

Lessons:

  • We have spent considerable time communicating/deciding the URL - if the format of the conference URL is not standard (i.e. http://20xx.foss4g/) then make a decision early.
  • If a PCO is being used and they are supplying the website then liaise as early as possible with their technical contact and set out expectations on what the site should be (and not be i.e. .ASP)
  • Provide whomever is doing the website with as much reference material as possible - if they are a PCO they will not know anything about FOSS4G therefore they are at an immediate disadvantage when it comes to creating content for the website

Budget

  1. Get your budget agreed to before you sign a contract with the PCO. We found items in the budget, like accommodation for the local PCO attendees that caused us friction. It would have been better to have these sorted out before the contract was signed.
  2. Similar to above, make room to discuss/identify OSGeo administrative requirements early on. E.g. free booth space, how many full conference passes needed for OSGeo, and special venue requirements (eg meeting rooms). Few allowances were made in 2009 budget to accommodate the hosts needs (needs were not identified by OSGeo either until too late).

Economic Climate

  • We won the FOSS4G 2009 conference in a financial boom, then had to run the conference in a bust, after the Global Financial Crisis. Consequently we were faced with many of our sponsors reducing or cutting sponsorship (Eg: Google moved from Gold to Silver sponsor), and many potential attendees had to face travel spending cuts and couldn't make the conference.
    • Lesson: Don't be the bunny who has to run the conference in the same year as a Global Financial Crisis.
  • Australia holds a large bi-annual spatial conference which attracts many of the government spatial delegates who would likely also wish to attend FOSS4G. The Surveying & Spatial Sciences Institute Biennial International Conference ran 1 month before FOSS4G, and we found that a number of potential delegates only had sufficient funding to attend one of the conferences. It would have made sense to pick the alternative year to this conference. This conference
  • The WALIS Geospatial conference, held in Western Australia a month after FOSS4G also had reduced registrations, down from 830 registrations in 2008 to 650 registrations in 2009.
  • The one Australian conference winner was the Spatial@Gov conference which started for the first time in 2009, 4 months before foss4g, and attracted 463 people. This conference would have attracted a number of people from foss4g, as it had a very strong focus on OGC standards, and also had ~ 1/3 of the presentations mentioning Open Source. The Spatial@Gov conference was deliberately started in competition to the Spatially Enabled Government conference which was privately run and seen to be very expensive in comparison. As expected, the Spatially Enabled Government conference had significantly less attendees than previously, and decided not to exhibit in Australia in 2010.
  • Overall, there was an oversupply of Australian Geospatial Conferences, and combined with the Global Financial Crisis, the conference organisors were faced with reduced profits or losses. FOSS4G 2009 did well to maintain a slim profit. (A few days before the conference it looked like FOSS4G would be making a loss as well).
    • Lesson: The Australian conference organisors (from FOSS4G, WALIS, Spatial@Gov, SSSI, CRCSI) have agreed in principle to work collaboratively to avoid oversupplying the Australian market with conferences. In particular, their is an aim to avoid covering the same material in multiple conferences, thus splitting sponsorship dollars and attendees.

Marketing

Target money

  • Sponsors want to know that they will make money by sponsoring the conference. Source speakers from big spending programs to talk. These will attract delegates interested in those programs and sponsors who want to get work from these programs.
  • Feedback we got from sponsors was "We thought FOSS4G was just going to be a techie conference and wouldn't lead to sales". You need to push the Business side of FOSS4G too. Push Business Case Studies, Integration into Spatial Data Infrastructure, Spatial Government, etc.

Press Releases

See our press releases at: FOSS4G_2009_Press_Releases, also FOSS4G_2009_Press_Release_Process.

Keep press releases concise. The more that is written, the less it is read. Our early press releases were too long and feedback was that people were not reading to the end of it. Keep the long winded explanation to the website.

Press release pipeline

On advise from 2007, as per FOSS4G2007_Lessons_Learned#Use_Proxies, we built up a press release pipeline, making heavy use of Community Leaders to forward the FOSS4G press release, with a paragraph or two introduction, to their communities. Reason for using community leaders is that emails are much more likely to be read if it comes from someone you know and trust. This proved to be very effective, with Google Analytics showing that referals to our website came from a very large area from community leaders.

We built a spreadsheet of community leaders, including name, email address, and email list or publication they were a leader in. The list can be accessed by Cameron Shorter or Tyler Michel from here: http://spreadsheets.google.com/ccc?key=pu9014gybzrd1M6FqyOzGWg&hl=en_GB . Talk to either of them if you need access for future FOSS4G conferences.

  1. Lesson: Build this list early.
  2. Lesson: Ask community leaders to CC you on emails they send out, so that you get feedback on which communities are being reached, and whether you need to find a new leader for a particular area. Assign someone to follow up to determine if the emails are going out.
  3. Lesson: Ask community leaders to add a personal message (see example cover emails from the Press Releases).
  4. Lesson: Select a schedule for press releases a publish it before hand. This helps magazines and Linked In owners to plan their releases to help you.
  5. Lesson: Don't send press releases just before a public holiday. We sent a release two days before Easter, and found many respondents were on leave. When they return, they will have a pile of email to attend to and your press release will likely be deleted.

Cameron sent most of the press releases from his personal email address. Afterwards, he found that he had been included in some people's junk email filters.

  1. Lesson: set up a separate email address for foss4g related bulk emails

Email Lists

We obtained a spam list of foss4g potential delegates from previous events, which we added to with a number of local lists we found. This was copied into foss4g-2009-announce email list. In retrospect, we should have had two lists, one spam list for potential delegates that you only want to hit with major announcements to encourage the people to register. And then a second announcement list that people self subscribe to which you can email more regularly with gossip, buzz, and ideas for how people can further get involved in foss4g.

We also had: foss4g-2009-private, for discussing sensitive (financial) matters amongst the organising committee, and foss4g-2009 for all other organisational stuff.

Translations

We had community volunteers translate the website and press releases. The theory is that local translations will reach into local communities and demonstrates the international roots of the conference. Examples: http://2009.foss4g.org and FOSS4G 2009 Press Release 7 Translations. A list of translators is also available at: http://spreadsheets.google.com/ccc?key=pu9014gybzrd1M6FqyOzGWg&hl=en_GB

Tutorials

  • See FOSS4G2008 Lessons Learned#Laptop_Based_Workshops
  • Many tutorials were overbooked, with people spilling out the door outside the room. (I wonder whether this was because tutorials were free, but contained much of the same content as workshops).
  • We had water jugs and glasses on the table. With a crowded room, people were nervous taking their computers out when there is water on the desk.
  • One of the tutorials was run from a Virtual Machine. Unfortunately, 1/3 of the computers in the room didn't have enough RAM to run the virtual machine.

Workshops

Submissions

  • Provide a range of options for user level (Beginner, Intermediate and Advanced) and category (User, Developer) and provide strict definitions of what these terms mean. Use examples.
  • Read previous FOSS4G2007_Lessons_Learned#Format_of_the_Call lessons learned so you don't have to learn all this yourself.
  • Having people fill out document templates and submit worked, but was a pain to juggle. A web form would be much easier, would eliminate some of the stylistic issues that I will need to sort out before getting things into the program and can enforce the word limits and the use of the correct template.
  • 100 words may be enough for a single instructor biography, but it's entirely insufficient when there are several. We had one submission that hit 500 for three instructors, and it would have been great to print that.
  • We put word limits on everything that would be published, and some things that wouldn't (such as Instructor Experience that was only used for assessment). We should have indicated explicitly what was for publication and what was strictly evaluation. No word limits need to be imposed on the evaluation only, but then you'll have to read it.
  • Having a separate submission path for tutorials than workshops allowed specific information to be captured for each. It likely cost us tutorial submissions where simply having a Workshop, Tutorial, Both selection would have made it trivial to submit both.
  • A number of people didn't realise there were templates for submitting workshop and tutorial details. The web form would solve this, and I don't really know how to make it clearer within the OCS system. Ideally a submission wouldn't be able to move further until a document was uploaded. Two submissions failed due to not submitting the doc.
  • Review the submissions early. I saved a couple of people by pointing out that the files they uploaded were not the correct templates, or they hadn't provided anything at all.
  • Review often too. In the final week, when most submissions arrived, I reviewed as soon as I received notice of a submission. Then I could get after them while they still had it on their minds.

There's a hard lesson I've learned, and I'm still not sure how it should be handled differently. We have a tradition of open selection of stuff. Workshops have always been less open, but we still involve community input. What I've found this year is that the only people offering this input were those with workshops or tutorials in. This means that the more people in your org that volunteer to review the higher your chance of getting in. To some extent this is fine. I think at worst we had three from one org, out of eleven, and one didn't complete his input. But in the end we lost some great presentations because they weren't there pushing for them. One in particular fit with the goals of the conference perfectly but wasn't selected because of the advanced content. Somebody else got their advanced content in instead, though I don't recall who. It was part of the recommendation to weight for beginner themes.

If I were to do this again, I think I might try the following. First, I wouldn't submit anything myself. I did have concerns over perceived conflict of interest, which was one big reason I pushed for the community selection. Second, I would refine the selection criteria much more than I did this year. Make sure it made it into the press release, was published on the wiki and on the submission form. I would then perform the selection myself. IIRC, the original reason for community involvement in the selection was not to be inclusive, warm and fuzzy, it's because it's a hell of a lot of work. Workshops are doable by a single person, especially once the selection criteria are explicit. Frankly, those that are interested in helping with this sort of work are generally not our target audience anyway. Presentations are different. They're closer to the event for one. We're more organised by then. And there's simply too many for one person, or even a small group, to handle in isolation with any kind of efficiency. I wouldn't expect this to go well with the community. It defies convention. In my case at least, simply not submitting my own workshop wouldn't really eliminate the spectre of conflict as others in my org had submissions in. I'm not completely convinced this is the correct solution, but it's what I've come up with.

Setup

  • Get lists of software needed by presenters early. I started asking two weeks before I needed to set them up, and everyone managed to work out dependencies among themselves quite well, but I would have loved to have time to do a test install to eliminate collisions in the registry.
  • Make sure you get access to machines the day before workshops. That day was attended by all but two workshop presenters (those presenting using live dvds) and solved many problems.
  • Getting things printed was not difficult, but half the workshops chose not to provide printed material. This makes alot of sense, provided materials can be provided for download. Having a handful of cd's to hand out would have gone a long way as well.

General

  • Of 401 conference delegates we had 188 workshop registrations; more workshops would have been appropriate.
  • One bit of feedback I heard a lot of during the conference is that people would like to have been able to attend more workshops.
  • Our market is fairly immature, but more workshops over more days would have gone over very well.

WMS Shootout

The WMS Shootout is a presentation comparing different WMS (and WFS?) implementations.

  • It was proposed as a Abstract, and was ranked by the community as the most popular presentation, and so was moved to the closing plenary session (in front of everyone, instead of within one of the steams).
  • While the Shootout was mentioned in early marketing, hoping that it would indeed be presented again in 2009, it would have been better to plan for the Shootout much earlier. Ideally this should become a permanent fixture of FOSS4G events, with a carry over of experience from year to year. This will allow it to be included more prominently in early FOSS4G marketing material as a FOSS4G drawcard. It can also be slotted into the program right from the start.

Abstract Selection

  • Make it a criteria of Abstract Submission that submitters accept a license to have their slides from the presentation, and a video of their presentation made available via Creative Commons. (It is messy to have to collect this afterwards).
  • The Abstract submission form supported only one presenter, but sometimes there's more than one presenter. Make it possible to submit detailed information about several authors.
  • Save the date when presentation was submitted. (It is useful to see when abstracts are being submitted.)
  • It would have been useful to profile reviewers, so that we could weight reviewers against expected attendees. In particular, I would have liked to collect:
  1. Geographic Location. (Country). Make sure the Country names is a pull down list which is the same as for registrations.
  2. Sector: Development, Academic, Government, Utilities, Private, other
  3. Position: Developer, User, Manager, CIO, Decision Maker
  • It would have been useful to have a "Comments" field for reviewers to add comments as to why someone was or was not reviewed high/low.
  • In reviewing abstracts from our community, some abstracts received 40 votes for just their abstract. This may have been encouraged by our press release, which encouraged abstracts authors to get their friends to vote for their abstracts. FOSS4G 2009 Press Release 17. Lesson is that we should encourage people to promote the conference, but not vote for just one abstract. We should also check the votes to verify people are not rigging the voting.
  • Having the community rank the abstracts was very successful. We did not get anyone challenging our selection choice, which was an issue in previous years. It also made it much easier for the abstract selection committee, as we had so many good abstracts to choose from.
  • Abstracts submission form should collect:
    • Title
    • Authors (multiple, some presentations had up to 3 presenters)
    • Abstract
    • Affiliation (company that authors work for. We aimed to have a spread of organisations represented)
    • email address (you will want to contact presenters afterwards)
    • Country (you may wish to have some balance of presentations across countries)
    • Tags (usefull for public voting, especially for 2010 where a huge number of presentations is expected. People could more easily vote on topics they care about)
    • Submission date (track the date automatically, it's always interesting afterwards when the people actually submitted their abstracts)
    • Accept that presentation material to be published unter CC (probably CC-BY or CC-BY-SA) (Add a checkbox that the presentation material (and possibly recordings) will be published under Creative Commons. Hunting for the permission afterwards is messy)

Recommendations to Abstract Authors

  • The following advice should be provided to abstract authors
    • Mention key themes of the conference and how your abstract is addressing them. Some 2009 abstracts did not mention Open Source or Open Standards.
    • Describing "vapour-ware", an idea that you would like to implement is not very compelling. Presentations should focus on specific technologies that already exist, or how you have used these technologies.
    • If presenting case studies, make sure you include "the positives and negatives encountered in your approach".
    • Be specific about what you will be talking about. "I will be talking about how Open Source can be deployed on Proprietary" is not enough for a reviewer to determine what will be talked about.

Comparison presentations

Delegates who voted for the FOSS4G 2009 presentations ranked the OSGeo comparison projects very highly, which is something I suggest presenters take note of, because competition for speaking slots is fierce.

At FOSS4G 2009, 183 quality presentations were submitted, and there was only 85 speaking slots. In 2010 it is likely to be much harder to be selected to present, as there is expected to be 2 to 3 times more delegates and many more hopeful presenters.

In 2009 the community ranked potential presentations, and some of the highest ranked presentations compared popular packages. Unfortunately, there were only a few of these types of presentations.

The presentations were:

  • Ranked 2: The WMS Performance Shootout
  • Ranked 8: PostGIS and Oracle Spatial
  • Ranked 9: There is no alternative to Openlayers...? (discussing OpenLayers vs other AJAX clients)

The moral to the story is that delegates want to see how different projects compare, and to date we have had a shortage of such presentations (partly because they are a lot of work to set up).

However, I strongly suggest that projects start teaming together to put together such presentations for 2010.

In particular, I'd love to see comparisons between:

  • Geospatial Desktop applications
  • Geospatial Browser based applications
  • Geospatial Servers (WMS, WFS, Tiled Services at the very least)

The comparisons could cover some or all of:

  • performance
  • robustness
  • features
  • ease of setup or use

The tests should not be restricted to Open Source, but be open to proprietary vendors too. (ESRI and ERDAS were invited to participate in the 2009 WMS shootout, and it seems likely they will participate in 2010).

Schedule

  • Make sure you have backup presenters. We had (Harley to confirm) over 10 speakers drop out before the conference.
  • Make sure you have back up presenters for keynotes and lightening talks. (These will likely be one of your other presenters).
  • Tell each presenter what time they are presenting. Through mis-communication one of our keynotes got the day wrong, and we had to do last minute juggling to the program to fit him in.
  • Make sure all speakers, tutorial presenters and workshop presenters have registered for the conference. We discovered at the last minute that some of the tutorial presenters were not registered.
  • When collecting personal details from presenters, ensure to collect an email address or similar which can be linked back to the registration list so you can cross check registrations. We had to do this manually, which was difficult.
  • One (Government Manager) wished to see an overview presentation at the start of the conference, so that he could decide which presentations should be viewed through the rest of the conference. This could be a very compelling, plenary presentation: "FOSS4G themes in a nutshell".

Birds of a Feather

  • We had one official "Birds of a Feather" session on Thursday afternoon. We had a wiki page for people to sign up for the Birds of a Feather before hand, but this wasn't used much. FOSS4G 2009 BirdsOfAFeather
  • We also had sign up sheets at the OSGeo stand, and that was used. We had many people wanting to go to a number of the sessions, and a couple of sessions were moved to different timeslots.
  • The description "Birds of a Feather" was not understood by many people and they needed to have the term explained to them. This is an issue for people looking at the program before hand and wanting to determine whether they should come to the session or not. Maybe use "Interest Groups" instead.
  • I, Cameron Shorter, organised 5 meetings of like minded people over dinner, breakfast and during the code sprint. (Meetings around Defence, Water, SDI implementers, GeoSpatial Businesses, OSGeo Marketing). I had the advantage of having access to the registration list, and hence could invite people individually. Even so, my skim over the lists was rushed and I'm sure I missed half the people who should have been at these gatherings. These meetings were very successful, with almost everyone invited attending, and I had many thank me for inviting them and noting that they found the meetings very valuable. So lessons for next year:
    • Provide a list of local restaurants beforehand, and invite delegates to set up "Interest Group" meetings at these restaurants for breakfast and dinner during the conference.
    • Someone with access to the delegate list should go through and email delegates individually and suggest meetings they may be interested in. (I used email domain names and my personal knowledge of delegate affiliations to identify likely interest). Someone also suggested that we could do some smart analysis of how people vote for abstracts. Alternatively, we could ask delegates to tick areas of interest when the register.
    • Note that the size of the group effects its effectiveness. A group of 8 allows people to talk with each other. If you have a group of 20, then you will want to give people a chance to move around. (For a dinner group of 25, we had people mingle while having drinks before dinner, then invited delegates to change seats between dinner and desert).
    • Jeff McKenna made a good point that these meetings should not be open:
"These 'invite only' meetings by the LOC at FOSS4G2009 left many of us who were not invited to meetings like 'GeoSpatial Businesses' (including myself and others that I know) feel that we were unwanted, after traveling across the world and spending so much money to be there. These meetings are a good idea, but they must be open to everyone to attend."

Installfest

Tools

Google Analytics

We are successfully using google analytics to monitor the foss4g website traffic. Using the geographic breakup of the traffic we can understand which regions of the world require more aggressive marketing. Anyone can view the metrics at http://www.google.com/analytics/ user: foss4g2 password: foss4g2009

The master account is: foss4g@gmail.com. The organising committee know the password.

On 1st of March we had been using Google Analytics for about 2 weeks during which period only 2 hits to the site were from China so we ramped up marketing in Asian marketing. As a consequence, we doubled the number of Asian delegates at FOSS4G this year over last year.

Google Docs

Google docs proved to be quite successful for collaborative editing of documents and for creating draft conference time tables

Delegate Feedback

Delegate Profile

This spreadsheet provides breakdown of registrations for 2007, 2008, 2009 based on:

  • Registration Date
  • Geographic Location
  • Job Profile
  • Reason for attending

http://spreadsheets.google.com/ccc?key=0Al9zh8DjmU_RdEZoOUtSeVZRVWtKQzV6R2N5ekdSdlE&hl=en_GB#

Some of these metrics were discussed in the 2009 Chair opening speech: http://2009.foss4g.org/speakers/#Cameron_Shorter

Retrieved from "http://wiki.osgeo.org/w/index.php?title=FOSS4G_2009_Lessons_Learned&oldid=81724"