Wednesday, November 22, 2017

Small Business Accounting Software Woes

I'm so disappointed with the online accounting software options available to me; and I've spent far far too much time in the past couple of days looking for an accounting solution for my new business. The current state of affairs makes me wonder if just using a spreadsheet might be as easy.

I am posting my experiences here for two reasons.
  1. To inform others who might have similar needs, and
  2. To inform the hopefully smart people at these companies, so maybe they will improve their products.
Let me start with a brief summary of my needs:

  • Track time (esp. billable hours)
  • Tracked time should include date, and project/client, and some description of work performed.
  • Multiple currency support. I have international clients that I need to bill in their preferred currency.
  • Invoicing and payment tracking for above.
  • Payroll -- preferably integrated with someone like Gusto.
  • Support for two employees with plans to grow. 
  • Double-entry accounting (including bank reconciliation) for my accountant.
  • Affordable -- I'm a small business owner.
That's it. Nothing super difficult, right?  You'd think there would be dozens of contenders who could help me.

You'd be wrong.

Here's what I looked at, and their deficiencies:

Freshbooks 



I really like most of what Freshbooks has to offer, and this was my starting point. Super easy to use, an integration with Gusto, and their invoicing solution is super elegant. Unfortunately, their lack of reconciliation and double-entry accounting (or any of the other "real" accounting stuff) disqualifies them. Adding to the problem, I already use them for my personal consulting business (where I've been a happy user), and they don't have support for multiple business on their "Classic Edition".

Then there is the whole confusion between "New Freshbooks" and "Classic Freshbooks".

This is a company that states they intend to continue to keep two separate software stacks, with about 90% functionality overlap, running ~forever. Why? Because they have some features (and some integrations) that they lack in the new one. (I've been informed that my use patterns indicate that I should stay on the "Classic" edition forever because of my heavy use of Time Tracking.) Some of us with real world software engineering experience know how costly and hateful it is to have multiple simultaneous versions of a product in production. Freshbook's approach here, with no plans to merge the functionality, is about the most boneheaded decision I've seen engineering management take.

Being stuck on the "Classic Edition" makes me feel like a loser, but really it's a sign that their own product is the loser.  I have to believe at some point one product or the other is going to be a dead end.

Quickbooks Online


This is a product that is well recommended, and probably one of the most widely used. It has so much capability. It also lacks the "hacked together by a bunch of different engineering teams that didn't talk to each other" feeling that their desktop product has. (Yes, I have experience with Quickbooks Pro, too. Sad to say.)  It's probably a good thing I can't look at their code behind the curtain.

The biggest, maybe even only, failing they have for my use case is their inability to bill against clients that are in a different currency. Wait, they are multicurrency capable, right?  Uh, no they aren't. If I can't record my billable hours against a client in another country in their preferred currency, then whatever you think your "multicurrency" support is doesn't count. I have international clients that demand billing in their local currency.  So this is a non-starter for me. This feature has been asked for before from them, and they have ignored it. Major, and honestly unexpected, fail.

Cost wise they aren't the cheapest, but this one feature absence is a show stopper for me, otherwise I'd probably have settled here.

Xero


Xero is another of the main companies, and in Gartner's magic quadrant as their leader in the sector. I didn't actually try them out -- though I did research. Their shortcomings for me were: price (multi-currency support requires me to pay $70 / month, which is about 2x all the others), and lack of time tracking. Sure, I can add an integration from some other company like Tsheets, for another $20 / month. But now this solution is like 3x the cost of everyone else.

One feature that Xero includes for that $70 is payroll processing -- but only for a handful of states (California is one), and I can't seem to find any reviews for folks who have used them.   If I want to use an outside company with a longer track record and broader coverage across states, like SurePayroll or Gusto or ADP, I will wind up paying double.

If Xero would change their menu somewhat (make it ala carte), we'd be able to work together. Let me integrate with Gusto, and not have to pay exorbitant fees for multi-currency support. Add time tracking and it would be even better.

Arguably I could stop being such a penny pincher, and just go with Xero + Tsheets or somesuch. Outside of the crazy expensive options for companies that can afford a full time accountant (Sage, NetSuite, looking at you!), this was the most expensive option.  I'd also have to use Xero's payroll service, and I'm not sure


ZipBooks


At first blush, ZipBooks looked like a great option. On paper they have everything I need -- they even partnered with Gusto, and claim to have multicurrency support.  Amazingly, they are even freeOf course if you elect to use some of their add-ons, you pay a modest fee, but from a pure price perspective, this looks like the cheapest.

Unfortunately, as I played with their system, I found a few major issues. Their multi-currency support is a bit of an inconvenient joke. They don't let you set a per-client currency. Instead you change the currency for the entire account, then generate invoices in that currency (or accept payments), then have to switch back to the home currency. This is account wide, so you better not have more than one person access the account at a time. The whole setup feels really hinky, and to be honest I just don't trust it.

Second, their bank integration is (as of today) broken -- meaning the website gives me conflict errors before I even can select a bank (I wanted to see if my business bank -- a regional smaller bank -- is on their list). So, not very reliable.

Finally, their support is nearly non-existent. I sent several questions to them through their on-line support channel, and got back a message "ZipBooks usually responds in a day". A day. Other companies I looked at took maybe 10-20 minutes to respond -- I still have not received a response from ZipBooks.

I need a service that supports real multicurrency invoicing, is reliable, and with reachable support. Three strikes for ZipBooks.  Damn, I really wanted to like these guys.

Kashoo


Kashoo was well reviewed, but I had some problems with them. First their only payroll integration is with SurePayroll. I hate being locked in, although I could probably overlook this. Second, they don't have any time tracking support. Instead they partner with Freshbooks, but only the "Classic Edition" (and apparently no plans to support the "New Freshbooks".)  A red flag.

And, that brings in the Freshbooks liability (only one company, so I can't have both my old consulting business and this new one on the same iOS device for example), and I'd have to pay for Freshbooks service too.

On the plus side, the Kashoo tech support (or pre-sales support?) was quite responsive.  I don't think they are far off the mark.

Wave Accounting 


Wave is another free option, but they offer payroll (although full service only in five states) as an add-on.  (They also make money on payment processing, if you use that.)  Unfortunately, they lacked support for integrations, time tracking, or multi-currency support.  I'd like to say close but no cigar, but really in this case, it's just "no cigar".  (I guess you get what you pay for...)

Zoho Books


Zoho Books is another strong option, well regarded.  So far, it seems to have everything I need except any kind of payroll support.  I'd really love it if they would integrate with Gusto.  I was afraid that I would need to set up with Zoho Project and pay another service fee, but it looks -- at least so far from my trial, like this won't be necessary.

So my feature request is for integration with Gusto.  In the meantime, I'll probably just handle payroll expenses by manually copying the data from Gusto.

Conclusion


So many, so close, and yet nothing actually hits the mark.   (These aren't all the options I looked at, but they are the main contenders.  Some weren't offered in the US, or were too expensive, or self-hosted.  For now I'm going to try Zoho.  I will try to update this in a few months when I have more experience.

Tuesday, November 14, 2017

TLS close-notify .... what were they thinking?

Close-Notify Idiocy?


TLS (and presumably SSL) require that implementations send a special disconnect message, "close-notify", when closing a connection.  The precise language (from TLS v1.2) reads:

The client and the server must share knowledge that the connection is
ending in order to avoid a truncation attack. Either party may
initiate the exchange of closing messages. 
close_notify 
This message notifies the recipient that the sender will not send
any more messages on this connection. Note that as of TLS 1.1,
failure to properly close a connection no longer requires that a
session not be resumed. This is a change from TLS 1.0 to conform
with widespread implementation practice. 
Either party may initiate a close by sending a close_notify alert.
Any data received after a closure alert is ignored. 
Unless some other fatal alert has been transmitted, each party is
required to send a close_notify alert before closing the write side
of the connection. The other party MUST respond with a close_notify
alert of its own and close down the connection immediately,
discarding any pending writes. It is not required for the initiator
of the close to wait for the responding close_notify alert before
closing the read side of the connection.

This has to be one of the stupider designs I've seen.

The stated reason for this is to prevent a "truncation attack", where an attacker terminates the session by sending a clear-text disconnect (TCP FIN) message, presumably just before you log out of some sensitive service, say GMail.

The stupid thing here is that this is for WebApps that want to send a logout, and don't want to wait for confirmation that logout had occurred before sending confirmation to the user.  So this logout is unlike every other RPC.  What...?!?

Practical Exploit?


It's not even clear how one would use this attack to compromise a system... an attacker won't be able to hijack the actual TLS session unless they already pwned your encryption.  (In which case, game over, no need for truncation attacks.)  The idea in the truncation attack is that one side (the server?) still thinks the connection is alive, while the other (the browser?) thinks it is closed.  I guess this could be used to cause extra resource leaks on the server... but that's what keep-alives are for, right?

Bugs Everywhere


Of course, close-notify is the source of many bugs (pretty much none of them security critical) in TLS implementations.  Go ahead, Google... I'll wait...  Java, Microsoft, and many others have struggled in implementing this part of the RFC.

Even the TLS v1.1 authors recognized that "widespread implementation practice" is simply to ignore this part of the specification and close the TCP channel.

So you may be asking yourself, why don't implementations send the close-notify ... after all sending a single message seems pretty straight-forward and simple, right?

Semantic Overreach


Well, the thing is that on many occasions, the application is closing down.  Historically, operating systems would just close() their file descriptors on exit().  Even for long running applications, the quick way to abort a connection is ... close().  With no notification.  Application developers expect that close() is a non-blocking operation on network connections (and most everywhere else)1.

Guess what, you now cannot exit your application without sending this, without breaking the RFC.   That's right, this RFC changes the semantic of exit(2).  Whoa.

That's a little presumptive, dontcha think?

Requiring implementations to send this message means that now close() grows some kind of new semantic, where the application has to stop and wait for this to be delivered.  Which means TCP has to be flowing and healthy.  The only other RFC compliant behavior is to block and wait for it flow.

What happens if the other side is stuck, and doesn't read, leading to a TCP flow control condition?  You can't send the message, because the kernel TCP code won't accept it -- write() would block, and if you're in a non-blocking or event driven model, the event will simply never occur.  Your close() now blocks forever.

Defensively, you must insert a timeout somehow -- in violation of the RFC.  Otherwise your TCP session could block forever.  And now you have to contemplate how long to hold the channel open?  You've already decided (for whatever other reason) to abort the session, but you now have to wait a while ... how long is too long?  And meanwhile this open TCP sits around consuming buffer space, an open file descriptor, and perhaps other resources....

A Bit of Sanity


The sensible course of action, treating a connection abort for any reason as an implicit close notification, was simply "not considered" from what I can tell.

In my own application protocols, when using TLS, I may violate this RFC with prejudice. But then I also am not doing stupid things in the protocol like TCP connection reuse.  If you close the connection, all application state with that connection goes away.  Period.  Kind of ... logical, right?

Standards bodies be damned.

1. The exception here is historical tape devices, which might actually perform operations like rewinding the tape automatically upon close(). I think this semantic is probably lost in the mists of time for most of us.

Wednesday, November 8, 2017

CMake ExternalProject_add In Libraries

First off, I'm a developer of open source application libraries, some of which are fairly popular.

TLDR: Library developers should not use ExternalProject_Add, but instead rely on FindPackage, demanding that their downstream developers pre-install their dependencies.

I recently decided to try to add TLS v1.2 support to one of my messaging libraries, which is written in C and configured via CMake.



The best way for me to do this -- so I thought -- would be to add a dependency in my project using a sub project, bringing in a 3rd party (also open source) library -- Mbed TLS.

Now the Mbed TLS project is also configured by CMake, so you'd think this would be relatively straight-forward to include their work in my own.  You'd be mistaken.

CMake includes a capability for configuring external projects, even downloading their source code (or checking out the stuff via git) called ExternalProjects.

This looks super handy -- and it almost is.  (And for folks using CMake to build applications I'm sure this works out well indeed.)

Unfortunately, this facility needs a lot of work still -- it only runs at build time, not configuration time.

It also isn't immediately obvious that ExternalProject_Add() just creates the custom target, without making any dependencies upon that target.  I spent a number of hours trying to understand why my ExternalProject was not getting configured.  Hip hip hurray for CMake's amazing debugging facilities... notIt's sort of like trying to debug some bastard mix of m4, shell, and Python.  Hint, Add_Dependencies() is the clue you need, may this knowledge save you hours lack of it cost me.  Otherwise, enjoy the spaghetti.
Bon Apetit, CMake lovers!

So once you're configuring the dependent library, how are you going to link your own library against the dependent?

Well, if you're building an application, you just link (hopefully statically), have the link resolved at compile time, and forget about it forever more.

But if you're building a library the problem is harder.  You can't include the dependent library directly in your own.  There's no portable way to "merge" archive libraries or even dynamic libraries.

Basically, your consumers are going to be stuck having to link against the dependent libraries as well as your own (and in the right order too!)  You want to make this easier for folks, but you just can't. 
(My kingdom for a C equivalent to the Golang solution to this problem.  No wonder Pike et. al. got fed up with C and invented Go!)

And Gophers everywhere rejoiced!

Making matters worse, the actual library (or more, as in the aforementioned TLS software there are actually 3 separate libraries -- libmbedcrypto, libmbedx509, and libmbedtls) is located somewhere deeply nested in the build directory.   Your poor consumers are never gonna be able to figure it out.

There are two solutions:

a) Install the dependency as well as your own library (and tell users where it lives, perhaps via pkgconfig or somesuch).

b) Just forget about this and make users pre-install the dependency explicitly themselves, and pass the location to your configuration tool (CMake, autotools, etc.) explicitly.

Of these two, "a" is easier for end users -- as long as the application software doesn't also want to use functions in that library (perhaps linking against a *different* copy of the library).  If this happens, the problem can become kind of intractable to solve.

So, we basically punt, and make the user deal with this.  Which tests days for many systems is handled by packaging systems like debian, pkg-add, and brew.

After having worked in Go for so long (and admittedly in kernel software, which has none of these silly userland problems), the current state of affairs here in C is rather disappointing.

Does anyone out there have any other better ideas to handle this (I mean besides "develop in Y", where Y is some language besides C)?

Licensing... again....

Let me start by saying this... I hate the GPL.  Oh yeah, and a heads up, I am just a software engineer, and not a lawyer.  Having said that....

I've released software under the GPL, but I never will again.  Don't get me wrong, I love open source, but GPL's license terms are unaccountably toxic, creating an island that I am pretty sure that original GPL authors never intended.


My Problem....


So I started by wanting to contemplate a licensing change for a new library I'm working on, to move from the very loose and liberal MIT license, to something with a few characteristics I like -- namely patent protection and a "builtin" contributor agreement.   I'm speaking of course of the well-respected and well-regarded Apache License 2.0.

The problem is, I ran into a complete and utter roadblock.

I want my software to be maximally usable by as many folks as possible.

There is a large installed base of software released under the GPLv2.  (Often without the automatic upgrade clause.)

Now I'm not a big fan of "viral licenses" in general, but I get that folks want to have a copy-left that prevents folks from including their work in closed source projects.  I get it, and it's not an entirely unreasonable position to hold, even if I think it limits adoption of such licensed software.

My problem is, that the GPLv2's terms are incredibly strict, prohibiting any other license terms being applied by any other source in the project.  This means that you can't mix GPLv2 with pretty much anything else, except the very most permissive licenses.  The patent grant & protection clauses breaks GPLv2.  (In another older circumstance, the CDDL had similar issues which blocks ZFS from being distributed with the Linux kernel proper.  The CDDL also had a fairly benign choice-of-venue clause for legal action, which was also deemed incompatible to the GPLv2.)

So at the end of the day, GPLv2 freezes innovation and has limited my own actions because I would like to enable people who have GPLv2 libraries to use my libraries.  We even have an ideological agreement -- the FSF actually recommends the Apache License 2.0!  And yet I can't use it; I'm stuck with a very much inferior MIT license in order to let GPLv2 folks play in the pool.

Wait, you say, what about the GPLv3?  It fixed these incompatibilities, right?   Well, yeah, but then it went and added other constraints on use which are even more chilling than the GPLv2.  (The anti-Tivoization clause, which is one of the more bizarre things I've seen in any software license, applying only to equipment intended primarily "consumer premises".  What??)

The GPL is the FOSS movements worst enemy, in my opinion.  Sure, Linux is everywhere, but I believe that this is in spite of the GPLv2 license, rather than as a natural by product.  The same result could have been achieved under a liberal, or a file-based copyleft.

GPL in Support of Proprietary Ecosystems


In another turn of events, the GPL is now being used by commercial entities in a bait-and-switch.  In this scheme, they hook the developer on their work under the GPL.  But when the developer wants to add some kind of commercial capability and retain the source confidentially, the developer cannot do that -- unless the developer pays the original author a fee for a special commercial license.    For a typical example, have a look at the WolfSSL license page.

Now all that is fine and dandy legal as you please.  But, in this case, the GPL isn't being used to promote open source at all.  Instead, it has become an enabler for monetization of closed source, and frankly leads to a richer proprietary software ecosystem.  I don't think this was what the original GPL authors had intended.

Furthermore, because the author of this proprietary software needs to be able to relicense the code under commercial terms, they are very very unlikely to accept contributions from third parties (e.g. external developers) -- unless those contributors are willing to perform a copyright assignment or sign a contributor agreement giving the commercial entity very broad relicensing rights.

So instead of becoming an enabler for open collaboration, the GPL just becomes another tool in the pockets of commercial interests.

The GPL Needs to Die

If you love open source, and you want to enhance innovation, please, please don't license your stuff under GPL unless you have no other choice.  If you can relicense your work under other terms, please do so!  Look for a non-viral license with the patent protections needed for both your and your downstreams.  I recommend either the Mozilla Public License (if you need a copyleft on your own code), or the Apache License (which is liberal but offers better protections over BSD or MIT or similar alternatives.)