"We spend the time and energy searching all over the web for cheaper reservations for you", are you really spending time on searching things manually? If so, I wouldn't pay anything for such a service, because you may apparently go on holiday and don't care about my reservation. If all is automatic, then I could go for it. However, then "spending time and energy" is a lie.
I believe anyone should be able to submit their reservation, along with credit card details. If you do find the cheaper rate somewhere, you charge them at that point and present with the offer.
As for the automatic it is partially automatic. As we're gauging interest right now we haven't fully automated it.
For the pricing we're looking into different options such as taking only a %'d of amount saved, only charging if we save you money, etc. We'll be doing some testing in the very near future on different pricing models.
Congrats on shipping. :) As others have mentioned, I was turned off by the pricing model. Your idea of taking a % of amount saved, or charging me after you've achieved savings would be much more palatable.
That said, if you have the data for it, it would be awesome to show some proof that this is a widespread thing - that prices do fluctuate regularly and there are these drops in price people can take advantage of - if they are using your service. I think that would help your case.
Leanstack.io was extremely useful for discovering services. Needed best A/B testing tools? I used to go to Leanstack. I don't seem to find any reason to visit Stackshare. I don't really care whether Twitter uses Zendesk or Freshdesk.
StackShare has even more tools and services than Leanstack did, with more ways to discover them. Perhaps our messaging needs some work. StackShare is still very much about finding the best tools: http://stackshare.io/mobile-a-b-testing. Would love to hear your feedback, shoot me an email if you're up for it: yonas [at] stackshare.io.
EDIT: Just noticed you're behind Virtkick. Funny enough we just listed you last night: http://stackshare.io/virtkick
I found the reason to visit Stackshare real quick. I just checked today's Analytics of my startup https://www.virtkick.io - 20% visits originates from stackshare, so I now have to claim it. ;) Quite funny, I tell ya.
It doesn't change the main concern, though. leanstack.io was the greatest site to find services.
I'm sorry but we missed your comment. Just created an issue to track this problem: https://github.com/virtkick/virtkick/issues/65 Please subscribe to the issue so you'll get the updates.
Frankly, there are two mutually exclusive camps: free software and open source. I myself sympathize with free software (GPL) whereas RushPL with open source (MIT). Selling proprietary versions has never been the reason for CLA, though! We want to be able to re-release VirtKick under MIT (and automatically get rid of CLA) if we get funded, so businesses have no problems with it. (See https://news.ycombinator.com/item?id=8527999)
Selling proprietary versions has never been the reason for CLA, though! We want to be able to re-release VirtKick under MIT (and automatically get rid of CLA) if we get funded, so businesses have no problems with it.
So selling proprietary versions isn't your goal, but allowing the code to be used in proprietary versions is?
You're walking a very fine line here. One so thin I wouldn't fault anyone who said it doesn't even exist.
What one regards as a feature, other regard as misfeatures. If you like virt-manager, then VirtKick isn't really for you. We value a simple UI more than virt-manager, and REST API more than virsh. We don't say your way is wrong. It's just more difficult.
Existing libvirt clients, at least those that we know of, aren't super reliable though. libvirt stucks when there's too much happening on the HV, or denies jobs without even trying (e.g. when a pool has async jobs). A backend that schedules tasks for background execution is needed for that (and we have it), so even now we're not "just" a frontend for libvirt.
The use case is a very simple panel with zero virt knowledge needed to start.
> so even now we're not "just" a frontend for libvirt.
I would certainly prefer that virtkick was 'just a frontend' for libvirt. Then the people who are making use of virtkick can seamlessly rely on the huge amount of existing software that supports libvirt. You can provide a REST API that is translated to the existing libvirt API rather than replacing it.
If you have task-scheduling improvements for libvirt, they should be upstreamed rather than only exist in your software, so everyone can benefit from them.
