Tag Archives: Open source

Does your LMS play nicely with others?

With the recent release of Learn with Mobile’s latest RESTful and webhook APIs, I found myself feeling very grateful that open interoperability and integration have started to become standard practice for leading cloud service providers.

Yes there is still software in every industry where its vendor continues to refuse to play nicely with others.  If you work in a large company or SME its probable that your LMS still fits this category, even if it’s only a few years old. But leading newer services all seem to understand the value of sharing and being open with each other.

Sharing and APIs have become a “must have” feature for the L&D thought leaders that will guide learning software choices in the next few years.  But with so many large providers in the learning industry still lagging behind, it’s worth sharing some history that helps us understand the risk of accepting this behaviour.

It’s not so many years ago software industry giants almost succeeded in taking this openness and opportunities away from not only learners, but all businesses as IT started to grow in its impact.  We all need to learn from past mistake to empower those who will be creating the future.

An explosion of choice

It’s fair to say world is full of apps.  Just between Google’s Play Store and Apple’s AppStore there are now more than 5 million apps available for you to choose from that can do everything from keeping you connected with friends, to ordering your pizza.

Likewise, over the last decade we have also seen an explosion in online cloud services as a replacement for traditional software for both business and individuals, many of which provide free options for personal or small business use.

The combined effect of these two trends have had on software in the last ten years cannot be overstated.  Between them they have helped to return our use of technology to its roots where everything is designed to do one job, but sets out to do it really well.

In theory now, we can always choose the best tools to solve each problem or goal we have.  But this only works if everybody plays nicely together.

Like children we all started by playing nicely

There has never been a time in technology where it’s been more important for everyone in the technology playground to play nicely together.  What may surprise you though is that this is not a new problem at all.  In fact it’s a problem Ken Thompson and Dennis Ritchie had already solved in 1969 as they were working on one of the most influence technologies of all time: Unix.

The theory used in the design of each app in Unix was remarkably similar to the design of today’s apps and cloud services: do one job really well, and then share with others so they can pick up where we left off.

In Unix the sharing was done through pipes and streams, now days apps share through RESTful APIs, and web hooks, but the core principles of well behaved software is the same.  Unfortunately we had to go through decades of badly behaved companies who didn’t want to share, before we could get back here again.

If you first got involved with PCs in the ’90s or 2000s it may be hard to believe that all software started off in such a friendly environment.  But software has its origins in an environment where everybody listened to one another, built on each other’s ideas, and everybody would always play with anybody else.  Much like young children in a playground, the only things that really mattered was if we were going to have fun while working together.

Playground bullies and the teenage years

As the IT industry matured and PCs started appearing offices, houses, and homes, software hit what is probably best described as its teenage years.

Large technology companies started to create huge pieces of software that did too much.  Software that didn’t focus on doing a single task well, but rather on doing lots of things, just about OK.  The idea here was simple, if we do lots of things OK, people will start to rely on us for everything.  Once they start using us for stock, they will have no choice but to use us for their order processing, and their accounts, and… Or once they start using us for HR they’ll also have to use us for e-learning, and facility management, and…

Why would anybody use an “OK” service if a great service was available as an alternative?  Well most of this software started off by being really good at just one thing.  But vendors started to bolt on additions that were at best “OK” and at worst unusable.   Before long like a teenager, applications from major vendors stopped talking to everyone that wasn’t in their friendship group.  The once open sharing became replaced with grunts, groans, and gestures and simple refusal to communicate or share anything with anyone.  The goal for companies selling software was that once you had committed to one solution from a vendor you were locked in to them.  No longer could you choose the best tool for the job and have everybody get along.  Now you simply had two choices: use your existing vendor for everything, or pay somebody to input and manage all your data (at least) twice so you had the right information in each piece of software you used.  Commercially for those producing the software, this plan worked well in the short term and a lot of money was made.  For everyone else in business though it meant IT become nothing but a growing headache with its unsatisfied demand for more money.

