We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Earning Your Support Instead of Buying it: A How-to Guide to Open Source Assistance

Formal Metadata

Title
Earning Your Support Instead of Buying it: A How-to Guide to Open Source Assistance
Title of Series
Number of Parts
183
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date2015
LanguageEnglish
Producer
Production Year2015
Production PlaceSeoul, South Korea

Content Metadata

Subject Area
Genre
Abstract
More organisations are moving to use FOSS4G software to cover shrinking budgets. It is very appealing to an organization’s leaders to ditch their current proprietary software solution with the attendant saving on per user licences and ongoing maintenance costs. Obviously, if you switched to FOSS4G to get better features and scalability you should consider buying a support contract from one of the many vendors that offer them, these companies support many of the core developers directly. This way you get all the advantages of open source, prompt support and often the chance to ask for new features. However, if you (or your boss) are looking to save money then you are moving from a cash economy to a gift economy. In a gift culture you need to build up your “capital” before attempting to take too much out. For example, you’ve downloaded the software and installed it, and all looks good. Then disaster hits, you have a demo for the CIO and nothing's working; Time to hit the user list, the developer list, stack exchange. Why can’t you get an answer? Remember just because your issue is urgent to you the developers might be in the middle of a new release or adding a new feature and have more important (or fun) things to do with their time. They will notice they have never seen your name before on the list, or on Stack Exchange that you have a reputation in the single digits – thus you are a newbie. There’s no harm in that but wouldn’t it be better to have got that out of the way before your emergency. You could have built up your reputation by asking some questions earlier especially questions like “what can I do to help?” or “I found an unclear paragraph in the install instructions, how do I fix it for you?” on a mailing list. On StackExchange you can build reputation by asking good questions and by answering other people’s questions. Once you’ve banked some capital there are still good and bad ways of asking a question. Developers are busy people (the GeoTools users list has 20-30 messages a day for example) no one has time to read all of them closely. If you use a poor subject (e.g. "Help!!!!") or don’t provide a clear description of the problem (e.g. “it crashes”) then the odds of being ignored are huge. It can be tempting once you have found a helpful developer to keep emailing them directly, but this is likely to lead a polite(ish) reminder to keep to the list so that everyone can benefit or silence. This talk will show how to be a better open source citizen and get a better answer than RTFM when your project is stuck and the demo is the next day. The author will share his experience with helping users and developers on the GeoTools and GeoServer mailing lists and as a moderator on gis.stackexchange.com.