Everything is a Freaking DNS problem

There is this constant discussion about Open Core vs Open Source vs Proprietary Software , Fauxpen Source, Open Source Business models etc.. you probably know all the usual suspects involved, first up lets agree that nobody will ever agree on what's best, (off course it's pure open source.. ) , but one of the important aspects is to know what values are important for you and your customers

Simon Phipps thinks we should build a scorecard that lists the different values we attach to a certain level of openness

He'd like a rating to questions such as , Is the license OSI-approved? , Is the copyright under diverse control? ,Is the community governance open?, Are external interfaces and formats standards compliant? , Does your community operate under a patent peace arrangement? Are trademarks community controlled? etc ..

Do we need one ? Matt Aslett , whom I finally met last week in London , thinks not as it will has the knife will cut on both sides, but then also thinks yes as it might clear up confusion to outsiders.

The comments on his post however is where the real discussion starts, the one where the Open Core fanboy tells about HIS customers not caring, and the Open Source zealots comment that the open core customers don't care as they already settle for the best of worst world (ok ok , I added that myselve :))

We are old and smart enough to decide ourselve .. aren't we ? Fact is that plenty of us already use this kind of scorecards for themselves, We prefer Open Source over Open Core , but still Open Core over proprietary software, we look at the community, we look at the source , we look at who's contributing and who's using. Sometimes we value a vibrant user community over a vibrant contributing community , sometimes we don't like projects with only contributions from 1 company .. we do that exercize daily

On the other hand, as Matthew Aslett states, the outsiders probably don't know yet, and as someone else in the discussion said, some customers are just stupid ..

Different Open Core vendors have different approaches, we should use our own brains to see the difference between Marketing Driven company squashing out buggy but open code and community driven company looking for a business model. If you, such as Sander claims constantly are trying to outsmart your community , don't you think your customers will realize that ?

An aftertought If Simon Phipps gets his wish granted, what do we do with the blogs etc, shouldn't Matt then change the subtitle of his blog to The business and politics of open core ? and his title to Open Core Executive to ? Or do we just call him the Richard Stallman of Open Core ?

I`m gonna have to quote Tarus once again :

For years now I’ve been struggling to educate the market on the fact that the business around open source software is not about software. It’s about solutions.

Let me repeat that .. it's not about selling software ...

It's about solutions

And obviously FLOSS is the Ideal platform to build value for your customers

By now everybody and their neigbour has realized that indeed Everything is a funky dns problem, Frank is giving talks about it at ZooCamp, and Serge figured out the hard way the downtime of planet.geekdinner.be was due to a dns problem :)

But I told you different things before ... and some of you listened others are still reinventing the wheel as we go ...

Matt A. points out that the OpenBravo folks realized that one should try to build on top of Open Source projects rather than modify core code ..

Wonder where he read that before :
Some projects are prepared for local contributions, they have a modular framework that allows you to build on top of the project while not having to touch the core of a project, Drupal and openQRM are great examples of those, but not all projects are that smart. Needless to say that when you have such a modular framework you really shouldn't be modifying the core part of the platform, unless you are fixing a real bug.

Over at the MySQLPerformance blog, Peter points out that Open source projects don't do big fat marketing campaigns and the community doesn't appreciate features being developed in a corner then being released with a big bang ... we prefer our releases Early and Often...

On Automating Software installations, a Tom Limoncelli about how we install software and debug setups, with a nice quote "Oh my god. Is that why nobody uses the GUI we spend millions to develop?".
Well Luke said it before .. If my computer can't install it .. the installer is broken

Stephen Walli has some good toughts on how Open Source vendors should setup their partner programs, indeed with their eyes wide open ..

I ranted on Open Source Vendors thinking they should still work with partners models and the channel the traditional way before

However I have to admit that over the last month I did talk to people that do understand our Love / Hate relation ship with the Open Source Vendors that want to partner with us .. and that some of the newer Open Source Vendors are actually attracted by our different way of tackling partnerships.

Oh well.. as Tarus says .. my 3 readers understand..

Tarus is happy not to have VC's on his back. He doesn't want to be responsible for turning a 15 Milj investment into a 150 Milj cashout. Others chose to go that way.

Back when he wrote the article the chances were small that he already knew that Qlusters was going to be shut down with still sooo much money in the bank, but the VC's wanted it back.

So how do open source companies plan on making those tenfold roi reality.
Apart from selling out to a bigger company I think thats a very difficult task.
Especially when you keep in mind how to manage both the Open Source community and your customers. The figures he mentions that VC's require surely start pushing vendors into violating Fabrizio Capobianco rules.

Now the story changes when indeed you cn go to a model where you are selling a large scalable service to your customers, even with microsized payments it becomes a possibility, but that's a totally different business model from what e.g. the Open source systems management shops are doing .

So will the Zenoss, Hyperics or the Groundworks of this world survive the demands of their VC

Luckily these projects are Open Source, so when the company dissapears, the project can continue, and grow even better. Like openQRM did

No Matt, my brain definitely wasn't idle.. I've been thinking about these problems for the better part of the last decade. And it seems like I`m not the only one who wants this discussion.