It’s was these teenage years that created giants such as SAP, Microsoft, Sage, and similar large companies many of which went on to face anti-trust cases throughout the world.  They controlled our HR, our Office Suites, our ERPs and CRMs, our accounts, our learning, and they wouldn’t even work with each other, never mind with anyone else

As the internet gained more attention, other companies started to pop up with friendly pubic images, such as Google, Facebook, and a re-vamped Apple, that spoke nicely about “playing with others” but only if you played the games they wanted, how they wanted you to, and you let them control your data and every aspect of the game.

Whether an old-style bully that kept demanding more and more of your lunch money, or a new style one that was friendly as long as you did what they asked, and then shared your secrets behind your back; these IT companies managed to hurt all industries at a time where technology should have been enabling people, not restricting them.

By actively choosing to refuse to work with anyone else, the giants of the IT industry took away consumer choice and created a set of playground rules that still cause problems and impact productivity in many businesses today.

The situation got so bad that the open source movement organised itself as a world-wide activism to fight against these trends and create software built on openness and sharing.  I, like many others, poured countless hours year after year into open source.  We shared a genuine concern that consumer choice and freedom was it risk, and if we did nothing would be entirely removed from technology within only a few years.  We started driven by fear, but became empowered by sharing.  We thrived on each other’s ideas.  We knew we could make a difference by working together.  We wanted to ensure the idea of technology that was open and shared with others never died out.

Reaching adulthood and Restoring Choice

As software reached its adult years, empowered by the surge in internet usage, and the renewed focus on sharing from open source as its activists entered businesses, people started demanding technology that worked together again.  An environment where small companies with big ideas to could start succeed was created.  People started to talk to each other and provide services designed to do one thing, really, really, well again.

In this more friendly environment ideas started to snowball.  Changes took hold that led to todays 5 million plus apps and numberless cloud services.  More importantly these changes once again restored genuine choice to both businesses and individuals on how to use technology.

Championed by services such as Xero, Salesforce.com, and Learn with Mobile.  Great software that does one thing really well again, has for a few years now even started to disrupt industries previously dominated by bullies.  With modern services using open RESTful APIs, easy to use web hooks, to talk to each other.  A new attitude has emerged that sees sharing and interacting with each other as a feature, not a risk.

