New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Ok, who wants a ticket system? :P
SolusVM module!
Information page is up with confirmed pricing: http://www.openbill.co.uk/
this will be a self hosted system right?
Correct
In the video you say it is open source...
First 5 seconds too, lol.
Hi James,
I've looked at your video, and looked at where you're at with "OpenBill." Personally I think you need to drop this idea of "encoding" it altogether, you're doing nothing but making it more difficult for your legitimate customers to use and customise the product.
Secondly, as you're asking how much someone would pay, I look at the video then compare it to something like Pancake App ( http://pancakeapp.com/ ) which is $49 and full source code based on CI. For the price you're asking I would be expecting more features integrated, and then I have the elephant in the room and that is will this be another Quality Servers/TheUKCloud/Killer.IO situation that you walk away from? Or if this is another hobby brand you're working on?
Whilst I really do wish you success with this application, if I was someone looking to rest my whole small business' billing cycle on the shoulders of a 3rd party developer I would want to know that i'm migrating to a platform that has a solid future. Perhaps at least a public roadmap to V1 stable would go someway to showing you have a longterm direction for this latest project.
I am also allowing development to continue as a reasonable pace by securing myself an income. As I said before, I am looking to put some serious time into development to take it further. Sure, I could have just licensed it out cheaply, but then I'd have to stop development after v1 which wouldn't be much fun
I know Pancake is a cheaper option, but have you actually played with Pancake? Personally I don't like it and think I can do better. I know that it will be some time before it has all of the features but I think it's partly up to buyers to have a little faith in me, and up to me to reward that faith with discounts and cool new features.
What specifically are you looking for that isn't there, that you would use? I'll add it to the roadmap?
sigh I knew this would come up. As I said before these two: Quality Servers/TheUKCloud, had serious problems. I fucked up and it was beyond repair. I did my best to make good with the customers, but that's all I could really do at that stage.
Not sure where this comment is coming from - it's still up and under my control, with a longer server contract tied to my personal name.
What I meant at the time, and what is still true is that I have a lot of constraints on my time and therefore would like to keep the number of hours a day I spend on virt.io down. If this becomes impossible then I will probably retain ownership but have someone else take on most of the work.
I set up a Uservoice community last night to keep track of feature requests and their implementation: http://bugs.openbill.co.uk/. I'll be populating it with the ideas I've received so far, that are going to be implemented after the initial v1 release.
P.S. Have you noticed how I've planned to implement pretty much every suggestion made so far? :P
Why would you have to stop? You increase the price as the service/product improves. You don't slap on a $320 price tag for work that's on a to-do list. I think you're greatly overestimating your worth.
That's great. Give me a PM when you finish implementing them all.
A few questions for you:
Why should I pay $3 less for obfuscated code that I have to host, when I can pay $3 more for a product with greater features and a hosted solution?
Obfuscated code to me is worse than a hosted solution.
Why should I buy your product instead of one of the many fine products on CodeCanyon that come with full source? (for under $50)
Also, your attitude seems to be that buying this product is investing in you. Where as in reality people don't care, all they want is a functional product that "wows" them.
I think you're too eager to release this; its current form is half baked and to be honest it's nothing special.
I know I'm being quite negative, and in all seriousness I do wish you the best with this product. I just have my doubts.
There is a 30% discount, which takes that down to about the $250 mark. Also you don't "have" to buy the full source code - an owned licence would be just £70 - around $100, with support and updates. I think that's quite reasonable.
Because the hosted solution is slower, locks you in and gives you little control over your own data.
I didn't find one that is as good as this, or I would have used it.
How I decide to devote my time is a personal choice. I'm happy to give up a little social time for OpenBill which should be enough for it to flourish.
False. Your 'insurance' against people just buying the code once and using it forever is several things: updates, support, and reputation. Users that only buy a license for a month won't get updates afterwards. They also can't get support. Additionally, hosts will lose reputation if something like a public license checker exists and it's found out that they use an unlicensed version.
Encoding via Ioncube etc., is, as was said earlier, not a suitable option. There are basically three groups of people that would want to see and reuse the code:
End result is that encoding (it's not exactly encryption) is not really going to help. Better options are, as mentioned before, a public license checker (and be sure to make it well known that that license checker exists), only giving support and updates to people with a license, and perhaps the most important one, explaining to people why you need them to buy a license (have to have food on the table etc etc). Especially the latter tends to get people further than they initially expect.
I don't really see the point in a developer version - it will only make it more expensive for people that just need a quick (security?) fix to get stuff done, meaning it only really inconveniences legitimate users. The usefulness of an NDA is also questionable, considering there is already something preventing people from using the code for their own purposes (copyright).
There appears to be an eternal debate over this - which is why open-source proponents often use the term "Free Software", to avoid misunderstandings in that field. Personally I don't consider something open-source unless it allows you to at the very least modify the code or reuse parts of it.
As long as you are considered the 'main vendor', you will pretty much have a guarantee of sufficient income. I think the question here is what you consider more important: making a decent living, or making as much money off it as possible?
I'm also not quite sure what "bits and pieces here and there" has to do with open-source.
All those three go for encoded source, even if to a lesser degree.
Final remark: making your code open-source gives users a guarantee that they are not left in the dark if you ever decide to close up shop. Someone else can take over development.
EDIT: The above not only means more certainty for users, but also less strain for you as a developer.
then why do all the major billing softwares do this? Clientexec, HostBill, AWBS, whmcs?
Because they buy into the fear-based marketing of Ioncube ("your code is getting stolen, protect it now!"). This marketing strategy is not unlike that of anti-malware vendors. Fear sells.
It also protects your code somewhat from crackers, it provides a road block, not a total stopper but it helps. It keeps honest people honest. Dishonest people will nomrally stay dishonest.
I don't get the idea you actually read what I said. Those that you are trying to 'protect' your code from are the exact same group of people that have the time (and money) to invest into cracking this kind of stuff. The extra few days they need aren't significant, and do not actually stop them. You are only inconveniencing legitimate users.
Roadblocks are useless if you have a guarantee that the escape vehicle will run through it anyway, yet it obstructs regular traffic.
@joepie91 and @24khost:
I appreciate both of your comments and generally see two sides to the same coin however I tend to agree more with @24khost, for the reasons I've already given and the reasons he mentioned, which is why at the moment I'm leaning towards encoding as stated on the website.
There won't be an NDA since the EULA covers everything that's necessary, and the EULA will have a provision to allow licence holders to continue to use the software should something happen to me.
The home page is coming along nicely:
Which reasons in particular? I thought I responded to all of it, but I may be wrong and have missed something.
@jhadley I would love to see a whmcs import script also!
cpanel provisioning +1
Direct Admin Provisioning +1
I would buy this if I ran a host. :P
Any plans for OpenBill to be used for non-webhost billing?
I too am not a fan of dealing with encoded files. I also have to agree with @Chief and @telephone and say that you're pricing is little high for a new project with planned features.
For me, I want to give openbill a try, but won't deal with encoded files, and the developer price point is just too high for me =/
As others have stated, encoding just makes things more difficult for the end user, and those who really want to get the source will decode it. Though I understand your reasoning behind encoding, IMO it's a poor solution. There are many commercial developers that provide the source code on purchase, continue to make income, and continue development.
I'll definitely be following this project and see how things progress though. Hope to see this become successful!
edit: @joepie91 goes into more detail about maintaining income while providing source code above
Since you took the time to write out everything you did, I think it's fair I do the same:
Immediately the concept of taking holidays springs to mind. Just like everyone else, I want to be paid not to work for a few weeks a year.
This software isn't just for hosts. In fact, it was supposed to be for freelancers originally. Your average web design client isn't going to check their designer's billing system's licence, or care much about it for that matter.
For most people, it will be better to file a feature request than do their own coding. Once you start changing the code, you're largely on your own with regard to updates, whereas new features get added for everyone and supported.
I'm trying to avoid suing people.
It's probably cheaper to pay for a decoded licence than to attempt to decode the software.
Will be doing all of those things.
There's no need for an NDA. The EULA covers everything.
As long as my wife and I can live comfortably, I don't really care.
There will be a provision in the EULA for paid customers to continue using/developing the product should I be unable to continue maintaining it.
Direct Admin Provisioning +1
This isn't designed to compete with WHMCS really. We'll see where it goes though :P
It was meant to be for freelancers actually, so the question ought to be whether there are any plans for it to be used for hosting billing. The answer is it depends on demand.
Is that with or without the discount?
Thanks!
Well if it doesn't have those features that a webhost would need then the pricing in my eye's falls.
to somewhere in the 5.95 a month range.
With the early adopter discount =/
If I were to raise the early adopter discount to 50% would that make it affordable/worthwhile to you, or would it still be too much?
I'm not sure how this is a problem - if someone buys your billing panel, they will expect support anyway, regardless of whether you are on holiday or not. You'd have to find more support staff regardless. I don't really see how readable vs. encoded source changes anything here.
That's a fair point - I can imagine that makes a public license checker far less useful.
For most people that may be the case - but what about people that want to have a feature that you're not planning on implementing? Or what about urgent fixes? Or what about custom integration? Etc, etc, etc. If your source is encoded, you are forcing people to get features implemented by you and you alone, and a good example of where this goes wrong is the IPv6 rDNS in SolusVM. If your source is readable/editable, the choice whether to file a feature request or code it yourself (and maybe even contribute it back!) is up to the user, and he can choose what fits best for that particular situation.
The actual suing is not even necessary - just the idea that it can happen is enough for most people to not even attempt it. For 99% of the rest of the situations, an abusemail to the host suffices.
But how would they do that if they can't access/read/modify the code properly? There are situations I can think of where you wouldn't even be able to supply the original source later on, and these situations would pose a real problem.
Then I think you could safely charge for support and updates and leave the code readable or even open-source, as 'main vendor' you will automatically be considered the most trustable/reliable support provider for the software. That should provide enough income in itself.
My advice would be to try releasing it with readable source initially - if people reusing the code without permission ever becomes a real problem, you can always switch to Ioncube encoding and developer versions later on.
Will do
Should have been clearer - if something happens to me and I am simply unable to continue, I will make sure the source gets released.
There seems to be a serious contradiction here - either encoding is necessary to prevent licence abuse or it's not in my opinion.
I personally don't believe it will work, and if there are issues with code theft - which I find highly unlikely to start with - I don't believe Ioncube will solve those issues. The only reason I am giving that as a possible solution, is to show in practice how using Ioncube won't really change things - consider it a form of practical proof of my points above