Dries told me that as a follow up to my previous post I should write a post with solutions to the problem. Difficult as I don't have the solutions yet.. If I had them .. well :)

Fact is that different types of opensource products might require different approaches Alfresco to my knowledge has little to no contributing community , Linux distributions tend to have a big one, if not just in the form of the different open source projects they pacakge. The MySQL community is more one of documentation, helping out and bugsquashing. So my ideas aren't valuable for everybody, which is maybe why Matt Asay can't understand me, he might be looking at only one side of the picture.

There are some little things that I can suggest however.

Open Source works because of people contributing to projects, Open Source companies should recognize that and figure out a way to return more business the partners that also contribute to their code , this way they can contribute both on commercial and financial level. If you keep sending business to non contributing partners at the loss of the ones that actually commit code, some people will be unhappy. Those contributing shops might not be bringing the big revenue for the vendors, but they sure are contributing.

The other part is in the support model, Matt somehow thinks I`m in the "everything must be free" camp. Wrong, I`m in the right price for the right product/service camp.
Which means that if I`m escalating a support issue of a customer of mine to a vendor, my time must also be paid for. However that's a difficult sale, my client already paid for his support contract , to the software vendor.

So my suggestion, back when RedHat came to the Bemelux, was to have different types of support contracts, a customer could get a direct contract with a vendor where no integrator could log the calls. Then with another contract type if the a partner actually logs a call for his customer he must get some kind of kickback for that...
One of the advantages there are that more first line calls can be tackled by local partners, partners that might know their customers better.. but they still have a backup if they can't solve the problem. Therefore less investments are to be made in a support organization by the vendor.

And last but not least , don't tell your partners what they can't do. They should be listening to their customers, if their customers choose for the open source version it's the customers choice, and the partner should be able to help his customer, the last thing you need to do is punish them for listening to their customers needs rather than the vendors. This is how the proprietary world works.

Oh and Matt, next time you are in Belgium, let's do another round of Buytaert vs Asay :)
Maybe we come up with some better ideas than the above ones.

Or, why the Inuits won't partner on selling Ice from Alfresco unless they change their strategy.

I usually agree with lot of the things Matt Asay writes but today in Closing an open-source deal trough your systems integrator , he thinks the way to work with partners in an opensource environment is to force them to sell the commercial solutions of your products.
He also thinks you should block them from starting an implementation before the end customer has signed a purchase order.

Whew.. this must be the most stupid idea he had since he started his opensource career. The sad part is that I haven't seen a commercially backer of an opensource project dealing correctly with its contributing partners. He isn't solving the problem , he is creating a bigger one :(

Integrators and consultants are often the bigger contributors to a project because they are integrating new features for their customers, You know, their local , we speak your language , customers. So now Matt wants to force them not to sell services around GPL software anymore but sell the commercial versions ?

As lots of commercial opensource versions do not allow you to make changes to the code if you don't want to loose support your hands are tied again. And yes I have been in this situation before multiple times, a situation where , a commercially backed opensource project, required a couple of small changes to fit with a customer, because of these changes the commercial vendor would drop support , so the customer decided not to buy the license. Should a local integrator capable of helping such customer loose that deal because of a partnership ? Off course not .. It's perfectly understandable that a software vendor can't support every different patch. Shouldn't an integrator have the freedom to assist a customer in making these choices, and give him valuable advise ?

Forcing the integrator to sell the commercial version brings them back to the proprietary software vendor situation , where they couldn't solve issues either.

Mind this is a Category "C" user ,(an organization that has more money than time), which should be an easy win for the commercial opensource vendors.

Then there is the issue of Paying twice where a customer both pays for the time the integrator spends on solving his issue and the support contract. I`m stil looking for a solution for this one.

In the past we invested in different partnerships , some requiring certification, with different Open source vendors before, never got a dime back from these investments.

While our shop was a small but specialist expert knowledge center most deals that those other vendors had in our area went to the incompetent boxmovers that did volume, often totally screwing up the actual implementation. Whether we had contributed to the project, or in the case of Linux distributions were probably equally skilled to support the environment as the vendor itself didn't matter.
We didn't sell enough boxes , so we never got any deals back. Our business is advising people on how to implement open source , implement it for them and support them. We are working with both type A,B and C customers. But the commercial opensource vendors want to force us to go back to the old proprietary boxmoving model, sell licenses, don't sell solutions, Oh and No you can't fix that .. you'll have to wait for the next commercial release or lose support.

