Bright Interactive Announce “Crowd Feature” For Asset Bank
UK DAM vendor, Bright Interactive, who develop the Asset Bank system have announced a new service called Crowd Feature. This is a website that allows their users to pledge funds for new features in order to split the cost. Asset Bank also envisage Crowd Feature being used by other vendors (more about that later). There is a quote from Asset Bank director, Martin Wilson, on their blog:
“After yet another example of multiple clients asking us to develop the same feature I looked around to see if any other major software vendors enable their clients to share development costs. To my surprise none seem to, so we decided to launch our own online platform so we could provide this service to our Asset Bank clients. Crowd Feature is a SaaS website, available to any software vendor who is interested in doing the same for their clients.” [Read More]
The basic idea is that users can make a request for a given feature, offer to put up an amount of money for it and those which are sufficiently in-demand to cover the cost will get developed. The use of ‘crowd’ in the title indicates that this is inspired by various crowd funding sites like Kick Starter – which is more about creative projects than software. There are other crowd sourcing type sites which I’m sure people who read this publication on a regular basis will be familiar with. As to whether this has been used for software projects before is harder to assess. I believe open source projects, including the DAM system, ResourceSpace do use an open feature funding model, but this isn’t formally managed with dedicated websites and I would imagine the expectation is that this is going to be straightforward ‘client requires, contractor delivers’ type model.
Opinion about Crowd Feature in the den of unrepentant cynicism that is DAM News is divided. My co-contributor has dismissed it as ‘vendor fluff’ and ‘feature voting’. However, in my view, it is less clear cut, there are a mix of positives, negatives and a bunch of questions to think about. Some of the latter may present challenges to Asset Bank – but they probably knew that might happen!
On the positive, we have mentioned many times in the past that DAM vendors need to be more responsive to users and spend less time simply copying the competition because features are mentioned in RFPs from prospective customers. A crowd funding model requires users to think about features in terms of hard cash rather than a vaguer wish list of stuff they might like to be included and then subsequently probably not use very much. For Asset Bank it also gives them direct feedback as to the demand for given features so offers some opportunity for them to prioritise development resources and save costs accordingly.
I am not too sure whether Asset Bank’s competition will be so eager to use their website to allow their users to announce to Asset Bank what feature elements are missing from their product. I can see a few copying the idea and setting up their own. It might well work for any related, partner products that Asset Bank might use themselves within their wider product, however.
As has been mentioned, this is kind of feature voting which has been utilised by a number of vendors for some time now. There is the ‘ebay’ financial element where users need to bid for features which adds far more weight, but this poses some questions which I could not find answers to on the site as it stands. A more in-depth FAQ would be useful to help aid participation, but here are a few to get started:
- Specifications: as anyone who has worked at the sharp end of the software business will be well aware, one user’s idea of a given feature can diverge dramatically from another. If the requirement is very well focussed and tightly defined, you could (just about) get away with it. If the Change Request is more extensive, or harder to define, who agrees the spec? If multiple stakeholders are required to group-fund the implementation, they all need to be in complete (or close to) agreement about the nature of it, otherwise, I can foresee people dropping out and this taking the funding below the necessary threshold.
- To take an opposite problem, if there is an excess of funding, what is the process for deciding who still has to pay and who does not? You could say the first to request it have to pay, but that is de-motivating to participation. Reverse ordering might be another option, so the last people to vote have to foot the bill, but then that might stifle interest in popular features as prospective users wait and see if someone else will meet the cost. I guess it depends on how desperate for a given feature you are (and paying part as opposed to all of the cost is still going to be favourable). I don’t have all the answers to this, perhaps Asset Bank do, but they need to explain how this might work given these scenarios.
- Contribution share. Are the contributions fixed and amortised across the number of people pledging to support a given feature? So, if feature x costs y and is supported by z stakeholders, is it y/z that everyone pays? I can see some being willing to pay more, but probably not cover the whole cost themselves. I imagine this could work a bit like buying stocks and shares, so if you want a feature to stand a higher chance of getting built, you vote multiple times and pay the higher contribution. That isn’t fully explained though and Asset Bank need to clarify how this works.
- Quotes and cost estimates. This is related to the specification issue. Most end users have a fairly sketchy notion of how much features are going to cost and the software market is highly price inefficient with quotes from suppliers (even with specs) varying across massive ranges. If I were using this, I would want an indication of what I was going to be in for in terms of fees before committing.
- Copyright and IPR. Who owns these features once developed? With open source software, this model works better since the users (at least) can get at the code – even if they might have to pay for it. I am not sure of the specifics of Asset Banks’s IPR policy but if proprietary then some might not be keen on funding this themselves without directly owning it. By the same token, however, it should be noted that there will be many end users who don’t care about that point. It needs to be more explicit though.
Those are just a few questions and points, I am sure others will have more.
Overall, I think this is an interesting idea with a lot of potential, but it needs some explanation and development. If it is a marketing gimmick (or ‘fluff’ to use Naresh’s description) to get a bit of press attention then it is less compelling and I can’t see even their own existing users bothering with it too much after an initial glance. On the other hand, if it’s a long-term undertaking that they intend to develop with increased sophistication and versatility, then it might be worth paying attention to as an experimental method to try and resolve the structural issues the Digital Asset Management software market is currently afflicted by.
UPDATE: as per the comments below from Nick Vowles of Asset Bank, there is now an FAQ about Crowd Feature which covers points raised in this article. If there are other questions raised on this forum, we will pass them on to Nick and colleagues.
Share this Article:
To be honest, this confuses me. One the one hand, the notion of customers voting on what they want makes sense. But aren’t we already asking customers to pay for new features by asking them to buy the software and then asking for their software maintenance fees each year?
For custom development, sure, payment makes sense. But for general product features I would assume that the cost of R&D is the financial responsibility of the vendor.
The next concern I have is one of focus. If the product roadmap is owned by the highest bidder, what vision is steering development? Shouldn’t the differentiation between various DAM products be the different visions of the DAM vendors behind those products? The idea of a shared pool of ideas just feeds into the sameness that we see in DAM systems already. (I just wrote an article about this very topic on http://DAMSurvivalGuide.com)
I love the idea of crowd funding when it comes to getting a product off the ground. But in those cases, it’s about *funding* someone’s vision–not about *defining* that vision. The influence of the people with the money is one of the reasons some vendors won’t accept venture capital.
Plus, I think a product needs to sustain itself. If R&D can’t be financed by sales, then isn’t this like starting a business and then needing to ask mom and dad for loans all the time just to keep it solvent? I wouldn’t want customers to think that without additional payments, they shouldn’t expect to see any reasonable product advancements. I think this would irritate current customers and it would discourage new sales because–I’m sorry–but this really makes it seem like the company needs financial assistance to stay competitive. To be clear, I’m not saying this is the case with Bright. I have no idea how well they’re doing and I honestly mean them no disrespect or ill will. (Nick seems like a very nice guy!)
My final point here is just to encourage Bright to think about what their product will look like in 5 years if it’s based on the best funded ideas and not necessarily the best ideas. If your R&D team is responding to paid directives, you might find you lack the time you need for your own ideas. Don’t let yourselves fall into the same traps that have stifled the dinosaur DAMs. Lead your customers and listen to them. But don’t follow their lead–it’s your job to stay ahead of the game. By the time multiple customers start asking for a feature, it’s likely a sign that you didn’t provide the leadership and ideas they expected. This is a bigger issue to address.
All this said, bravo to any DAM vendor who comes up with a fresh idea. I applaud Bright for trying something new.
David Diamond
Director of Global Marketing
Picturepark
Thanks for the feedback both.
Ralph – you will see we have added some FAQs (http://assetbank.crowdfeature.com/faqs/) in response to most of your questions. We certainly don’t want this to be a bit of marketing fluff, but Crowd Feature’s success really depends on whether our clients think this is useful. We’ll be talking further to them about it over the next few months so hopefully we can report back in time.
David – I think one thing that might be adding to the confusion, which is perhaps not obvious, is that we allow our clients to pay for customisations to Asset Bank (this is in addition to the R&D we do as part of our product roadmap). We do obviously have final say on whether we want a feature in the product, although we do have a flexible plugin framework so that we can develop client-specific customisations if necessary. We also have spent a lot of effort on making Asset Bank very configurable, i.e. to avoid ‘feature bloat’ and noise and so that clients only see the features they want.
Nick Vowles
Marketing Consultant
Asset Bank
David/Nick, you’ve both made some fair points about this.
It’s a tricky situation since although the crowd funding model is a good one, there are some use-cases which it doesn’t work so well with. If this is kept for features that would not otherwise exist (i.e. niche specialty requests) then it might work but probably less so for general requirements where (as David says) general R&D investments should be picking up the tab.
There was a more enthusiastic post about it by Tim Strehle: http://www.strehle.de/tim/weblog/archives/2013/11/28/1672
This point in Tim’s item is significant for me:
“For add-on features that don’t need changes in the core product, I’d go one step further and add an option to collaboratively develop the feature as open source, or ask a third party to implement it. That way, instead of having to give money to the vendor and wait for him to build it, you (a customer or partner) could invest the time of your own developers or pay someone else. Suddenly you have a core product as a common platform, and a market place where anyone can add value…”
As a channel to let other people build enhancements that aren’t sufficiently in demand to be built in-house, this becomes a lot more interesting as an idea (it wouldn’t necessarily need to be open source either).
This is back to some points raised by us at DAM News (and David too in that blog post he mentions) about vendors a) specialising in key areas rather than trying to build everything and b) being willing to assimilate other contributions rather than trying to hold on to it all.
We’ll keep an eye on this one and see whether it becomes geek/marketing toy to be abandoned not long after Christmas, or platform for collaborative enhancement of their core product with longer term implications. They will need self-confidence, vision and time/money to meet the latter objective, but the investment could well pay off as I am fairly sure the DAM industry will eventually have to move to this model over time anyway.
I was interested by Tim’s post too. The idea of a DAM product/platform that enables clients to develop add-on features themselves (or via open-source or a third-party) is very compelling. Look at how successful a similar concept, the ‘app store’, has been for Apple.
However, I think it would be a challenge for a vendor of an established product to pursue this idea. For it to succeed, the technical architecture would need to support a ‘plug in’ development framework intrinsically – I don’t think a ‘traditional’ API, even an extensive one, would be enough.
A new platform, built from the ground up, would be most likely to succeed-although, as the DAM market is now mature, significant development effort (i.e. investment) would be required to create a ‘minimal viable product’ offering the core DAM functionality users would expect.
Still, it’s worth thinking about. Anyone up for joining a crowdfunded initiative to develop an extensible DAM platform? ;-)