Open Source companies are the more innovative marketeers

When you look who is pioneering innovative new marketing approaches and technologies you will often find Open Source companies being on top of the list. That’s not by accident. Open Source companies have much less budget to promote their products compared to their traditional commercial competitors. So they are forced spend the money wiser and come up with new and better ideas. If you look for example at the reference lists of marketing automation SaaS platforms such as Marketo, Market2Lead, Silverpop, Loopfuse or Eloqua you will find many Open Source company on these. Sadly enough there’s no really usable open source technology out there to do marketing automation despite the fact that some of the mentioned SaaS players do actually use Open Source technologies to quite some extent. But that’s maybe a niche to be filled by somebody? Anyway, Open Source companies are not only leading when it’s about applying marketing automation but also along other modern techniques such as content syndication, leveraging SlideShare, YouTube, Twitter or social networks such as LinkedIn and Facebook. So if you are looking for good ideas on how to do marketing, many Enterprise may be well advised to look at how Open Source companies do these things.(Comment: For our German language visitors interested in innovative web marketing techniques and approaches there’s a good introduction white paper available. For the English speaking audience the SaaS vendors mentioned above do provide good information)

Do Enterprises bother too much about legal issues around Open Source?

Enterprises are quite worried about Open Source license models and potential legal issues. I have been talking to companies that claimed to not use any GPL type software because of the viral nature of the license. Others have decided to install complex processes to make sure that every license is understood and all consequences checked. Do Enterprises bother too much here? Many probably could take it a bit easier given that most use is really use, very few companies actually alter the software they download. And even if they did, it still wouldn’t be an issue as long as the software is not redistributed. There may be situations in international companies with many subsidiaries and legal entities, where “distribution” could become an issue even inside the enterprise, but this occasions are rare and shouldn’t be the reason for banning GPL. Many companies are also afraid to publish software (or software changes) because of the potential liability claims, but there are ways around this too. So, if your Enterprise doesn’t use Open Source for purely legal issues, it may be right to ask a second (or third) time before giving in.

Consolidation in the Open Source Directory landscape

SourceForge is acquiring Ohloh. Two of the largest and most prominent Open Source directories go together. That’s good and bad, as always. Ohloh has followed many innovative paths to generate interesting data and information around open source projects. They picked Ruby on Rails as their programming environment and probably were one of the show cases for Ruby with this. They had open APIs very early. I liked what they were doing a lot. SourceForge on the other side is sort of the father of all Open Source directories. They were very early and probably the most complete directory of them all. Bringing the two together could be an opportunity but also a bit of a threat, especially to Ohloh. Will they be able to continue to innovate? We will see.For EOS Directory this recent acquisition doesn’t really mean a big change. While both SourceForge and Ohloh tried to cover pretty much the whole space of Open Source EOS is very focused on the most enterprise ready technologies and on the Enterprise user.

Has Open Source really won?

The Economist has posted yesterday that “open source software has won the argument“.Others, for example Matthew Aslett expanded on this thought and asked additional questions, i.e. where to go from here.In my eyes this is not really about war and winning, it’s more about finding a well thought through co-existence of proprietary and Open Source software. It’s about industrializing software production, i.e. making the development process more effective and efficient. And it’s about broadening access to good software for everybody. There are good reasons for inventors and clever engineers to publish their work as proprietary software and generating some return for their hard work. And there are good reasons for opening commodity technologies and for leveraging the distribution power of the Open Source approach. I always stated that the future will bring co-existence of both worlds and this seems where we are heading too. Good for us.One caveat though: As it has recently been discussed there is still often no fair competition between commercial vendors and Open Source solutions. The case of Switzerland where a big Microsoft deal was closed without even looking at (Open Source) alternatives is an example. So, maybe the “war” is still not won?

Open Source for Enterprises – who does the work?

Enterprises are used to purchase software following a standardized procurement process. This process is supported by commercial vendors by supplying information, answering RFPs, sending materials, providing free support, delivering proof-of-concepts. etc. When an Enterprise turns to Open Source, many of these things are not granted anymore, especially when you are dealing with community supported software. The illustration below compares a typical Open Source community, a commercial Open Source vendor and a traditional commercial software vendor along the services typically requested by enterprise.

Enterprise Open Source - who does the work?