So how many of the opensource benefits should the customer give up ?

No Matt, this time your idea stinks,

This way skilled consultants that care about open source and contribute to the community are being punished for doing so, whereas they should actually be getting business back from the vendors, so they can earn money and contribute more on your product you force them to waste more time on the sales side. While the people that just move boxes, don't care if its an open source application or a proprietary package gain more. For them its just business as usual .. selling boxen.

It just doesn't make sense

This concept is just bad for opensource in general, motivated people will stop contributing to products they implement, as they see that their efforts aren't appreciated by the vendors.

Slashdot totally misinterpreted Jeremy's post about MySQL starting to build features first for their customers. As a business model , this sounds like a good way to get revenue , customers want certain features that are valuable to them , so why not let them pay for it .

The question however is how your development cycle works. Often this method of keeping code first for your paying customers , and when "the feature has been paid for" give it to the opensource community , is the wrong one.

What it comes down to is that you neglect the release early , release often and the peer review , many eyeballs see more bugs, fundamentals that made opensource projects big and stable. You are in effect stepping back to a proprietary model where you have to rush your deadlines because you have promised customers such and such feature, hence letting your customers do your beta testing.

It’s not like it’s the first time MySQL pulls this trick. They already did that when building a Carrier Grade edition for Cluster. That indeed also was a product where they had customers paying for unstable beta products.

The peer review process is one of the things that insanely attracted me in Open Source, the code that you get is not some piece of overrushed code where a developer made a dozen shortcuts because he had to make a deadline, but a piece of code that has been reviewed by many , discussed, and then eventually allowed into the project.

Releasing beta level code to customers and eventually to opensource means you miss out on a lot of the features a true opensource project has.

Often the reason why Open source minded organisations still chose for this approach is to get revenue to be able to hire more developers/ support peope and improve the product faster. But it's a vicious circle, because your product isn't up to the standards you are used to you need more people to support it.

However in the MySQL case , a mostly user community, lesser user development contributions, this could make sense.

Over the past couple of days Sun has been getting a lot of feedback on it's behaviour with open source.

So there is Amanda McPherson trying to teach Sun that the L in LAMP really stands for Linux.

And then there was Roy T. Fielding quiting the Open Solaris community.
I'm still wondering why a company that once bought StarDivision because it was cheaper to buy the company than to pay licenses for similar functionality, keeps maintining their own kernel stack rather than contributing to one that is way more popular and as a much larger userbase.
Its not like they have a die hard community they will loose, it's not like they will loose customers over it. When Sun says that Linux is the new Solaris their customers will just follow.

Personally I stopped working with Solaris ages ago... when we ocasionally run into a customer that wants us to deploy things on Solaris we always have to spend extra time GNUifying the box, which is yet another pain.

Sun had to learn the hard way from the JAVA crowd that they do care about Licensing and a community only starts to build when they like what they see. and it's exactly that community that Solaris is still lacking.

Virtualbox also is in the same boat, they have a good user community, but they don't have a lot of contributers as they require contributors so use the MIT license and even sign some papers.

In a way MySQL used to be the same , altough lots changed during the last couple of years , but back a couple of years ago nobody outside of MySQL was contributing code, there was a gigantic user community, but not really a developer community.

The big difference here is in community.. not customer base, these people are actually using MySQL because they are freely choosing so. Not because their boss or corporate policy tells them to.
But MySQL learned, and is changing, it currently has also non employees contributing .. often ex employees but also other people , people that form a real community.

Today .. if you really want to cash out ... create an product open source it ,create a user community around it but don't allow contributors, my bet is Sun will buy you :)

I told it before.. I really really hope one day Sun will understand .. but from the past couple of acquisitions.. they seem to be taking the same path over and over again.

Not even that long ago I discussed Innovation in Open Source projects ..

Let me refresh your memory...
Call me oldfashioned but I still think of most of the closed source shops as 9to5 developers that write code because their boss tells them. Their boss is being instructed by clueless marketing people that promise impossible features to customers with impossible deadlines. An Open Source developer writes code because he wants to fix something , because he needs a feature , not because someone tells him to do so. To there is much more passion to be found in the heart of an open source developer than in your average closed shop developer.

Now add Michael Dolan 's comments on Open Source projects lead and managed by a sole corporate with no actual community to my notes.

Then try to understand why Sun announces this , now I wonder .. what are they going to pay people for .. features that the corporate product management wants, or features the community wants ? There is money involved .. so who will be calling the shots ?
I hope they make the right choices .. I really do !

