Introducing Opencall | Hacker News Reader

Introducing Opencall

183 pointsscottybowl85 comments

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.

View on HN

You have some usernames and passwords (to what looks like production servers) sprinkled throughout your app. May need to change those ASAP, wipe your history, or something.

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).

If it works, does any of this matter right now? He's trying to make his business survive, not craft a work of technical art. Shouldn't he spend his time on marketing if the thing works?

His business isn't going to survive very long if he keeps uploading security credentials where everyone can see them.

Not my finest hour.. Lesson learnt - valid point, and I will make certain to be more security conscious moving forward.

Maybe not right now, but you've got to take care of technical debt sometime, and a few of those points are quick wins.

actually, there's no big big items but opensourcing isnt magic, you want people to look at it. if the project looks nicely managed, its a lot more attractive :)

Hey man, thanks for existing. The amount of money I make from cleaning up after dipshits who think "just throw some spaghetti at the wall, we'll deal with making it sustainable and secure later" keeps me almost embarrassingly busy. Of course, I'm as often as not the last money they spend, because if that's how you're running your business, you're screwed anyway. Keep being ignorant; keep writing me checks.

This is precisely the type of attitude that would cause me to not want to even start on a side project. I'm floored whenever someone puts up a side project for feedback, and then a flood of high-quality technical feedback comes on how to improve things. That is cool. This is not.

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.

And I think the attitude that "screw security...shipping is all that's important" is monumentally condescending, and shows incredibly poor business skills. It's saying "look, fuck the customers and whatever data we may collect about them, as long as we launch". And it's not a zero-sum game; you get a long way to "good security" with "good coding practices" and some "good testing". The only real up side to having to clean up the mess after some snotty brogrammers who's only response to "you just dumped the PII for 25k customers into the black-hat market" is "So? We got 25k customers!" is being able to respond "not any more".

You should read more carefully. :-)

The road to success is littered with crashed startups who just keep pumping out code when the time for marketing instead of coding came long ago.

Please, no personal attacks. They are totally out of line on Hacker News.

Some of these are debatable.

> 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)

All of my repo's have a 'build-dev' script in the root of the repository (see here: https://github.com/brightmarch/picto/blob/master/build-dev). Run that after you pull it down and it builds the environment for you (minus setting up Vagrant).

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.

or use composer, and commit composer.lock to ensure when composer install is run you'll get the dependency versions that are meant to ship with the release.

> Don't store your vendor directory in Git! Completely unnecessary and waste of 47MB.

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?

There is a composer.json and composer.lock file in the repository. All you'd need to do to download all the dependencies is have composer installed and run "composer install".

Thus making your application build process require full Internet connectivity, and making it require that every dependency hosting site is working.

Committing dependencies is a solid decision to avoid taking a dependency on a bunch of third parties.

"application build process" or simply the checkout process? I'd suggest your deployment process shouldn't include a public git repo others can change. Instead, use your own fork on Github, or alternatively host a git repo local to your deploy network. After all, you're trying to avoid dependencies on things like Github working/failing, right? ;-)

I do this.

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.

That's what composer is for

what is composer, and why do I have to learn it if it is completely unnecessary?

Composer is the de facto PHP package manager, and it is highly recommended for modern PHP applications.

What is <insert technology>, and why do I have to learn it if <insert worse technology> is sufficient?

If you must... use submodules.

This is good advice.

The only addition I'd give is to start changing your passwords… quickly.

Thank you, this is fantastic feedback. Sorry for not applying sooner, but my account was blocked from making comments (apparently I was trying to post too frequently!).

Passwords were changed the second you mentioned them, and we'll be making all of these changes as soon as possible.

This is the thing about open source. Any one can make these improvements. Maybe you could open github issues for these suggestions and someone could have a go at making the patches.

How would you synchronise between versioning the symlinked assets and the app itself? Or do you just keep all images, for example, until you're simply sure you don't need them anymore?

I am in this business and I think the general execution seems reasonable if it works as advertised. However you need to secure at least one big partner or a few smaller ones. May be Plivo themselves, they should be interested to help out promoting a good product based on their platform. You will need funding to develop the whole thing into a unique appealing product with some differentiators - some harder technical features, better artwork/UX if you will.

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.

