Introducing Opencall
I've been bootstrapping a tech start-up for the past year (having spent $25k+ on development of our platform plus all the other expenses that come with setting up and running a business) and last week a major competitor entered our niche market.
The money for the start-up was coming from my own pocket and funds were/are running low - it was crunch time, do I throw my last remaining cash trying to catch up with this competitor, or do I shut down.
I asked advice from a number of different sources, and the overwhelming response was to pivot the business by open sourcing and selling services around the platform such as hosting.
After a long weekend of thinking, designing, planning and building, I give to you:
* Opencall http://www.ocall.org
* GIT Repo: https://github.com/calltrackingasia/opencall
It would be great to hear your feedback and to find out if anybody would be interested in becoming part of the project.
89 comments
[ 3.1 ms ] story [ 61.0 ms ] threadOpencall http://www.ocall.org
GIT Repo: https://github.com/calltrackingasia/opencall
Looks like a pretty cool system. My products are all Twilio-based, so I could see a lot of value in making your system telephony-agnostic instead of relying on Plivo.
Sweet product though.
[0] http://pear.php.net/manual/en/standards.php
From the site:
* Login to your installation of Opencall and add the numbers you’ve just purchased on Plivo. Then define your rules (e.g. when someone calls number X, forward the call to my mobile number or to my SIP address).*
* When someone calls your Plivo tracking number, their call will get instantly forwarded to the number or SIP address you defined in Opencall. At the same time, Opencall will log statistics about the call and make a recording of the conversation (if you enable this feature).*
So basically, it's call routing and recording, to allow people handling inbound calls (e.g. customer service, inbound marketing, etc.) to track their calls, stats, information, review previous calls, etc.
I'm sorry to be so blunt, but if that's your elevator pitch, well, right there is your problem.
What is call tracking? It lets you track statistics and recordings of inbound phone calls (usually from your customers) so that you can identify trends, strengths, weaknesses and understand the performance of your sales and marketing campaigns.
Time of day, day of week, failed calls, total calls, caller id, caller country, call duration, hangup reason - all these stats and more are available.
I had this issue and my conversion went way higher once I made my copy for my user instead of for my product.
Good luck! Your product looks amazing.
Call tracking software records information about incoming telephone calls ... it is based on the technological possibility of measuring the behavior of callers and is thus the equivalent in telephony to the conversion tracking used on the internet.
https://en.wikipedia.org/wiki/Call-tracking_software
Lots of suggestions:
* Don't write your own cron scripts, use Symfony Commands.
* Delete the Acme Bundle.
* Don't store your vendor directory in Git! Completely unnecessary and waste of 47MB.
* Don't commit parameters.yml, that's what parameters.yml.dist is for.
* Use a migration tool (Doctrine Migrations are fine) instead of one big SQL dump.
* Not sure what mongodb/example.php is for.
* Why is all the plivo stuff in web/plivo/ instead of being a callable controller?
* Are you manually generating your Doctrine entities?
* Don't commit your asset directories (they should be symlinks).
* No need to use PHPMailer (or include the entire project in your repository), Symfony comes with Swiftmailer which is great.
* Same with src/Phone, add that library through Composer (https://packagist.org/packages/practo/libphonenumber-for-php).
The design looks great, but I wouldn't trust a lot of this (especially after seeing how many hosts and usernames and passwords you left scattered about).
I find that it simplifies versioning as well as making it so you don't have to download individual dependencies. What is your suggestion otherwise?
Committing dependencies is a solid decision to avoid taking a dependency on a bunch of third parties.
If someone's downloading your repo, why wouldn't they mind getting their dependencies the normal way? Also, there is the benefit of your git history not having to track vendor libs, and you being able to lock versions in.
This is about convenience to yourself as a developer, as well as others. Feel no need to include vendor libraries :), it's ok.
I know what you are meant to do is check in your composer.json and composer.lock then do a composer install on the server.
But then you have a external dependency on your install process on live servers, which is a terrible idea. To got around this, I've seen companies say "we have our own package mirror". Or you could just check in the vendor folder?
Another reason I do it: My software package is used by people who aren't PHP programmers and I want them to be able to just grab the files and go with no fuss.
I do appreciate having the vendor folder in git takes space and is a pain ... but I think the trade off is worth it.
It's not the attitude of saying that security isn't taken seriously that gets me upset. It's the condescension. Let people learn by making mistakes, sometimes there's no other feasible way. Think of how to be helpful, not condescending.
The only addition I'd give is to start changing your passwords… quickly.
Passwords were changed the second you mentioned them, and we'll be making all of these changes as soon as possible.
> Don't store your vendor directory in Git! Completely unnecessary and waste of 47MB.
While 47MB is indeed a bit large, storing vendor libraries alongside your code makes sure you have a working version when you pull down the repo. Nothing more frustrating than hunting down why the code you just checked out doesn't work.
> Don't commit your asset directories (they should be symlinks).
That depends on what you mean by assets. If there are binary assets needed for the app to run, they must be included. Imagine downloading a web app with all the icons and textures missing. Not good. And if source files exist for these assets, they should be in the repo, too (like PSDs or Inkscape SVGs)
You should commit your asset files in the Bundle, but not the ones in web/bundles/ because those are created by copying or symlinking the assets in your Bundle.
This is hardly giving it away to the world. It's making the source viewable, but it feels it's not about open code, but someone who spent $25k developing a platform (often more in many cases).
Open source has this thing where people refer to it as free, in reality, this is just like someone begging for us to pay their monthly fee and give them free commits.
Why? For something anyone here could do with a CRUD app?
... If I used your software commercially, I can't even link it to my own software.
This gplv3 stuff shouldn't be allowed to be thought of as free, it should be thought of low trickery. Read the license, imagine if this was your business. It looks as if someone wants the world to program their software. But it's not the world's software, it's their software, their control, their power. Not yours. Not the worlds.
I'd replace the homepage (temporarily) to the absolute minimum during the time it's bombarded with requests, unless you have a vserver/cloud-host that you can scale up. Or change the server your DNS records point to, if you use CNAME, to one at rackspace, github homepage, or anywhere else with a minimal homepage. But I'm sure the guys @HN have better tips :)
I don't know much about legal stuff and licenses, but I would allow anyone to use your software as long as it's code is shared, except for enterprises. Companies who want to use it commercially and have more than 1-5 employees would need to obtain a license. Open Source doesn't mean that you cannot put a price tag on it.
But as you said, prepackaging the stuff as a deb/rpm and allowing white-labeling for enterprise customers would be a good way get some money back from this. Just saying, but you could, if you wanted to, add advertising into the opensource product and disallow it's removal unless a license is obtained. If you were an SaaS, you could collect data and metrics, that you could monetize, but I'm glad you aren't anymore :)
@pg I think there should be a sticky informing website owners on howto react, when their website is HN'ed. Somewhere in the footer of the homepage or so.. This is happening a bit too often and many aren't prepared for such high traffic peaks.
> but you could, if you wanted to, add advertising into the opensource product and disallow it's removal unless a license is obtained.
That's not Open Source. The phrase Open Source has definite meanings and a strict definition, and people have a set of expectations when they hear that phrase. http://opensource.org/osd-annotated
Granted, you certainly can do what you are proposing, but
- That's a very different business model from an Open Source one, as commonly discussed and understood.
- You really shouldn't call it Open Source. This is important beyond mere pedantry as people spent a lot of time building up the Open Source movement with strong principals, and we all benefit immensely from it. If we allow the Open Source label to be ruined by things like this we will all suffer.
> Open Source doesn't mean that you cannot put a price tag on it.
The other things could be done, but you're right, they don't fall under the strict definition of opensource. It would require a different license :)
Oh, btw, the op should take a look at https://pkgr.io/ and https://github.com/jordansissel/fpm
http://openvbx.org http://twilio.com
Disclaimer: I am part of the Plivo team.
A change to BSD instead of GPL would be nice too :)
I've been meaning to build something similar so I'll probably be bit of a contributor
At the moment we don't have a community as we only launched the project today. The form is a placeholder while that community gets established, and will hopefully be replaced with a forum & docs very soon.
and
http://daux.io/ and http://apiblueprint.org/ look like a good way document your software
1. The advice to pivot and offer it open source is good. Kudos to you for following up on it. This gives you some free marketing that you might not otherwise get.
2. It isn't quite clear to me how to integrate other telephony products based on the discussion. If in addition to http, you could support either IAX2 or SIP, this might provide significant improvements in terms of reachable market, because you could integrate with existing soft phones and open source PBX's, including both Asterisk and Bayonne.
Those two things strike me as being things which might increase your market reach significantly.
Thanks for the feedback.
my cofounders and i spent upwards of $250k cash (on top of our own time value) of our own money before we gained any sales traction. an order of magnitude higher than your pain threshold. if you weren't prepared to spend that much either from earnings or savings or equity, i'd say you made the right choice.
Would be interesting to hear your thoughts.
AGPL/GPL:
If you do this people in the community may like this. But you will have problems selling commercial licenses to people. To get around this, many companies do a dual license model where you can get the code under AGPL for free or pay for a commercial license. However, to make this work, you will have to get all your contributors to sign a contributors agreement giving you some rights. Some will hate this and won't.
BSD:
There is a risk that an outside company will take code and profit from it without giving back. Some contributors will avoid because of that. But then, no issues folding community contributions back into your commercial codebase. Contributor Agreement much simpler and less controversial.
I personally went the BSD route for http://ican.openacalendar.org/ - I like simplicity.
Looking at the Opencall website, your are only selling it as a hosted service and not as a product. Both GPL and BSD will allow someone to create a competing hosting service and add any proprietary addition to it without having to share it back. AGPL would make sure that any such addition is shared back, so your business will always has access to improved versions.
Contributor Agreement is irrelevant since you won't need one if you just do hosting.
Given that OpenCall is Open Source, this is very possible.
Good point re diff between on GPL/BSD and AGPL. Tho if I may add, AGPL will only state that in writing. A bad company may break that, and then it's up to how willing you are to get legal on them to enforce the AGPL. Some people may be unwilling to do this, so this may play into the choice of license you go for.
I think the perceived drawback with AGPL is that you'll not have the community jump in as readily as with a more permissive license. And there is a lot of negative talk about the license as a result.
Google for example will talk about how AGPL is "more of a procedural issue than anything else" [1] whereas I believe that it is just in their interest to have permissive open source code that they can use and not share back anything. Very little of the Google infrastructure is shared, but there is no doubt that there is a lot of FOSS code in that infrastructure, or as a basis for the infrastructure, which obviously has moved on (and not been shared).
Google once banned AGPL projects from Google Code, but reversed that in Sept. 2010. Maybe the "threat" from AGPL in changing the culture around open licensing is now perceived so low that they aren't afraid of it anymore.
There are successful AGPL projects like MongoDB[2].
[1] http://www.theregister.co.uk/2011/03/31/google_on_open_sourc... [2] http://www.mongodb.org/about/licensing/
Yes, I do work on a bunch of AGPL licensed software which is used by governments, companies and NGOs.
My advice is don't put more cash into it for now, go talk to Plivo, talk to a few call center companies see if anybody wants to be a partner on reasonable terms. In the mean time look for a team and funding. Not freelancers, a few guys part time, working for shares is better for VC.
In adult life, usually best to post from a position of strength, or people will dump on you.
The reason I ask: I hate their, and their competitor's pervasive and mad behavior, when it comes to pitching their own product, whilst DDoSing etc. their competitor.