But I'm afraid Sun still doesn't understand how to play with the opensource crowd. They try .. but run into too much walls As Michael notes , you can hardly call Open Solaris a succesfull open source project as it still doesn't have a real community. I hope one day they will realise that , drop their commercially driven doomed to fail open projects and start contributing to some projects with a real community. It took them a while to figure out the right thing to do with Java .. I`m sure they'll learn and figure out this time also :)

Sun isn't the only one not to understand how the community works.. but it's one of the most public ones that needs our help.

So what have we learned so far ..
* Open Sourcing an end of life proprietary proprietary does not work
* Managing an Open Source in oldschool inhouse proprietary style doesn't work

And lots more ...

Over at ITToolbox Tarry has another blog . He posted an article where he tried to debunk some myths about open source. I feel he needs some help there :)

Let's start with his second Myth , Open Source is Free. Off course it isn't , you need to invest your own time to get familiar with it or pay other people to use it. Compare it to building a house ... you can build one if you have the skills and the time , but you still need to pay for the bricks and the mortar, or you can pay someone who has the skills to build one for you. With software there used to be a similar thing. You could buy software, then install and configure it yourselve, or you could hire someone more skilled than you to install and support it when you run into problems. Now take away the fact that you have to buy bricks and mortar , or for this case the software. That's Free Software.. you still need to spend time to get to know the tools or pay someone to do that for you. Depending on what the core business of your ogranization is .. the choice is your.

Tarry says
BUT it remains a product that you need to get support. Just like Windows or Oracle database.
Which I don't agree with .. the fact is that I never can get the same level of experience and knowledge myselve on a product such as Windows or Oracle as I can on Linux and MySQL , I can't dig in to the source code of the first 2 products
In fact, Oracle is a better example, its an open source, right?
Whoow, when did that happen .. during which long vacation did I miss Oracle being Open Sourced ? Yes Oracle contributes a lot to open source but Oracle itselve being Open ... I must have missed that..

People won't notice but you'd have a huge application running on it in no time and you'd be stuck to that "free version" for the rest of your life. Or you choose to eventually buy the software support and even end up paying the license fee. Ha! Vendor lock Alarm!
Now there is a skyhigh difference between a limited featureset product that is free to download but not free to use in a production environment and and opensource which is free to download, to use, to modify and to contribute to. Yes there are people making a business model of supporting that piece of software but they don't force you to buy anything from them. It's a pretty sensible thing to buy services from the people that actually wrote the code , but you are free to buy the same services from someone else, someone local, someone who speaks your languag And they will be able to read the code and fix the problems.

Look at a proprietary product where you want a feature changed or a critical bug fixed.
You can call your local supplier, who can't do anything else but call his reseller who will escalate to the vendor. There is no way your local integrator will actually be able to modify the product and fix the problem. However You or an open source integrator with the appropriate skills can take the code of the product, study it and fix the problems. After which off course they will contribute these changes back to the community. I see no vendor lock in there.

Simply because no matter how small you are, you wouldn't want to risk you application on this product, you'd rather go for a full support. Same applies to the "open source" cousin! Do you really think that running Centos, Whitebox, Ubuntu etc without licensing and regular patching is a sustainable option. no sweetheart, it isn't no where. There are however places where you can carry on for a while with this scenario, but not for long.
Yes you need to patch your system in a timely manner, but I don't see where you could License Centos or Whitebox or a big set of other Open Source projects such as Apache etc.
There are different good reasons to buy support and services , you might want to financially stimulate and support the people that wrote the code so they can continue to write it, you might want to have an insurance for your boss when things go wrong , you might have a long history of making too much IT expenses, or you are forced to buy a certified product because yet another vendor only wants to work on a certified products. But risk for instability on the open source side is not amongst the list of reasons. If you have the appropriate skills and time nothing is blocking you from supporting yourselve. There is absolutely no need to buy a license from someone . So carry on ..

On Open Source Innovation..
Innovation happens at the heart of the open source with as much fury as in a "Closed Source" shop.
Call me oldfashioned but I still think of most of the closed source shops as 9to5 developers that write code because their boss tells them. Their boss is being instructed by clueless marketing people that promise impossible features to customers with impossible deadlines. An Open Source developer writes code because he wants to fix something , because he needs a feature , not because someone tells him to do so. To there is much more passion to be found in the heart of an open source developer than in your average closed shop developer.

Innovation is not happening in the Closed Source shops anymore. Innovation is happening out in the open.

Tarry, guess we need to grab some beers to discuss this further , but I feel we'll have an opportunity coming up pretty soon :)