Blog

Theme of the week for me has been "free software".

It started from a strange source - reading about the judgement in the BSkyB versus EDS law case. Briefly, BSkyB hired EDS in 2000 to build a customer relationship management (CRM) system for two call centres in Scotland. The project was worth £48m, and EDS gave assurances that the system could go live within nine months and be completed within 18 months. However, by 2002 BSkyB had taken the development back in-house (it then spent  £265m on the project) and in 2004 sued for damages. It took years but they won - EDS are guilty of "fraudulent misrepresentation giving rise to damages" estimated at £200m. As you'd expect there were arguments from both sides. EDS argued that BSkyB had been vague about what it wanted. Legal commentators seem to agree that it finally came down to the (lack of) credibility of the EDS principal witness, and that's why they lost their case.

But what seems not to bother anyone is the overall cost of the project. I'm guessing there was more to this CRM than the average Saleforce.com project, and I used to work on call distributions systems in my Telecoms days so I know what these can cost, but a budget of £48 million pounds? And then the cost of £265 million to do it in-house? Amazingly high.

Sometimes when you see coverage of open source technology by certain websites or in analyst reports there's a nudge-nudge factor this isn't really proper grown-up technology. Free software - you get what you pay for - is their implication.

But if this is a glimpse into the world of proprietary Enterprise software I think we need to hope that things have changed since 2002.

It puts the arguments between definitions of freeware, free software and open source software into perspective. The arguments between advocates of "free beer" and "free as in freedom" can be fascinating, but pragmatism says free/open source software is really more about not being ripped off. Not being ripped off by the project costs; by the false promises of a vendor's sales team; by the inflexible terms of a license agreeement; and by inability not to to be able to change the software if you want.

There's a common thread between community projects, companies who offer free or freemium product, commercial open source vendors and free software projects. It is transparency, good value-for-money and respect for the long-term relationship with a customer.

Government is known for the same car-crash examples of ICT projects as the above. The UK government came out this week waving a large open source banner, but achivements included the example that "over 25% of secondary schools use the Linux operating system on at least one computer".  Not good enough.

An interesting survey arrived in my inbox from Cobalt Corporate Finance about the latest quarterly survey of a panel of Computing magazine readers and Cobalt’s IT vendor clients. This allows for a comparison of the buyers (202 IT managers) and the vendors (80 C-level executives). They specifically looked at attitudes to Business Intelligence, Cloud computing, Data Security, Green IT, Mobile Computing, PC/Windows Upgrade, Social Networking, Software as a Service, Unified Communications and Virtualisation.

The headline is that responses are all more positive than last quarter, but IT vendors remain more optimistic than IT buyers. The article is found here.

There are two ways to look at their results. The first is which IT technologies are in the "here and now" - in use or under evaluation; and which are further out - 12 months before adoption. This would indicate that Data Security, Mobile Computing, Virtualisation and PC/Windows Upgrade are most prominent in buyers' thinking. On the other hand, Software as a Service, Social Networking and Cloud computing are 6-12 months out in their plans.

The other way to look at the results is to measure the disconnect between buyer and vendor attitudes. This gives an indication of which technologies are at their peak in the hype cycle. The biggest disconnect between vendor optimism and buyer caution came in Software as a Service. On the other hand, buyers are more interested in Green IT issues than vendors seem to think.

The chart tells the story:

CMS Watch is a great site for learning about document management, web content management, enterprise content management, enterprise portals, web analytics, and enterprise search solutions. It's mandatory reading for those of us making products, and definitely worth the time of any buyer who needs to select a product in this area.

This week they published their predictions for what is likely to happen in 2010. They were also brave and smart enough to assess how well their 2009 predictions fared.

Selectively looking at some of their 2009 outcomes, they probably got it right that Open Source ECM made advances and that social computing diffused into the Enterprise. I think they got it more wrong than they admit on SharePoint being derailed by Office 14  - the interest continued unabated and the beta of SharePoint 2010 did it no harm either.

They predicted that SaaS vendors would expand offerings. There was plenty of activity in the SaaS sector but many buyers are still unconvinced about putting company documents on a third party server. A term of service from a SaaS provider looked at recently is not uncommon: "Once you cancel or terminate your registration with us, we will instantly delete data, content, text, documents, images and information from the service. After the cancellation of the service, all of your content will be lost for ever." Data lock-in as a variant on vendor lock-in, and just as dangerous. 