Thank you - this comment is buried but it's excellent advice and I will be taking it seriously. Currently chatting with one of the co-founders of Plivo so watch this space :)

Just adding a comment to make it easier to click the links:

Opencall http://www.ocall.org

GIT Repo: https://github.com/calltrackingasia/opencall

Looks pretty sweet. Do you have a style guide for contributions? There are a lot of low-hanging fruit here that would be easy for contributors to get in and start making pull-requests.

Thanks - no I don't, any tips or resources on the best way to get this prepared?

I usually just start out with an existing style guide. Maybe take something like the PEAR style guide [0] and distill it down to the basics. You basically just want people to know how you want things formatted and what is an acceptable structure for commits.

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

That's really useful, thank you. The system will work with Twilio if you override the default XML responses when adding an advert, but for now that's not built in so I haven't officially put that it supports Twilio.

If you can edit the post it would helpful if you included something to let people know what the project is. Something like:

  Opencall: open source call tracking software

  Self-host your call tracking solution – own your data, cut
  your costs and track calls in any country.

Any market that is worth entering will have competitors. Look at what you are doing as a strategy not a last-ditch effort. Open source is a very valid way to build a business in a market with entrenched proprietary competitors, and it's exactly what my company is doing right now. I wish you luck, and go sell some software!

Just another reminder:

In adult life, usually best to post from a position of strength, or people will dump on you.

Interesting that you think that, do you have any HN-Show examples to support the point, or other sources? Not to be pedantic, I am really just curious.

This seems a lot like OpenVBX[0] just powered by Plivo, not Twilio[1]. OpenVBX is also open source.

http://openvbx.org http://twilio.com

Seems like OpenVBX is a call router of sorts, whereas Opencall is call tracking software. Similar, but different.

so, this is a subset of openVBX?

yup - what is the main difference between the two? OpenVBX can be decoupled from Twilio as well.

So here is the interesting thing. I am an ACTUAL user of this type of software and a paying SUBSCRIBER to two different SaaS call tracking platforms. I run a marketing agency and have almost 200 clients using call tracking on the twilio platform.

Firstly - thank you! What an awesome contribution to the community. I cant comment on code quality or license attribution but I can tell you that it is an extremely valuable service.

I have not downloaded and installed your code, but I will - here is where I see the market need these days, and its far greater than just source attribution.

Google has done a great thing by encrypting searches, but it is terrible for website owners and marketers because it is so difficult to prove ROI.

The place that we use using this successfully is by using the UTM source information of a click to change the incoming phone number on the site using dynamic number insertion - this helps clients have a justifiable ROI to continue to use the service.

If you have questions about how I am using this, please feel free to let me know - but kudos to you on building and open sourcing it.

A couple points.

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.

SIP is currently supported on the outbound leg. Definitely the plan to integrate with other telephony products and hopefully by going the open source route we'll be able to make it happen sooner rather than later.

Thanks for the feedback.

What is call tracking?

The product is for tracking inbound calls, presumably leads. From the looks of the screenshots, you can see who called, how they were routed, and listen to the recordings.

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.

In sales/marketing language: it allows companies to boost their sales & ROI, reduce advertising budget wastage and optimise their teams performance on the phone by tracking inbound phone calls from their customers.

No, those are all outcomes. What does your thing do to achieve those outcomes?

I'm sorry to be so blunt, but if that's your elevator pitch, well, right there is your problem.

It depends on who I'm pitching to - if I'm talking to a CEO of a company, they're less interested in how it works and more interested in how it's going to make/save them money.

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.

Disagree. It's a pretty good elevator pitch. I may need something like this in the future and I'm excited by it!

Tip: this tweet is so much more important that saying what the tool is. It positions yourself with a problem the user has instead of just saying what the product does technically.

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.

This. Read the post, clicking through to the site, browsed the repo, still had to go look it up on Wikipedia. Copying a bit of their intro wouldn't hurt:

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

