· Most customers look to the developer or company who helped them install and use Umbraco for support
· Ranges from phone to email to in-person support.
· There is a range of expectations by customers on what support means and when they should be able to call and how quick they should get a response/resolution
· It seems fairly common though that no one wants to provide 24x7 support, though everyone wants to provide great service/support to their customers who use Umbraco.
· Niels and core team do not have any desire to provide direct support to the customer, they want to provide support to the developers, freelancers, and companies using Umbraco to provide solutions.
· They do have slightly more detailed info on the Support as it's defined in the 3-Month and 12-Month license versions. The greater detail is on the #/frequency of allowable incidents. But it doesn't further define/limit incidents. Niels said they'd share that info.
· Legal verbiage kept intentionally light on the Support descriptions on the site and in agreement. Preference to keep it this.
· There is growing recognition though that as larger customers use Umbraco, as it's used for more mission-critical sites, and as it grows internationally there will be a greater and greater need to better formalize support offerings (to help sell Umbraco, win competitively against proprietary products that make that a differentiator to scare customers about Open Source)
· This support should be provided by the Umbraco dev/partner community, it's an opportunity for them
· A shared support queue model/wealth sharing on requirements will likely never work in reality. Too complicated to manage secure access to the needed code and systems of most implementations to be effective, plus it often takes some resident knowledge of the implementation. Plus many/most want to maintain the primary and singular link to their customers so they can continue to grow their business with that customer, they have the most knowledge of the systems, the needed access, and much to gain by maintaining customer satisfaction.
· What can be helpful is having available to Umbraco community members some simple tools and models to allow them to more easily offer their customers more formalized "Support Packages". This would include more narrowly defining common support related terms/limits, defining basic Service Level Agreements, putting together some simplistic legal verbiage that can be used for contracts, and having some easy pricing models and package offerings.
· These tools/models could bee published in an "open source" fashion to the community for their own use and modification under the same kind of principles we treat the code (if you modify and extend please contribute back).
· The Umbraco license/support is still in place, this is not a replacement to it. This idea is an
· Extension to it that formalizes what many of us are already doing, can helps protect you better, and hopefully helps us to sell more, compete better when needed against formal packaged products, overcome customer objections/concerns about lack of support, etc. And if you are a developer who has customers that require formal support and you do not wish to provide them with the associated SLA's they are asking for, we can have a list of those developers/partners by country that are so you can explore engaging them to assist you.
· Paul Hernacki, from Definition 6, agreed to create an initial draft of some SLA's and package/price models that they've been working on, will try to have them in a week or so.
· We should keep it simple. European legal terms/requirements are generally simpler than in the U.S. So it'd be best to have something that is more 1-4 pages worth of material along with "this is what this means" explanations.
· Some weren't sure it was needed, others thought it was greatly important. Enough for it to make sense to pull some initial drafts together and add another tool to our toolbox.
· There needs to be more info on the web site regarding support options so that customers better understand what is available.