What can be easily seen is that Enterprises must change their attitude a lot if they really want to deal with true Open Source communities. As not all of the Enterprises are willing to do so, an interesting market for “commercial Open Source” vendors has been enabled. These commercial Open Source vendors such as SugarCRM, Alfresco, SpringSource, etc. close the gap between what a traditional commercial vendor is offering and what a community is able to do. It comes with a price of course, but still is very attractive, especially when Open Source elements and commercial elements are combined in a good way.

What makes an Open Source software Enterprise ready?

EOS Directory is all about Enterprise ready Open Source software. And of course we have documented our criteria for the individual ratings on this site. But let’s take on step back and rethink what makes a project/software actually Enterprise ready. Of course different companies have different opinions but there’s quite a bit of consensus what is important:

  • The software must be of high quality, reliable, scalable, etc. So all (most) of the traditional qualities must be fulfilled. That’s all about software engineering.
  • There must be enough usage of the software to “guarantee” survival of the technology for the foreseeable time
  • The software must be well documented, both in separate documents as well as in the code. There are companies who only use Open Source software, if there’s at least a book published on it
  • There must be a vibrant community of a significant size behind the software. In some cases this community may be replaced by a company that would have to fulfill at least the minimum criteria in terms of size and financial viability. Here Enterprises are often forced to make compromises.
  • The community (or company) governance is transparent and state-of-the-art methodologies, approaches and principles are applied when developing and maintaining the software. Many enterprises love the Apache Foundation for its strict set of rules here.
  • There should be at least some market for professional support and integration services around the project. Ideally this market is where the Enterprise using the software is situated.
  • The software is written in a programming language and using components and frameworks that are long term viable and ideally a standard in themselves. Many enterprises prefer Java based open source software and there are some where PHP is a no go.
  • The license model applied is compatible with Enterprise usage and allows for enough freedom to not restrict the Enterprise in its development and business strategies.
  • The functionality and features must be good enough to meet Enterprise standards. This includes security features, user experience and everything else you expect from software.

These criteria are representing quite a high bar and many Open Source project probably would fail in one area or the other. It’s though much easier to make a compromise when you can influence the roadmap or even the software itself. And here’s a true advantage of Open Source against proprietary software that by the way should meet most of the same critera and doesn’t in many cases.

How large are Open Source Product Development Teams?

It’s a well known secret that (commercial) Open Source companies are quite small compared with their more traditional competitors. Company sizes of less than 100 people are common, some of the companies even don’t reach the twenties. And with this staff they need to do quite a lot, i.e. marketing, sales, support, strategy, and of course, product development. When looking at the core teams of even sizable software products it may astonish with how little manpower the development can be done. This is only partially because of Open Source. Yes, of course, it helps that you can use existing modules and frameworks and you don’t have to reinvent infrastructure type code. But what is even more important is the fact that many of these products and platforms developed are new, with little legacy and progress can be made quicker therefore. Modern software development environments are a further plus (i.e. continuous integration and testing) and the methodologies applied as well. What it comes down to is that two or three people together can come up with an impressive technology in few months and further progress after version 1.0 is staggering at least for some times. It’s only after a couple of releases when more traditional problems like the need for downward compatibility, migration paths, etc. start to influence development efficiency in a negative way. Many of the today leading Open Source technologies (be it CRM, CMS or BI and Systems Management solutions) have initially been developed by usually less than a handful people. And of course these small teams have had it much easier to coordinate things and agree on directions.There is a downside to all of this too of course. – The dependency to the individual contributors is significant and often Open Source projects fall apart when a key member of the development team leaves (or forks the code). But thanks to the nature of Open Source it’s still possible to base new developments on the existing source code.

Is forking Nagios good for the Enterprise?

As it has been discussed already quite widely (e.g. on the 451 CAOS blog) Nagios has been forked. The new project has been called Icinga and a nice website has been published. Of course this has stimulated some more discussions on whether a fork is actually a good thing or a bad thing. And as always there are good and bad aspects of such an event. I will not repeat the arguments here, but it’s certainly valuable to read the different opinions of people involved including one of the key developers of the projects.What is clear is that while creating awareness a fork also produces confusion. And what this example also again illustrates is that some of these Open Source projects have a very thin governance and astonishingly small core teams. And this is not good for Enterprises who think long term and are looking for future proof technologies.