There’s even websites such as “If this then that” (https://ifttt.com/) that exist simply to connect all these friendly services together in a way that works exactly how you want it.  Personalised experiences are becoming the norm.

Some of the giants have started to react by being more open and playing nicely again.  Microsoft is a great example of a bully company that has turned around not only its image but also its behaviour and services.  Once an example of the worst behaviour in IT, it is now an example for good to others who were once its peers in the playground.  But not everyone wants to change, and it’s going to take a long time for all of the giants to do make the transition into the new reality.

What does it mean for me?

Whether your looking at software to solve your learner’s next problem, improve your business performance, create a coaching culture, replace your LMS, or really looking into any software or service, you should ask potential vendors one key question “how well does this play with others?”  People will be used to this question by now, so it shouldn’t surprise anyone.  The historical giants are falling way behind others in this support.  But what should you do if the service you are looking at doesn’t provide an open API for others to integrate with? Simply move on and find something that does!

Even if the unfriendly software has a killer feature or two, if it won’t talk to others you will end up severely limiting your vender choice and wasting a lot of money.  What’s worse, by getting locked in you’ll find yourself falling ever further behind your competition in the years to come.  Far better to find a service that does almost everything you want well and invest in working with them to create a better alternative to that killer feature than to get locked in all over again.

That’s what the thought leaders in software recommend.  It’s what the thought leaders in L&D recommend.  And the same advice is finally being heard from thought leaders in all industries.

Technology, like good learning, should empower, not restrict.

The Open Source vs Commercial Development Myth

The two can Co-Exist

Looking around the internet you could believe that open source software development, and commercial software development, are opposing forces that can never meet or work well together.  All experienced software developers know this is simply untrue, and yet the myth seems to perpetuate anyway.

By being careful, and being keeping with the spirit of the freedoms represented by the open source community.  It is possible for open source developments to benefit commercial software, and commercial developments to benefit open source software.  In the almost two dacades that I’ve now been involved in software development both open source and commercial;  I have never found a conflict between the two ideals that couldn’t be solved in a way that helped everyone.

Understanding the Types of Open Source License

The first thing you need to understand is that not all open source licenses are equal.  There are primarily two kinds of open source: copyleft and permissive.  For commercial software development I find it easy to divide the copyleft licenses into “strong copyleft” and “weak copyleft”.  Let me cover the three categories briefly here:

Strong Copyleft

When a software system or library is placed under a Strong Copyleft licenses the author is indicating two things:

  1. He wants others to be able to use the code he has produced.
  2. He feels the code produced has value enough to ask others to share their own changes to the code and share systems using the code under the same terms.

The most prominent Strong Copyleft licenses are: GPLv2 and GPLv3.

Strong Copyleft licenses are sometimes described as having a “viral” affect.  This is due to the fact that any derived work has to be distributed under the same license terms.  In the spirit of the license a derived work is usually intended to include software that references or links to Strong Copyleft software libraries as well as altered versions of the original.  This means for example you can only use GPL code in your commercial application, if you are happy to now distribute your commercial application under the terms of the GPL.

Personally I would describe Strong Copyleft licenses as the least friendly for commercial software development and many commercial development companies have to avoid it to meet the IP desires of customers and business owners wanting software developed.

Weak Copyleft

When a software system or library is placed under a Weak Copyleft licenses the author is indicating three things:

  1. He wants others to be able to use the code he has produced.
  2. He feels the code produced has value enough to ask others to share their own changes to the code under the same terms.
  3. He is happy for the library to be used in closed-source products.

Weak Copyleft licenses are most often used for libraries.  The author wants bug fixes and enhancements added back to the library so it can continue to improve, but doesn’t care about how you license the software that utilises the library.

The most prominent Weak Copyleft licenses are LGPLv2.1, LGPLv3, MPL, and MS-PL.

Weak Copyleft licenses are mostly about encouraging you to share fixes and enhancements to core functionality and keeping those fixes and enhancements “free”.  It does not generally have the same “viral” affect as strong copyleft licenses because software that references or links to weak copyleft software libraries as not intended to be considered derived works.  This means you can use LGPL code in your commercial application, and distribute your main software under any license you want, however any changes you make to the copyleft library must be distributed under the original copyleft license.

Personally I would describe Weak Copyleft licenses as very friendly to commercial software development.  It encourages you to get benefit from somebody else’s effort, and simply asks for improvements to be shared in return.


When a software system or library is placed under a permissive licenses the author is indicating three things:

  1. He wants others to be able to use the code he has produced.
  2. He’d like some credit for the work he has put in.
  3. He is happy for the code to be used in any future open source or closed source application.

The most prominent permissive licenses are BSD, MIT, and Apache.

Permissive licenses are about preventing wasted effort while people to reinvent the wheel.  The functionality of the code is shared freely for open source or commercial use.  There is no “viral” affect, and you do not need to contribute changes back to the original author or project team, although this doesn’t mean you shouldn’t.

Personally I would describe Permissive licenses as very friendly to commercial software development.  It encourages you to get benefit from somebody else’s existing effort rather than wasting time reproducing the same functionality.  In exchange usually all that is asked for is acknowledgement of the codes origins.

Keeping the Spirit of the Original License Choice

Its important to understand that open source licenses work within the restrictions of the existing copyright framework.  This differs slightly country to country, and generally only forms contracts between people code or software is “distributed” to.  If you are not careful you can get caught up in questions of “can I do this with license X?” or comments “I don’t have to do that because license Y says you are not entitled to it”.  This is not what the open source community is about.  I believe that as well as keeping to the letter of the licenses, you should honour the spirit of the license regardless of the “additional rights” awarded by copyright laws in your country.

If you take a GPL library you want to use, and try and come up with ways to use the software “indirectly” to avoid putting your own code under the GPL, stop and think again.  The code you want to use was shared by the author because he wanted to see enhancements to it shared too.  You may not want to share your innovations., you may not like the GPL.  But that was the intention of the author and you should honour it or choose not to use the GPL code.

Likewise don’t think that because you upload copyleft software you developed to a web server you didn’t “distribute” it so you can keep the source closed.  And don’t create a “wrapper library” around an LGPL library where you add your new functionality so you don’t have to share it.  This isn’t the intention of the author when they let you use their code, and you shouldn’t abuse their intentions for your own gain.

If a product is dual licensed under copyleft and non-copyleft licenses, don’t constantly push the boundaries of what you can do with the copyleft version, contribute to the funding of the library or software by buying a license so it can continue to improve.

Giving Back

There are many ways to give back to the open source community as an commercial software developer.  Some are really simple but under commercial pressures are often ignored.

1. If you fix a bug in a library, no matter what license its under, submit the change back to the author or project team.

2. If you make minor enhancements that are generically useful, submit them back to the author or project team.

3. Don’t contribute incomplete changes or changes specific for your needs only back to the author or project team. These changes usually carry no reusable value and can waste the project’s time tidying them up for inclusion.

4. If you create a library or tool because you couldn’t find the one you needed in the market, and its not something you are wanting to commercialise on its own, make it available under an open source license you are comfortable with so others don’t have to repeat your effort.

5. If you create a useful program, library, or tool; consider duel licensing a “community” edition under a copyleft license.  Yes its true some developers and organisations won’t honour the license, but generally those people would have broken your commercial license terms if they had a chance too.  This dual licensing can be particularly useful for libraries as it can attract the attention students and others keen to learn your libraries or software, and this can in time become a major source of paid license users in the future.

6. Even if you are working on an open source project, don’t change the license of code from permissive to copyleft by adding enhancements and fixes under your project’s copyleft license rather than the original permissive license.  This practice has long been a point of contention between advocates of permissive licenses and those using their code in copyleft projects.  The overall project can still be copyleft, while honouring the spirit of the license for permissive code you use and giving back under the same license.

Commit Pitfalls

Here are a few of the pitfalls that can happen if you’re not careful combining open source software with commercial software products.

1. When you use an open source library don’t assume the author will carry on enhancing it in the future, and don’t assume someone else will fix the bugs.  Many open source projects are maintained in people spare time, and so every day some projects go stale as project teams move away, or change direction.  If you use an open source library in your commercial product, remember that you must plan to be able to maintain it in the future.

2. Always check the license before using an open source library.  Is it compatible with the IP requirements of you and your customers?  Does it have an explicit non-commercial use clause?  Its even worth checking this if you think you “know” the license the project is under.  Its not uncommon for exceptions or additional clauses to be added on top of standard licenses.

3. Don’t expect you can open source a dying product to “hand over” maintenance of it a community.  Be aware that the original author or team of an open source product, always end up the major contributors to that project long term.

4. Don’t assume because you didn’t pay for something, its cost is zero.  You still need to integrate the software or library into your solution, and you still need to train developers on its code base so you can maintain it within your SLAs.

5. Don’t dismiss a GPL library until you’ve checked the license.  Some projects prefer the use of the GPL over the LGPL but add explicit exceptions for the linking of close-source software.


Open source and commercial software can benefit each other, even if their license terms sometimes seem contradictory.  By following the license requirements, and keeping with the spirit that caused the author to open source their software in the first place, the open source projects can benefit from bug fixes and enhancements from commercial users of their software.

Closed source commercial software can benefit by using stable versions of open source libraries reducing development times and potentially delivering a richer experience.

Both open source and commercial users benefit from a dual licensing scheme where it is appropriate, with the larger user base providing a useful support and learning network, as well as a pattern of many active open source users progressing to paid services in the future.

The small print: I’m not a lawyer so please take this article as me sharing my experience as an open source and commercial software developer rather than legal advice about licenses and copyright law.