Open Source for a Startup (the Good, the Bad and the Ugly)
Build vs buy — the usual dilemma of large companies when it comes to new product development. An engineering team needs to either build everything from in-house or use some middleware that can theoretically speed up the development. Such middleware usually comes in purely commercial (technology license purchase) as well as in open source forms.
As a tech startup, you usually don’t have a luxury of building everything from scratch (despite an enormous appeal of such option to any engineer) and need to rely a lot on 3rd party middleware. With the initial absence of cash, it usually means relying a lot on open source.
The following list is an example of the tools that worked great, not so great or become a bottleneck during the development of Eliademy — a platform for teachers to create online courses. It might be different for a different product.
The Good
Twitter Bootstrap
We didn’t have a much time to create various buttons and dropdowns, nor implement them from scratch and make sure they work on all possible browsers. We decided to choose Bootstrap — and it worked brilliantly. You get most of the components any web page needs in a single CSS file, excellent cross-browser support, an extremely robust theming option and responsiveness out of the box. It is also distributed under the “least restrictive” MIT license. The only downside is a substantial change in class naming from v2 to v3 which requires quite a lot manual work for migration.
CKEditor
The core of Eliademy is the content teachers create. We started with our own home-grown simple HTML editor but very soon realized it would be quite a task to keep up with all feature request, let alone infamous browser compatibility. Along plethora of various web-editor middleware, CKEditor really stood out with its inline option — a way remove fixed toolbar entirely and show it depending on user’s context action. It also has an incredible amount of various plugins (full-fledged LaTeX support or media URL parsing), very lightweight, reliable and easy to maintain.
I’d still prefer us to own completely user experience (like Medium or Evernote do), but with a “free” price tag a major update every 6 months it is arguably the best open source tool I have used.
The Bad
Bugzilla
We needed a simple backlog/issue tracking tool and were reluctant on investing into one of many tools out there. After 4 years we still host our own instance of Bugzilla, but while it worked quite well as issue tracking tool it is pretty terrible when it comes to sprint planning (it is not intended to be used this way at all). Also, it is in development from 1998 and age really shows. Forget about drag and drop for file attachments, simple commenting system, user mentions or a clean UX. It is passable for startups but takes the time to get used to.
Pootle
I got an idea to host our own crowdsourcing localization service from Evernote who used slightly modified version Pootle. Sadly there is not that much of a competition in the “free” category so the choice was clear. Translate.eliademy.com become the core of our volunteering community but it requires a large amount of maintenance. There is no straighformward integration with existing userbase (user still needs to register a separate account), almost no community management features (aside from admin setting overall permissions) and extremely slow update cycle. It works, but I’d wish for a much better system.
Moodle
An idea to create an e-learning platform wich would be compatible with over 9 million of existing online courses was certainly great to start with. However, we wanted a decent user experience and opted out for a single page application written entirely in JavaScript. This meant the only way we can ensure compatibility is to use Moodle’s backend, which at the time was not exactly ready for such model. Existing web services API was extremely badly designed (a login call would pull all courses list along with course content) and didn’t support any caching needed for a really scalable system (in Moodle’s team defense, the average installation has 10–20 thousand registered users at most).
Writing layers of optimization and web services APIs took the substantial amount of time, in some cases well exceeding time needed to build the same functionality from scratch. Some of the works we did were released as an open source in return.
The Ugly
Kaltura Community Edition
We needed a subsystem to host private user videos, and Kaltura was chosen as the most “feature rich” solution. Sadly, one must remember that there is a big difference between a community edition and a commercial service Kaltura is offering. The former is a functioning video hosting/converting system but almost entirely lacks any admin functionality. There is no way to see all uploaded videos (which makes debugging/user support a nightmare), conversion batch, statistics or set up transcoder options. It is full of really strange limitations — you need to setup a custom Cron job to clean up DB when a video is deleted by a user, keep your eye on conversion batch etc. Worst of all it occasionally rejects uploaded videos (especially low bitrate ones — like recordings of a PowerPoint presentation) without much of debug info.
Verdict — usable for “enterprise YouTube” applications, bad for ed tech startups.
Big Blue Button
Even though we were developing an e-learning platform we wanted to give a video conferencing/screen sharing option to all teachers (it became especially needed with Google shutting out free Helpouts in early 2015). Moodle and Big Blue Button were a frequent combination used by many campuses, thus it sounded as good idea to use the same familiar technology for the teacher.
It works in general, but has one giant problem, it severely outdated. Frontend is written in ActionScript (read Flash), which rules out all mobile users and occasionally causes camera/mic problems. It was still “acceptable” in 2014, but not turned into a real problem. Client session also runs in a separate UI/window which is pretty much impossible to customize aside of slapping your logo — forget about clean UX.
Verdict — stay clear and use any WebRTC based solution.
Magento Community Edition
An option to charge for courses naturally needed a product description web page, integration with a payment method and some simple cataloging interface. The idea to use Magento as frontend Webstore seems very logical.
There were quite a few issues on integration — we had to make few really ugly solution to remove the concept of the “shopping cart” (no one buys courses in bulk) or work with any usual startup payment providers like Braintree or Strype. It is also not designed to support language change on the fly, instead, you are supposed to create various locale stores and relist products for each locale. The worst part though is a stark difference between community and enterprise versions. Do you need simple purchase reporting with VAT breakdown or an option to prevent spamming product reviews? Forget about it or start paying.
Verdict — we end up building lots of additional functionality on our own backend and as a result planning to phase Magento out completely in the next major product update. If you are building a web show for physical goods — maybe, for e-learning marketplace community edition is a very poor choice.
An unsolicited piece of advice for a startup CTO — keep in mind that open source does not necessary mean free. Even though code comes for free, it has all sorts costs:
- integration cost — time spent on making your product work with open source components
- maintenance costs — time spent on upgrading 3rd party components and fixing bugs that usually appear right after that
- license limitation cost — each added component requires to be compatible with your business model and other components
Make sure you understand and communicate most of long-term limitations and drawbacks it will bring. Sometimes, after a proper analysis, building your own components is not such a terrible idea after all. On the other hand, very frequently you have a risk on reinventing a bicycle, so keep an eye on all possible middleware options out there. Some of them can save you lots of time and become the core of your own product.
P.S. To understand the various licensing issues I highly recommend a free online course by the father of free software movement Richard Stallman.