IMHO (I'm just a stranger from internet)

1. Call to action is hidden. Your goal it to sell SaaS service?

2. Price comparing plans should be easier, less text more icons. ex. http://uxmovement.com/content/7-useful-design-strategies-for...

3. Too many features. 3 features is optimum, 7 is max. (except selling to corporation, then you need a datasheet). look at https://training.kalzumeus.com/newsletters/archive/enterpris...

4. Products that do everything, are not successful.

5. Who is your customer? Maybe put remaining money in advertising.

6. Set it as beta and put on http://betali.st or other similar sites. Get more feedback, involve users, because you don't need one time customer you need audience (loosely quoting rework)

7. Where is competition there is a market. Competition is the greatest thing on the earth. Maybe you could beat them with the best customer service ever? Or with openness and community around your product? or your product will be super easy with minimum features? or will not require hours of trainings

As my account is new I'm having trouble replying to comments ("You're doing that too much!"). I promise I will reply to you all - thank you for all your fantastic feedback and security tips. We've started implementing some of these changes.

Would be curious to see/know which major competitor you're referring to

Im sure a quick Google search will show you ;)

hehe, your server is HN'ed :)

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.

> Companies who want to use it commercially and have more than 1-5 employees would need to obtain a license.

> 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.

@jarofgreen nice of you, but I think you got me a little wrong, or I wasn't clear enough. My main message regarding opensource was:

> 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

Thank you so much for releasing this as free-as-in-freedom software! Since this appears to be server software, I'd like to recommend switching to the Affero GPL; its only additional requirement over GPL is that network operators must release the source version they're using. This way, the software remains free and no one can take your hard work and refuse to to share it with your users. Good luck selling your services!

I wasn't aware of Affero GPL, will look into it. I've had some conflicting advice when it comes to licenses. Some are recommending BSD as it's more permissive (i.e. big companies can develop it in house without having to give back to the community). From a business perspective, that might be easier to sell to some companies, but from a community perspective it's not ideal.

Would be interesting to hear your thoughts.

You will definitely get conflicting advice on this. :-)

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.

It all depend on what one want to do, and what ones business model is.

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.

Contributor Agreement is absolutely relevant. If there is any chance that the project will accept patches from random people then release those patches as part of the core code base under a license .... you need a contributors agreement.

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.

In my view the people that recommend BSD/MIT or more permissive licenses tend to come from two camps: those that want to use the software themselves without having to share back anything or those that think that having a permissive license will get so many users that some benefit / coder sharing back will happen as a result.

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.

The company I work for offers a service for Germany based customers where they can register a calltracking number and get usage analysis - all for free. Check it out if you're interested: https://heldennummer.de

Does it have any affiliation with lieferheld.de/ ??

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.

I notice the only inbound telephony provider is plivo, do you have plans to support asterix or dialogic.

Plivo also has an OSS offering which is based on FreeSWITCH. So it could work with that too.

Disclaimer: I am part of the Plivo team.

Great stuff @scottybowl! You can test the system live by signing up and getting a free number at https://manage.plivo.com/accounts/register/

Couple of coding advise for Symfony2 application:

* use repo method in repo classes, * separate and contain related code logic into bundles: you should have your code like this: /src/OrgName/BundleNameBundle

just a general comment: your instincts and advisers were probably right - if you can't continue past 25k without serious reservations, it's best to open source it and build a business around the project.

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.

Any reason why contributions on the ocall.org site goes to a contact form?

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

It would be fantastic to have you as a contributor - please feel free to email me on scott.bowler@calltracking.hk so we can talk things through.

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.

https://github.com/discourse/discourse ain't bad for forums

and

http://daux.io/ and http://apiblueprint.org/ look like a good way document your software

First look I'd suggest is separating the DDL and DML into separate SQL scripts, the mysql dump is scattered and hard to read.

hey scott, met you before when I was working on Sponfed. kudos to open sourcing the software, wish you all the best buddy!

Thanks very much! Ping me if you'd like to catch up for a coffee :)

great idea, the industry needs this. don't personally know a lot about the industry but I know I need to learn more about it.

I'm sorry to be pedantic, because I acknowledge you are in a tough spot, but just because you put $25k into the development doesn't mean the code is worth $25k.

I don't believe the OP ever said the code was worth $25K.

The original title of the post was something along the line of "I just open-source $25K-worth of code." It's since been ninja-edited.

Reply on news.ycombinator.com