Living in a state of accord.

Modernising Our JavaScript – Supporting OpenSource

At LMAX, we’ve been using Vue.js for all our new JavaScript work very successfully for a while now. Our existing products used Vue.js for the logic but continued to use bootstrap as the component library to ensure the UI remained consistent.  For anything new though, we started using Vuetify to give us better UIs much more easily.

Vuetify is close to reaching it’s 1.0 release now and we’ve been using it for a while so when we first started with it, the vast majority of development and support was being done by the project founder, John Leider in his spare time. Migrating UI libraries is painful so having an early stage project without a lot of community (at the time) was a pretty big risk for us, but the code was excellent and John was obviously very committed to the project, being very responsive to bug reports and questions.  So LMAX jumped on board as a platinum supporter of Vuetify, making regular monthly payments to support Vuetify development.

It’s been a resounding success.

As a project, Vuetify has continued to grow – mostly because of the excellent work John was doing to build the community – giving more stability and now has multiple regular contributors. With the number of supporters also growing John quit his day job and is now focussed on Vuetify full-time. So our primary aim of supporting the viability and longevity of the project has worked out well.

We’ve also had secondary benefits. As part of being a platinum supporter the LMAX logo appears on the Vuetify site and we’ve set it up to link to our jobs site. It’s driven quite a lot of traffic that way and I think is actually the top source of traffic to our careers site.

I believe we also get some guaranteed support time as part of the package, but frankly John is so responsive I’m not sure if we’d actually notice the difference. We’re also keen to contribute code but the project is now moving along so well that stuff gets fixed for us before we get a chance to do it. It’s possible some of my colleague who are doing more with Vuetify have contributed some stuff, but every bug I’ve found has been fixed almost as soon as I can finish the bug report…

Overall, it’s been a huge success and well worth the money. I’d definitely encourage others to become financial backers of projects they depend on.

Open Source Is The New Shareware

There has been a trend over the past few years for open source projects to routinely ask for “donations” through a donate button on the site and increasingly in the software itself. I put “donations” in quotes because in the vast majority of cases these aren’t payments to a charitable organisation — they go straight into the pocket of the one and only developer.

Now it’s important to be clear, there are quite a number of open source organisations that are set up as actual charities or at least are independent organisations where the money donated actually goes towards the open source projects supported by that organisation. For example, when you donate to the Apache Software Foundation they use that money to pay for servers, bandwidth, legal advice the projects need, subsidising conferences around the projects and so on1. These are great places to donate your money or time to — they handle donations very professionally as the funds directly benefit the projects and ecosystem around the projects.

What bothers me are the projects which ask for donations but don’t have any way to keep the donations separate from the main contributors personal funds. That money isn’t going to the project, it’s going to the person — that’s not a donation. From the New Oxford American Dictionary:

donation |dōˈnā sh ən|


something that is given to a charity, esp. a sum of money : a tax-deductible donation of $200.

  • the action of donating something.

If someone asked you to donate to the poor and then pocketed the money you gave them, you’d be pretty annoyed — even if that person themselves was poor. On the other hand, if that person asked for money because they were poor, you’d expect them to pocket it. Why should we not expect the same honesty from open source developers?

What Do You Need Money for Anyway?

For small open source projects there are so many free services available that money really isn’t an issue. If you’re asking for donations to support your project, what exactly is that money going to be used for? How is that money going to further the project’s goals?

Bottom line, it’s not.

Between Sourceforge, Google Code, GitHub and a whole suite of others, small open source projects are very unlikely to require any kind of funding. At best it might contribute to the main developer buying a faster computer so they can be more productive, but is that really for this project or something they want for themselves? Again, it comes down to honesty – if the only computer they can afford hampers their productivity then upfront ask for donations towards a faster computer, it’s not only more honest, it’s also more compelling.

A More Honest Term

I have no problem with people asking for money as reward for their efforts developing software, that’s how I make my living. It doesn’t matter if the payment is optional or compulsory, what matters is that there’s honesty about what the payment is for.

The New Oxford American Dictionary can come to our aid here, since it includes a section under the term present about choosing the right word:


What's the difference between a birthday present and a Christmas gift ? Both words refer to something given as an expression of friendship, affection, esteem, etc.

But gift is a more formal term, often suggesting something of monetary value that is formally bestowed on an individual, group, or institution (: a gift to the university).

Present, on the other hand, implies something of less value that is an expression of goodwill (: a housewarming present; a present for the teacher).