For 2010, CMS Watch makes some predictions that we can compare and assess in regard to CogniDox.

For example, "Enterprise Content Management and Document Management will go their separate ways" (#1) gets our agreement. There is a tension between providing good workflow tools for document management and the tools used for website publishing. Clearly they need to be compatible and work in unision at some point but doing both in one application isn't necessarily the best idea. Given that prediction, their "Document Services will become an integrated part of ECM" (#8) may seem to be a contradiction. Ignoring that, we'd agree that helping users to automate the production of documents will be helpful and important. We tend to describe this as "document assembly" which I think is a more specific and useful term for e.g. creating a new legal document using metadata to populate key fields.

We'd also agree that "Faceted search will pervade enterprise applications" (#2). They mention Lucene/Solr, which we support in CogniDox 8.0 onwards, but we'd also mention the Xapian open source search engine library and the Flax Search Service as a technology to watch. CMS Watch only mentions SharePoint in the context of "Digital Asset Management vendors will focus on SharePoint integration over geographic expansion" (#3) which may be overly specific - most ECM and WCM companies will consider offering a SharePoint connector. That doesn't however imply that SharePoint is any more than a workgroup Intranet builder with file sharing capability. Buying decisions may verge on the ridiculous - why pay $$ for SharePoint user licenses and then add $$$$ for a proprietary ECM add-on? But SharePoint 2010 will be a force, and we can anticipate a rush on products that see themselves as SharePoint 'killers'.

One thing that correlates with ECM suites and SharePoint is that they can bring hidden costs in hardware / server requirements and the IT admin effort inherent in their client/server architectures. For that reason we'd agree that "Enterprises will lead thick client backlash" (#6) and to a lesser extent that "Cloud alternatives will become pervasive" (#7). Some of the same issues faced in 2008/9 for SaaS still remain.

We'd strongly agree that "Gadgets and Widgets will sweep the Portal world" (#9). People have become accustomed to seeing them on the public web at sites like iGoogle and they will become the definitive user interface for the Intranet. The only question is what widgets are the most essential?

The prediction that "Mobile will come of age for Document Management and Enterprise Search" (#4) depends on what is meant by "coming of age". It will certainly be the case that this will grow from the current small base, but we think this is one for 2011 instead.

That leaves 4 other predictions we have not commented on, and so a quick visit to CMS Watch to read these for yourself is recommended.

We recently released CogniDox 8.1 and amongst the new features was a CogniDox Word Add-in. 

An Add-in is a software component that adds custom commands and new features to a primary program such as those in the Microsoft Office suite. The particular value of the CogniDox Word Add-in is that you can browse and issue commands to the CogniDox repository while you are using Word.

The first elementary fact we faced is that the Office suite is a collection of individual programs and we had to choose which one we wanted to extend. We've blogged recently on the ongoing ubiquity of Microsoft Word as the principal tool for knowledge workers, so it stood out from e.g. Powerpoint and Excel as the one to go for.

Everyone knows there are multiple versions of Office in use across the market. Ideally, we'd support all of them. Unfortunately, the differences between Office 2003 and 2007 makes that two quite separate tasks rather than one. It isn't easy to find out what share of users are using Office 2007 compared to older versions - there's a stat from Forrester that  roughly 80% are using the latest version (2007). This seems on the high side, but then when you consider that new PCs will be shipped with the latest version and that 80% of Microsoft's Business Division revenue comes from Office B2B sales, perhaps it isn't so far out. I have to say we're still not fully convinced though.

So we choose Word 2007. Worst case scenario, everyone plans to upgrade to it and our work is re-usable for Office 2010. Having to support 2003 would have eaten into development time for a product that will become less relevant to our user base.

The next issue was how to tool ourselves for the task. MSDN tools have been prohibitively expensive. Luckily, a year ago Microsoft launched a program for new start-ups that would allow them access to MSDN on a very reasonable basis. You need to satisfy certain start-up criteria - in business for less than 3 years with under $1M in revenue for example, and you have to be nominated by a Network Partner (often a VC or a BA group). But that gets you participation for up to three years and access to  Visual Studio, Windows Server, SQL Server, SharePoint, MSDN, Microsoft Office and more.

We joined BizSpark in mid 2009 through the assistance of our local friendly and capable Business Leaders Network (BLN). With the help of their registration code it was really simple to do.

Once we had access to all these development tools we had to decide which ones to use. We went for Visual Studio 2008 using C#. There's a strong argument to do Office development in VisualBasic.NET rather than C#, because a lot of the Office Interoperability API calls use optional parameters. This is not supported by C# 3.0. As a result, you tend to wind up with fairly verbose code. MS has a KB article about this. Visual Studio 2010 will bring in support for optional and named parameters, which will make working with the Office Interop APIs much more pleasant. As the Add-in is a relatively small project; we prefer C# much more than VB and VS 2010 will bring improvements, therefore we went C#.

At the protocol level, our interactions with the Add-in are via SOAP. CogniDox already had a SOAP interface used by our Linux command line client, so we were extending known functionality to provide a richer interface for the add-in. The benefit is we can reuse the SOAP API to do other integrations. CogniDox publishes its SOAP API using a Web Services Description Language (WSDL) file, and all it took to expose the API to the C# project was to point Visual Studio at the WSDL file URL.

This highlights the fact that Open Data formats can be as important as Open Source.

At the UI level we had to work with the ribbon UI and a custom task pane which are standard UI elements within Office 2007. One decision was between using the WPF (Windows Presentation Foundation) or WinForms for the UI controls. WPF is relatively new and set to be the future of of Windows UI development, but we went the WinForms route because it gave us access to more mature documentation that sped up development time. We may re-visit this decision with future releases of the Add-in. Our priority for the initial release was to explore where we could go with the Add-in and get some real user benefit out in the field.

So, at least one LAMP shop gets to develop for MS Windows. Without the existance of the Microsoft Bizspark program, it's highly unlikely that we would have chosen to do that or be able to fund it.

I've been using the term "knowledge workers" frequently in recent posts, so maybe it's overdue a definition. Here's a recent quote from McKinsey analysts that I find useful:

"The heart of what knowledge workers do on the job is collaborate, which in the broadest terms means they interact to solve problems, serve customers, engage with partners, and nurture new ideas." -- McKinsey report, October 2009

CogniDox is used by companies that make high-tech products - semiconductors, electronics and similar - and so it’s clear that the average user in these companies fits well with this definition.

Over the year, we’ve taken a high level view over an amalgam of many companies that are storing files in a CogniDox repository to see what tools they use when performing their knowledge worker tasks. It’s not a rigorous scientific study by any means, but the results do seem consistent.

What we found is that Microsoft Office Word is still the tool of choice for capturing “what’s important” for these product design companies. For companies with many 10s of 1000s of documents in the repository, Word files were over half of the total stored (56%). The other format that is clearly important is PDF. CogniDox automatically generates PDFs from file formats such as Word and PowerPoint, but even after allowing for these ‘duplicates’ we still saw that PDFs make up over a quarter of the total (26%).

There are pockets of OpenOffice in use, especially among the engineering teams in our sample, but this would be consistent with the market share estimates of OpenOffice.org i.e. 10-20%. In any event, the main application is Writer and it is being used as a straight substitute for Word to serve the same purpose in documentation.

Other Microsoft Office applications came in as follows: Excel (6%), PowerPoint (4%), Project (1%) and Visio (1%). The rest were typically the outputs of specialist teams such as software (zips, tar files, etc) and technical authoring (XML).

Of course quantity isn’t directly correlated with importance. One of those Visio diagrams or Project plans may have taken far more effort and be considered more vital than a bunch of Word files.

This also isn’t a measure of software application usage – I’d expect email clients (Outlook, Thunderbird) and Browsers (IE, Firefox, etc) to figure large in that. This has more to do with the intersection between applications used and file storage.

Note this does not capture the knowledge worker's other modes of collaboration - surveys show the telephone and face-to-face meetings are still the preferred means of collaboration. People love their meetings. I've quoted two other surveys in previous posts that tell us the average time spent on meeting is 1hr 30mins per day, but if you are a Product Manager you could be attending up to 15 meetings per week - at least 3 hours per day of their time.

When meetings are not possible, e-mail and attachments fill the gap across the boundaries of time and location. However, the knowledge workers we analysed would possess in-boxes containing thousands of valuable content files as attachments, if email was the only option.

There wasn’t much evidence of the repository being used for multimedia files – no large image or video libraries. Probably not surprising given the nature of the enterprises and I’d expect different from e.g. a media creative company. Pity, as there’s huge untapped potential for using short (5 min) videos to assist product development – visual bug reports being an example.

There is also potential for Enterprise 2.0 tools in collaboration – but the reality seems to be that we are not using them yet. There’s no reason why that won’t change over time as teams increasingly collaborate using Wikis, micro-blogging and other tools. There may be good reasons to use Facebook for social networking or LinkedIn for business networks, but it has yet to make a case for internal knowledge worker networking.

But it will stay true that a key part of a product developer’s responsibilities is to document the product, and keep a safe record.

And Microsoft Office Word is still their preferred way to do the former.

The Cambridge Product Management Network had a useful get-together this week to debate the question: what is product management? It was a fascinating source of insights as to how things are done elsewhere. There was a range of job titles present and roles from "we have many PMs" to "I wear many hats, PM is just one role". There wasn't a consensus that the group had answered its own question, but along the way we covered the key elements. I suppose we could have referred to Wikipedia for an answer, but that isn't really the point.

It was often quick throwaway remarks that resonated most. "Product management is a team sport" was one example. NIHITO, or "nothing important happens in the office" was another.

The meeting had materials from Pragmatic Marketing, a product management training and consultancy company. As someone said, their PM Framework makes a very useful checklist from which to do a gap analysis for your organisation. Another similar company is the 280 Group. Both companies carry out annual surveys on Product Management. The most up-to-date is the 280 survey from August 2009 (the Pragmatic one for 2009 ought to appear in the next month or so). The 280 survey had 675 respondents. It seemed to cover a range of smaller to larger companies (the average revenue turnover was $114M) and different software business models (B2B, B2C, etc). Respondents opted-in and so the majority of them had a dedicated PM - in fact more than 3 PMs was the majority in nearly 60% of replies.

My chief interest in these surveys? To answer two questions: (1) how busy are these PMs and (2) what tools do they use to make themselves more productive.

The answer to (1) isn't very surprising - over a third (36%) look after 5 or more products and the average is over 3 products. That begs the question "what makes a product" and the short answer is that it is anything that requires a design trail (requirements, design, test) and an explicit release to users. In the vast majority of cases, that will pull in questions about product pricing, go-to-market strategy and product support, amongst other things.

The majority of them work long hours (>50 hours/wk) but much of their time at work goes on internal meetings. Over half (55%) go to more than 15 meetings per week (that would correspond to 2 working days per week just sitting in the meeting, let alone prep and action followup time). Over a third (35%) go to more than 20 meetings. There is still a mixture of waterfall and Agile methodologies used, on a roughly 60:40 split in favour of non-Agile. The typical number of software releases per year that the PM has to manage is 4, but it tends to be lower (2 is the mode) rather than higher.

The answer to (2) wasn't very promising for specialist software tool vendors. The vast majority of PMs use Microsoft Office (Excel and Word) to capture and manage product requirements. Some are using Wikis. There hasn't been a lot of investment in tools - 80% hadn't bought any software. Very few of those that had bought were highly satisfied with the benefits. Of those that had not, there was a fairly equal split between those that saw no need and those that would like tools.

What sort of tools? The top needs were seen to be tools for defect / bug tracking and requirments management. Other needs were tools for analytics reporting and customer community setup. There was also a need for better release planning support.

My gut reaction is that most of the companies at the CPM meeting were traditional B2B product companies starting to integrate social media into their marketing mix. We didn't explicitly talk about tools so I suspect but don't know that they would agree with the survey findings above. To me, it seems tools offer relatively easy ways to claw back the lost time that makes us unproductive and to reduce the extra work burden caused by the downsizing and the hiring freeze. 

There is definitely a lot of PM value in the message "get out and meet the customer" and that includes virtual encounters such as communities and customer portals. But, if we're not in control of the traditional product lifecycle, it doesn't seem likely that new social media will make it much easier. In fact, it will just add to the effort required in many cases.

Providing a solution for Product Managers is one of the reasons we build CogniDox and our users confirm to us that we have something significant to offer for managing reviews, gate process, design sync, multi-team development, change requests, release management and customer / community portals.

Despite that, the range of the PM role as revealed at meetings and surveys like this remind me that it is a multi-faceted, sometimes intangible, and evolving role; so no room for complacency.

The 2009 edition of the Open Source CMS Market Share Report was released today by the water&stone digital agency.  A free copy of the survey can be downloaded from CMSwire at http://www.cmswire.com/downloads/cms-market-share/

Ric Shreves, who has led the reporting on this and previous editions in 2007 and 2008, has developed a very thorough and clever method for analysing the market share of an open source product or project. You can't just use company financial data because the software is downloaded for free, so he has developed an arsenal of metrics ranging from number of downloads to the level of community actvity around the product. He uses these to order the products in terms of their usage and mindshare.

A CMS (it stands for Content Management System) is software used for creating Enterprise web sites and for uploading content such as news, blogs, documents; or any unstructured information content, without requiring technical knowledge of web site design. An analogy is sometimes made with the introduction of the Caxton printing press - without one you couldn't successfully enter the new printing industry. Today, you can't keep up with the creation and update of web sites without the modern equivalent - the CMS.

At the risk of offending my web designer colleagues, it can sometimes seem that every web design company out there offers it's own CMS. But the ones in this report are much more complex in nature, with a wide array of features.

The highlights are that Joomla!, Drupal and Wordpress are the most commonly used (in that order); and that there is a gulf of usage between these and the rest. Although Joomla! was the most used, it only came 5th in response to the question of how much people approved of it.

I think one problem with the report is that there is a difference in the type of company that chooses to use Wordpress rather than Joomla! or Drupal. Wordpress is easy to install and use, and it is therefore excellent for a one-person company that needs to get started quickly. Joomla! and Drupal typically need server installation skills but they do offer myriad features and add-on extensions, either free or low cost. This blog for example is produced by an extension called MyBlog from Azrul.com. The website is built using Joomla! 1.5 and the blog creation is a component like any other.

We also use Joomla! for the customer portal sites we create - CogniDox provides content from the document repository and we can add-on other components such as a customer trouble ticketing system by adding extensions.

I'm pleased to see Joomla! do so well in this report. It hasn't been getting as much press as Drupal recently, mostly because there are now companies offering Drupal support, and they have (quite rightly) promoted the tool along with their capabilities. There is still room for improvement on that front, but Joomla! is an excellent CMS.

The concept of a Knowledge Worker has been around for a long time (Drucker, 1959) but it is still a slippery term to define. Sometimes it's synonymous with Information Worker; other times it's a sub-category. It can depend on the company using the term - IBM favours one, Microsoft another. Sometimes it's reserved for a minority who work on unstructured tasks and goals which they achieve through free-form collaboration with others - not to be confused with workers who process information in structured tasks. Sometimes it's the majority, pretty much anybody who uses IT is an information worker.

And they all now work in the "clever" economy.

This slipperiness may be one reason why it's hard to define Knowledge Management applications and to understand fully surveys carried out on the habits of information workers.

There's a survey just out from Forrester that falls into that category. Intriguing and useful in part, but affected by the problem of knowing the makeup of their 2001 respondents.

For example, we learn that Email, word processing, web browsers and spreadsheets are the only applications widely used. But then we're told that while 60% use a word processing application, only 42% create documents. I can't reconcile that statistic with any of the knowledge worker environments I've worked in, so have to assume there is a difference here between information and knowledge workers. Some of us may wish it was true we didn't have to write documents, but have never got that lucky.

The survey does have an interesting graphic on different types of applications and how frequently they are used i.e. hourly, daily, weekly, monthly. Email clients (57%) and web browsers (35%) are the only applications used hourly to a significant degree. There is also an interesting age difference in the use of social networking sites: the 18-29 age group uses these sites extensively during non-work hours, but when they are at work they don't. At work, both they and the 30-43 age group only access these 13% of the time.

The reason for non-use at work may be explained by a different survey. This one, carried out by Robert Half Technology, surveyed 1400 CIOs at US firms. They asked which statement most closely described company policy on visiting social networking sites such as Facebook, MySpace and Twitter. The results were that over half (57%) replied "Prohibited completely" and a further 19% said "Permitted for Business purposes only".  So it is still the case that bigger companies (who would tend to have a CIO role in the first place) are blocking social networking sites.

The decision to block social networking sites isn't necessarily because corporates don't accept their use for collaboration among knowledge workers. It is usually security and data protection that is the cited reason. It's also possible that sites like LinkedIn might be deemed more business-use than say, Facebook, and are allowed. Or, it could be that we are in the transition phase between an old way of working and a new one.

In the meantime, I'm off to update my LinkedIn status and Tweet about this.

There was an interesting survey published just over a week ago - Axios Systems, an IT services management software vendor, commissioned interviews with 1500 IT executives in North America, Europe and Asia.

The headline was that 57% of interviewees felt their IT systems, processes and services were not delivering the value expected of them by their companies.

I was taken with two other points - 67% said that they still had no way of directly measuring the business value of their IT systems in real time, and 63% said that cost reduction would be their #1 driver over the next 12 months. 

"Let's go change what we cannot measure" would seem to be the unfortunate implication. 

However, I'm inclined to see this as an insight into the current state of mind of Enterprise IT groups. Many "go achieve more with a reduced budget" memos have been written in 2009, and the effect on morale must be significant. One problem of measuring quantifiable benefits of enterprise software is that there will be dozens (if not hundreds) of individual applications in use by a company at a given time, and knowing where value was added to the mountains of data is never an easy matter. Subjectively, one knows when an IT application has made something faster, better, easier; but it isn't always easy to see it on the top or bottom line. In this climate, it may be a better idea to put the metrics on hold and follow companies that are exploring the cost reduction promise of open source, cloud computing and virtualization technologies.

A good time to consider the cost of switching from an expensive proprietary solution is when the annual support and maintenance invoice falls due. This is often higher than the Year 1 cost of a commercial open source alternative (and support costs in subsequent years for the alternative will be substantially lower). 

I read a case study recently about a Legal firm moving from an expensive  traditional client/server document management system to open source - a quote that stood out was that it took the project team months to get management approval for the switch because "it all seemed too good to be true". Certainly good enough to overcome the prohibitive costs often involved in such a change.

But it would be a mistake to focus only on cost - the 'fit' of services offered, published APIs, plug-in modularity, feature extensibility when required, and avoidance of proprietary data format lock-in are equally salient. Open data is just as important as open source if you ever decide to change your mind about an application or vendor.

It's been one of those months where two or three thoughts or threads connect together.

First, we've been exploring tighter integration between CogniDox and Microsoft Windows Office applications. This led us to sign up for the BizSpark technology seeding program (many thanks to BLN for sponsoring our application) and to work with Microsoft technologies; if not for the first time then at least more than usual for us. Completely unconnected, of course, but in the same period Microsoft have started to release software under open source license, and have launched other programs such as WebsiteSpark to rival the dominance of the LAMP stack for web development.

Second, there's been (yet another) flurry of debate concerning the difference between free software and open source software. Eric Barroca, the CEO at one of our document management competitors (Nuxeo) wrote in his blog that he couldn't see a real difference between a free demo from a proprietary software company and the community edition of an open source product. The big claim of open source softare that it generates free sales leads is wrong - it is free trials that generate free leads. Matt Asay, VP Business Developent at another competitor (Alfresco) says that the open source software sales cycle averages 60-90 days, whereas traditional enterprise software averages 6 to 9 months.

Third, and continuing with the theme of software sales cycles, there was a disturbing expose about some of the unpleasant tricks that are used to sell enterprise software licenses. Read the article for details, but we are talking about demo vapourware, underbids followed by expensive add-ons, lock-in through high exit cost, and enforced software upgrades amongst other tricks. I have bought enterprise software in the past, and sometimes it does feel like a war with the vendors.

I read as many news articles about open source business models and trends in the enterprise software business as anyone, but am bemused when some seem to ignore common sense. Companies that have already made a major investment in Microsoft technology are going to keep looking for ways to extract value from that investment.  The vast majority of companies adopting enterprise software (such as a document management system) will consider total cost of ownership, including the non value-add costs of integration and trouble-shooting; at least as much as the license model. A commercial open source vendor with a sales team running to dozens of people is likely to behave in much the same way as a traditional proprietary software vendor, unless they have also rejected the tradition of sales targets, quotas and territories. Which they haven't...

That much seems quite obvious, yet curiously at odds with the earnest, evangelical tone of many blogs on the subject of open source enterprise software. The key differentiator for open source vendors in enterprise software is that they devote more energy to building their revenue from an ongoing relationship with their customers. It's all about mutual respect and transparency.