Largesse is a somewhat pompous term for a very generous gift that is conferred in an ostentatious or condescending way, often on many recipients (: the king's largesse; the largesse of our government).

A gratuity is associated with tipping and other forms of voluntary compensation for special attention or service above and beyond what is included in a charge (: known for her generous gratuities, the duchess enjoyed watching the waiters compete with each other to serve her), while a lagniappe is a Southern word, used chiefly in Louisiana and southeast Texas, for either a gratuity or a small gift given to a customer along with a purchase.

If you give money or anything else as a gift to a philanthropic, charitable, or religious organization, it is known as a donation (: donations for the poor).

But if your employer gives you money at the end of the year in addition to your regular salary, it isn't a Christmas gift; it's a Christmas bonus.

Since we’re not giving to a philanthropic, charitable or religious organization, donation isn’t the word we want. Gift or present might be since mostly the monetary contribution is an expression of esteem. Importantly both terms imply that the receiver can do whatever they like with it, it’s not earmarked for a project in any way.

The best term in there however seems to be gratuity or the more colloquial tip. It’s recognition that someone has done something for you above and beyond what they charged you for. It also seems to be really getting at the heart of what I believe most people are after: encouragement. Having someone part with even a small amount of money is a very strong sign of appreciation, especially when it’s combined with a well-worded note rather than just money turning up in a PayPal account.

So perhaps going forward if you need money to support your open source project, provide some information about what the money will be used for and why it’s important to the project. If you just want to be rewarded for your hard work or encouraged, put out a virtual tip jar rather than a donation button.

1 – actually many of those types of services and even server hardware may be donated as well

A Big Forking Problem

Back when git and GitHub were relatively new to the mainstream, there was a big discussion about how it promoted forking and was potentially bad for community building. Since then GitHub has well and truly proven that it can successfully support significant community and very successful projects. Looking around GitHub though, it’s clear that not every project successfully builds community there and the tendency to fork can still become a problem.

The big difference that I see between projects thriving with GitHub and those where forking looks like more of a problem is that thriving projects have a “campfire” other than the source code for people to gather around. Often that’s a mailing list, other times it’s IRC and various other technologies but there’s always one common place where the community can build. GitHub by itself is unlikely to build up such a community because there isn’t a really good way to engage everyone in conversation. As such, you get a lot of forks and people making improvements, but not really working together and often the various forks never get folded back into the original.

The good news is that despite all the forks often remaining off on their own, it doesn’t seem to be detrimental to the original project. People find the main GitHub repository through other means, mostly links on the web, so there doesn’t seem to be confusion over which fork is the “main” one. On the other hand, most of those forks represent a wasted effort which could have pushed the project forward if only there had been some communication.

Finally, it’s interesting that the GitHub model of anyone creating a fork is far more successful for projects which don’t need a contributor agreement to be signed. In that case, any fork that looks promising can be pulled in without needing extra permissions, so even without the extra communication channel the effort can be utilised. With a contributor agreement, you have to reach out and get the author to sign, which is a significant barrier.

Open Core, Open Development and Co-location

It would be hard to have not noticed the on-going debate around “open core”. From what I can tell, it largely, but not completely, boils down to concerns about a product being called “open source” if the core that’s open source is generally unusable without the commercial-only additions. Mostly, people are ok with there being separate commercial-only plugins or tools provided so long as the open source product can stand alone and be useful and effective. Dave Neary hits on what I think is a key warning sign that a product is using a damaging open-core model:

And that’s what I think gets people riled up – if you’re releasing something as free software, then there should at least be the pretence that you are giving the community the opportunity to fend for itself – even if that is by providing an “unofficial” git tree where the community can code up GPL features competing with your commercial offering, or a nice forum for people to share templates, themes and extensions and fend for themselves. But what gets people riled is hearing a company call themselves “an Open Source company” when most of the users of their “open source” product do not have software freedom.

The open source definition is all about what license is being used for the software, but the effectiveness of something being open source is at least equally affected by the development model in use. The ability for anyone to jump in and contribute to the project reasonably easily is what drives extra innovation and enables the development investment to be spread among many users of the software. Having access to the source code and the ability to modify it yourself is useful to avoid lock-in, but maintaining the entire software is generally too expensive to be worthwhile for users – it’s cheaper to incur the costs of switching to another product instead.

What Dave Neary’s paragraph above starts to move towards is looking for a product that uses open development rather than just open source. Bertrand Delacrétaz wrote up how we work at Apache recently and it’s a great model of things to look for in open development1. In particular Apache lives and dies by the first item: “All technical discussions and decisions on public mailing lists” or as I’ve often heard it put, “if it didn’t happen on the mailing list, it didn’t happen”. Unless all discussions wind up happening in a public forum, be it a mailing list, forum, wiki, wave or whatever, it’s unlikely that open development will be possible2.

So all of this leads me to a somewhat unexpected realisation: any open source company that insists on having all its developers colocated is failing to do open development effectively. If your employees can’t develop effectively from remote locations, how can you possibly expect to benefit from significant community contributions?

Anyone have examples of companies using exclusively co-located developers but still fostering an open development model?

1 – of course there are other approaches to open development, but few are as well articulated as the Apache way these days.

2 – Apache does use face to face meet-ups, but they make a point of keeping the mailing list in the loop about what was discussed there so everyone can still be involved

Ephox Enterprise TinyMCE

The new Ephox Enterprise TinyMCE site has now gone live, a result of our new partnership with Moxiecode, the company behind everyone’s favorite open source editor TinyMCE. I’m really excited about the potential of this partnership and have really enjoyed the opportunity to work with the Moxiecode team so far.

What We’re Adding…

We think we can bring a lot to the TinyMCE community, the things below are just where we’re starting.

Enterprise Grade Support

We’re really proud of the level of support we’ve been able to offer for EditLive! and we’re bringing that over to TinyMCE. TinyMCE gets used in all kinds of mission critical systems where down time costs real money. Ephox’s support packages offer service level agreements to ensure you get help quickly and keep things running smoothly.

More Resources for TinyMCE

Ephox is dedicating resources to help develop TinyMCE, improve it’s quality, answer questions on the forums (even for the free LGPL version) and generally help make TinyMCE even better.

We’ve already had a number of patches accepted into the main TinyMCE branch and are using our build farm to run TinyMCE’s tests across a wide range of browsers and platforms to help the Moxiecode team keep quality levels high (check out the results here). You’ll also see Ephox folk popping up in places like the TinyMCE forums to answer TinyMCE questions.

Quick and Easy Commercial Licensing

If you don’t want to distribute changes you make to TinyMCE under the LGPL or prefer a more traditional commercial software license for whatever reason, you can quickly and easily buy one straight from our web store, with our without a support package.

Express Edit

We’re currently working to update our “Express Edit” feature of EditLive! to make it simple to integrate both EditLive! and TinyMCE with the same set of APIs and have the most appropriate editor for the situation load. Express Edit has been around for a while, but with the power of TinyMCE we think it’s time has really come to shine. With Express Edit you can offer all the advanced features of EditLive! but know that if Java isn’t available or you just need a lightning fast editor to make a quick change you’re users will have TinyMCE available too. Basically, you get the best possible editor for any situation.

Committed To…

In case you were worried there’s a few things that we’re absolutely committed to:


We still see EditLive! as being Microsoft Word for the web. It’s a full featured, enterprise editor that dramatically improves author productivity and assists them in creating higher quality content. EditLive! has been the leading online editor for many years now and we are going to continue improving it as fast as we can. There’s plenty of great stuff coming down the pipeline for EditLive! including of course an improved Express Edit.

Open Source

Ephox as a company may not have had much to do with open source in the past, but most of the people working for Ephox have and we’re big fans. Now we get the privilege of working with the vast TinyMCE community and that’s really exciting.

Most importantly, TinyMCE is absolutely still available under the LGPL, Ephox is even providing a direct download link from our site to ensure everyone knows they are quite welcome to take TinyMCE and use it for free. The only difference between the LGPL community edition download and the commercially licensed options we’re providing is the license information.


Ephox and Moxiecode are working together closely on this venture. Ephox Enterprise TinyMCE is a distribution of TinyMCE, much like projects such as Debian include other open source products. Like Linux distributions we may find and need to fix problems with TinyMCE which causes our distribution to vary slightly until those changes can flow back upstream. To avoid any confusion, Ephox distributions of TinyMCE have an extra component to the version number, for example the current TinyMCE release is 3.3.6, so the current Ephox distribution is 3.3.6-170. This makes it clear which base version of TinyMCE is being used, that it’s been modified (even if only to add our naming) and which build from Ephox it is.

We’ve also called our distribution “Ephox Enterprise TinyMCE”, this is mostly a marketing thing but again it helps to avoid confusion in case there are fixes in our build that haven’t yet made it back upstream.

Questions? Comments?

If you have any questions, concerns or comments feel free to post them below or get in touch with me directly at or by phone on +44 7 525 806 170 and I’ll do my best to get you an answer.