In a recent blog post, Rod Johnson wrote about third-party companies offering Spring support:

[Non-sponsoring companies should] stop claiming to provide enterprise support, and be clear that what is being offered is a kind of on-call development assistance, with no guarantee of being able to resolve critical issues.

Ben Speakmon from SourceLabs replied:

Companies who sponsor open source by hiring its developers are neither a necessary nor sufficient condition for a successful project.

Many companies like Interface21 or MuleSource aligned their business plans with specific open-source projects, and seem to be a logical choice for getting technical support. Does this alignment imply that others can't provide as good technical support as these companies? Open-source software allows all participants to view the inner workings of a product, to provide fixes and enhancements, and otherwise carry on all the support activities required by an enterprise. The enterprise has as equal a footing as anyone else in supporting the application. Cost is the main reason why the enterprise doesn't. It's cheaper to shift this activity to a separate entity so that the company's developers can focus on creating domain-specific applications and enhancements, not on maintaining and supporting the platform code. The original contributors to an open-source project may have better initial positioning to support it but, does this preclude other parties from offering or providing good quality of enterprise support?

Providing/Offering of good quality enterprise support should not be limited to the Organization that hires the orignial controbutors. Its a open market for support. Isnt this analogous to Microsoft saying "No vendor should present/promote/offer themselves as providing support for COM/DCOM/ASP based development enterprise applications. It should be us always." [Non-sponsoring companies should] stop claiming to provide enterprise support, and be clear that what is being offered is a kind of on-call development assistance, with no guarantee of being able to resolve critical issues.] From what Rod said (quoted above), I think its needs to be clarified on what he meant by "Critical Issues". If he meant "critical issues" within Spring framework, then I think anyone who identified the critical issue should report it to Springframework.org, so that could be fixed. If the practice is that all the committers to springframework happen to be employed by Interface21 or [being a member of Interface21 is made a requirement before granting committer status to a contributer; then that smells of a company from the NorthWest :-))) But as far being able to help/offer-service to enterprises in their understanding & use of Spring; any vendor is right to claim they can help those organizations.

So depends on the support..... Being involved with a company that provides support for several open source products, we certainly wouldn't have the capability to say "I know of the offending method that you speak of, when you click on that 'activate' button." more than the person that wrote that piece of code. But we have found instances of where our customers have found specific problems that they needed solved, where we had to think 'outside the box' where the original developers didn't think of a possible solution. In fact, in some instances, the developers would come back with "yeah, that's cool, didn't think of that, but there is no reason why that wouldn't work!" So would Rod and his team provide a level of depth of knowledge to the underlying code that others may not know? Very likely. But the teams that use the Spring Framework day in and day out in anger would have some interesting twists on how to make it work that Rod and his team hadn't even dreamed about yet. (I know this - because I have seen this!!!!)

Complaining about other companies supporting your open source project is folly. The fact that there are other companies fighting for the business means one very important thing: There is business to fight for. They wouldn't be out there promoting there services if there wasn't a market for them. In fact, it can be seen as a security measure. "If I choose this project, all I have for support is you. If you fail, I'm stuck dead in the water with no one to rely on." A simple contrived example. One reason to buy Car Maker A's car over Car Maker B's car is availability of parts and service. Some niche brand with a single source can be considered a risky proposition. What if the dealer goes out of business, where do I get parts? Now some may argue "it's different with open source - users can see the code and self support". Yes, QUALIFIED users can, but frankly most companies aren't in the "develop and maintain our own core software infrastructure" business. So, most won't. Most will punt and convert over time to a better supported solution. So, Rod and friends should welcome these folks with open arms. It's fair to peak behind the curtain and ensure that these folks are selling what they say they're selling, and calling them out if they're not. But overall, more support means more adoption means more mindshare means a bigger market. Lifting all boats so to speak.

I see this as a sign of maturity in the open-source space. All of the world's industries have original equipment manufacturers and also second-party support organizations and second-source manufacturers. I look at Oracle's moves to provide support for Linux (while I have a cynical side too) is a sign that open-source is maturing. Rod even says at one point "set a price point that allows for genuine support" that reminds me of the Delco commercial urging customers to buy genuine Delco auto parts. As the CEO for an open-source company, the thing that keeps me up at night is worrying that we will not be able to deliver high-quality support and establish our sales channels more quickly than someone else. The value of an open-source company is in the sales and support relationships it has with its customers. BTW, I'm not talking about the open-source projects where the committers are unpaid and will never be paid to work on the code. I'm talking about open source projects like Spring, Mule, Hyperic, and TestMaker, where the company that stands behind the project earns an income through license sales and support so it can earn a profit and pay salaries to the engineers that do the principal engineering. When I was at Symantec/Peter Norton in the 1990's some research we bought showed that support organizations realize 4 dollars of service revenue for every dollar of license revenue for software products like the Norton Utilities. From my experience running PushToTest is seems to me that the same 4-to-1 ratio still exists. My bet is to build an open-source company that delivers software and support, and earns profits from both. -Frank Cohen http://www.pushtotest.com

I would actually agree with Rod’s sentiments. Why would anyone buy support for Spring not from Interface21 is a mystery to me. Other companies naturally can’t have similar expertise in Spring and unlikely to have dramatically lower prices to justify sub-par service. I won’t question the logic and business behind operations like OpenLogic (can hardly see anyone needing it – but I was proven to be wrong before). Using Rod’s analogy, I rarely like to go to supermarket unless I need some cheap and simple product. I would rather go to a specialized store to get a quality product. Best, Nikita Ivanov. GridGain - Grid Computing Made Simple

I would actually agree with Rod's sentiments. Why would anyone buy support for Spring not from Interface21 is a mystery to me.

Hi Nikita! Because shit happens. It's common for startups to start on a rosy path that turns ugly by the time you get to second-round funding. Also, the availability of the source means that everyone has access to it for inspection. Rod's argument seems to be that you must be a project member if you are to provide good support. That may not always be true. One scenario: second-round funding comes in, people leave the company for whatever reason, they know their stuff well, and have credibility with the open-source community. Why wouldn't you take support from them? Or from a third-party, unrelated, but who's got enough experience with the project? Since the road maps for most open-source projects are open as well, you can figure out whether support from one source or another is for you. As an advocate of bringing open-source projects into the enterprise, I can't stress enough that having a commercial entity providing support is a sign of health for the project. Having two or more is even better, because it allows me, as a client, to chose the providers of the highest quality services at the lowest cost for me. Cheers, Zhenya Non-stop action. A vulnerable hero. A quest to save the world. It's the most exciting novel of the decade: The Tesla Testament ISBN: 1-4116-7317-4 - BISAC: FIC031000

Most companies I have worked for purchase support for open source products (Apache Web Server, Struts, etc) just so they have someone to point the finger at if there is a problem. In practice, it really winds up being more of a legal issue (indemnification) rather than a real support issue. It is more of a management behind covering expense. Now on the other hand, for non-open source products, I have seen the support come into play a lot. I have been involved with opening up 100's of tickets with BEA, Netegrity, Oracle, etc.

Hi Zhenja, Agree, although example is rather contrived but I can see your point. It’s just that in case of Spring I don’t see this scenario. They’ve got money, enough people and I don’t think they are getting massive volume of support issues- it’s primarily an insurance for the clients and legal indemnification. I still don’t see why would I buy support for Spring (specifically Spring) outside of Interface21. Apache, Struts is a different story. Those projects don’t have well established backer. Best, Nikita Ivanov. GridGain - Grid Computing Made Simple

One scenario: second-round funding comes in, people leave the company for whatever reason, they know their stuff well, and have credibility with the open-source community. Why wouldn't you take support from them? Or from a third-party, unrelated, but who's got enough experience with the project?

There is a good way to check the expertise of Spring Framework contributors at Spring page @ SourceKibitzer. In the know-how cloud contributors are weighted according to their contribution in the project. Unfortunatly, we can't publish metrics without contributors agreement and it's just 3 guys who agreed to so by the date. But it is a chance for non-Interface21 guys to come out of the Rod's shaddow. Mark http://www.sourcekibitzer.org/Bio.ext?sp=l8

I would actually agree with Rod’s sentiments. Why would anyone buy support for Spring not from Interface21 is a mystery to me. Other companies naturally can’t have similar expertise in Spring

Please, speak for yourself. Are you saying that only the creator of a piece of software is able to understand it ? Others can only read it without comprehending its profound essence. What about Linux then ? Should we all ask support to Linus Torvald ?

and unlikely to have dramatically lower prices to justify sub-par service.

I won’t question the logic and business behind operations like OpenLogic (can hardly see anyone needing it – but I was proven to be wrong before).

Using Rod’s analogy, I rarely like to go to supermarket unless I need some cheap and simple product. I would rather go to a specialized store to get a quality product.

It is a matter of needs and taste. Anyway, it is hard to say that there could be only one specialized store for a specific product. Guido

May be I wasn't clear enough (perhaps) but I meant my comments specifically to Spring framework. Linux is completely different story. Linux never had a single absolutely focused commercial entity behind it that retained >90% of actual committers – Spring has Interface21 as a single “owner” of the technology. Same with JBoss AS and JBoss Group, OpenSpaces and GigaSpaces, GridGain and GridGain Systems, list goes on. Let me reiterate again: professional support for software like Spring (where simplicity of use and productivity was a primary objective to begin with) consists mainly of “insurance” in case of rare production blowouts and legal indemnification. Interface21 knows perfectly well that nobody will bug them on a daily basis on how to use this or that – there's enormous amount of documentation, books, etc. And if once in a blue moon there would a production issue I don't think anybody would have better expertize than folks from Interface21. Period, end of story. Best, Nikita Ivanov. GridGain - Grid Computing Made Simple

I would actually agree with Rod’s sentiments. Why would anyone buy support for Spring not from Interface21 is a mystery to me.

Here are some reasons why it is good to have other than Interface21 support providers: 1. You need a local player to provide a support. Somebody who knows your language and your company. One who can arrive at your office in 1 hour. 2. Price. Spring specialists are working in very expensive countries. Hiring a support from cheaper locations like India, China, ... could be more cost-effective option. 3. Sometimes you need user expertise. Developers are not always the best users of their products. Or do you hire Sun to support your Java development ;)?

Other companies naturally can’t have similar expertise in Spring and unlikely to have dramatically lower prices to justify sub-par service.

That is bad indicator for Spring Framework community. It means that you can't become contributor if you are not Interface21 guy. Hope it's not true in reality. Mark http://www.sourcekibitzer.org/Bio.ext?sp=l8

I would actually agree with Rod’s sentiments. Why would anyone buy support for Spring not from Interface21 is a mystery to me. Other companies naturally can’t have similar expertise in Spring and unlikely to have dramatically lower prices to justify sub-par service.

Perhaps if the answers to my following questions are known, it is much easier to understand whether or not it makes sense to buy Spring support from companies other than Interface21. What does an hour of support provided by Interface21 cost? Or put in another words, at what typical costs could I buy support from Interface21? And how does it compare to the competition? (Of course, the costs are not the only important point, often the quality can be much more important.) And does Interface21 _in practice_ offer really unbiased support? I could imagine that the Interface21 consultants are not really unbiased, but instead are heavily biased towards the use of Spring-related technologies. I doubt that they would recommend migrating a Spring MVC-based application to a Seam-based application, for example.

The original contributors to an open-source project may have better initial positioning to support it but, does this preclude other parties from offering or providing good quality of enterprise support?

In my experience, the only times that an upstart takes away service and/or support business from the original contributors is when the original contributors are either being lazy or screwing over their community (see: compiere and Mambo). Really, what helps in this case are the IP protections in place in most open source licenses, which is ironic, considering that most people don't really think of open source licenses and IP protections. But seriously, the project maintainers should never lose significant support revenue to an outside party - I would be ashamed if that happened to Hyperic. -John Mark http://www.hyperic.com/

In my experience, the only times that an upstart takes away service and/or support business from the original contributors is when the original contributors are either being lazy or screwing over their community

Agreed. OSS companies need to simply offer the best "support from the source", and you'll see stupid business models, like that of OpenLogic crumble in to the mud they sprung from. Roy Russo http://www.loopfuse.com

So the code is open but the service is proprietary. It is Rod's right to come out all (J)bossy about being the exclusive vendor of Spring service. I was hoping he would compete on quality of service (QoS) instead. That is the business model he is latching on to. The next step is to be acquired and see the service and feature schedule get assimilated into RedHat, Oracle, or other. To me, as a user, the product that is spring changes. The days of seeding, white papers, and general openness dry up and you begin to worry about vendor lock. Got to go back through all my code to make the applicationContext accessible through a generic MyContextFactory. Shades of commons logging all over again - ugh.

Coming from end-user side of the fence I would prefer to have options when selecting support contract for the open source products that my company is using. That's one of the main benefits we have as an open source user where we can pick and choose the right combination of products and service for our environment. I can choose to move to different service providers if they don't provide the service that they provide, end of story. We don't have this kind of freedom if we are using proprietary software. It would be good if most of the enterprise open source products have different companies supporting it as I would hate to get stuck behind one vendor that don't provide our company the service that we need. At the end of the day what matter is how you serve your customer the best customer service you can give to help them resolve the issues and walk hand in hand with the customer through thick and thin. Enterprise users are willing to fork out big $$$$ but, of course, it must be met with the highest standard of quality your company can provide.

I think the real issue here is that a gulf as appeared between what as traditionally been called free software (free as in freedom not beer) and commercial open source software. What Rod is talking about is creating a monopoly IMO. Open source intentionally makes no statement upon ethics, yet its unethical trading practices that has stymied the software industry for decades and motivated the creation of free software in the first place. It looks as though Richard Stallman was right when he said that freedom is the real battle field not open source. I must say that I find it disturbing when OSS businesses talk about being "community driven" in one breadth then advocate monopolistic practices in the next. I think we need to do a much better job at self regulation, unless we just want to replace closed source monopolies like Microsoft with open source ones. I know it isn't the "American way", but us Europeans believe in regulating the market as a way of avoiding monopolies and unfair trading practices. Having worked in the European telecoms industry for years, I know from first hand experience that regulation works. For example the world wide mobile phone market is dominated by European standards (GSM etc), and European companies dominate this market based on standards and regulations developed in Europe in the 1990s. As a consequence this industry has never suffered from the monopolies that have plagued the software industry (or plagued the early US telecoms industry, like with AT&T). For a start I think the OSI could do a better job at regulating OSS software branding. There should be a clearer distinction between organisations that promote a community ethos based on common community freedoms, and organisations where open source is a marketing and/or delivery tool IMO. Of course an organisation may fall in both camps, but it is now clear to me that in the emerging OSS space there are organisations that fall clearly in one camp or the other. Without clear branding, the reputation of free software suffers IMO, and the mixed marketing message I described earlier is allowed to prevail and muddy the water. I believe what motivates people to pool their resources and gift their time to an open source project is complex and multi-faceted (far more complex then made out by Eric Raymond IMO) and often ethics do play a significant role. I for one would not contribute my time to Spring, precisely because of Interface21. If Linus Torvald had taken the same approach to Linux I do not believe that the Linux community would have achieved the successes it has today. And I do not believe that Linux would have have become a viable competitor to Microsoft Windows. Without some (self) regulation, I can see the OSS industry imploding as commercial entities try to ring fence monopolies and grass roots developer support evaporates as a consequence. The only people who will benefit from this outcome is the current incumbent commercial monopolies. Paul.

Hi Paul: Lots of interesting thoughts in your reply. One thing that I want to reiterate from my earlier posting is that as CEO of one of the OSS companies my goal is not to develop a monopoly but instead to make sure my company offers the best service and support to the product. In our case the code is GPL so anyone can build their own distribution pipeline to the product and anyone can offer service and support for it. That motivates me to be the best company selling and supporting the product. The other open-source people I know are trying to do the same thing. It may be that some OSS products fall into the trap of being monopolistic but I see the marketplace correcting that bad behavior by moving its sales and service support to other providers. -Frank Cohen http://www.pushtotest.com

I think what we all seem to forget is that there is no Spring without Interface21. Now, we all can argue that it's about developers, not the company, but in reality, Spring developers must get paid or the quality of software will start to fall dramatically (just look at 99% of projects on SourceForge). I will not argue whether it's ethical for one company to pay for development of the product and for another company to earn from it without paying royalties. We all can say "who cares?" - the license does not prevent it and competition is healthy. However if Spring support market begins to saturate, it may have a negative financial impact on Interface21, and then the whole Spring product will suffer quality-wise, development-wise, and innovation-wise. Hopefully that won't happen. I do hope that companies like OpenLogic either wake up and start paying up to Spring at least for Level2 and Level3 issues. We should be careful not to spit into well - we all might drink from it later on. Best, Dmitriy Setrakyan GridGain - Grid Computing Made Simple

Hi Dmitriy,

I think what we all seem to forget is that there is no Spring without Interface21. ...

If this is truly the case then Rod Jonson and others should stop describing Spring as community driven or community spirited. If what you say is true, then Spring is just another proprietary middle ware framework that happens to be open source.

I will not argue whether it's ethical for one company to pay for development of the product and for another company to earn from it without paying royalties.

What do you mean? like how GNU/Linux becomes Linux and a host of Linux distributions make money from work "gifted" by others over many years? If open source is gifted "free" work it doesn't matter as long as all in the community can benefit from it and have equal access and freedoms. Interface21 doesn't have a right to exist, and personally for an horizontal middle ware product like Spring, if it can't survive through free contributions or donations, but only through a monopolistic approach to service royalties then I would argue that the community has spoken and it has limited community support in the first place. Paul.

I've read Rod's blog and Rod was absolutely polite, Rod criticized OpenLogic's business/development model in a developer and client perspective, he never criticized why they are supporting Spring, of course he can't say "no one can offer Spring support besides Interface21". The Apache License is very liberal, anybody following the Apache path is saying to the world "we are a company but we are very open", is very very difficult to build a monopoly with open source exclusively (using the usual licenses), you must rely on legal protection of names, patents (argh) and this kind of ugly stuff. When a product becomes complex and have a big user base most of the time the original developers are overwhelmed and support tasks are delegated to other "trained" developers, in this phase anyone can offer support. Interface21 has the competitive advantage that original developers can be reached to solve critical issues and this is a *very huge* competitive advantage.

Hi Dmitriy,

I think what we all seem to forget is that there is no Spring without Interface21. ...

If this is truly the case then Rod Jonson and others should stop describing Spring as community driven or community spirited. If what you say is true, then Spring is just another proprietary middle ware framework that happens to be open source.

Paul, I don't get this at all, community-driven and community spirited doesn't mean that the community wrote all the code (go ahead and sight Linux, but see my comments below). From my own experiences with Mule the community is most affective when soliciting feedback, the hundreds of emails we receive every week helps to _drive_ the development of Mule. Users also submit ideas, improvements and code to the project (plus we also have a MuleForge with about 60 modules, with over half coming from our community, others are partners or internal projects). Community-driven development is all about allow your users to get involved _when they can_. The community of users don't have time to run a project, maintain QA, consistency, etc. There needs to be a dedicated team n place to make this happen. Does having a dedicated team in place somehow detract from the openness of the project? well of course it doesn't, It just improves the quality of the releases. Spring might still exist without Interface21, but it wouldn't be the robust, integrated and fully-featured framework that it is today.

I will not argue whether it's ethical for one company to pay for development of the product and for another company to earn from it without paying royalties.

What do you mean? like how GNU/Linux becomes Linux and a host of Linux distributions make money from work "gifted" by others over many years? If open source is gifted "free" work it doesn't matter as long as all in the community can benefit from it and have equal access and freedoms.

IMO Linux only 'really' worked because of guys like Redhat. They made linux accessible (remember the dark days when Linux wouldn't recognise your screen resolution or modem). How did they make it accessible? By taking control of a distributed that they turned into a real product. At some point a successful open source projects needs to take the next step and build a company around it, in part to get some return on investment for the team that looks after the project but more important to sustain and grow the project offerings.

Interface21 doesn't have a right to exist, and personally for an horizontal middle ware product like Spring, if it can't survive through free contributions or donations, but only through a monopolistic approach to service royalties then I would argue that the community has spoken and it has limited community support in the first place.


Paul.

Donations and contributions are always gladly received but a project, but the proviso is that the contribution has to live up to the same standard as the rest of the code base. Unfortunately the majority of code submitted projects is at best only 80% complete, since there needs to be more testing (often there is an absence of tests) AND there needs to be a QA process in place to ensure when the contribution is added it doesn't screw anything else AND works seamlessly with other related modules in the project. There is a lot of additional work on top of contributions that 'someone' has to manage (resist the urge to put this responsibility on the contributor since s/he has does not work to the projects release plan since they are volunteering and there's no guarantee the work will ever get done) I do understand what Interface21 are going though since we have been going through a similar transition the last 12 months I agree that to try an monopolise revenue on an open source project you started with the premise that "we wrote it" may not be the best approach, but there are plenty of benefits that the company behind the project can offer that others cannot - 1) While there may be many experts on the project out there, they are not all under one roof and ready to help you. 2) The company behind the project ultimately own the core road map (contributors rarely get involved here because they don't have the time to invest in it). Of course companies like SpikeSource can contribute back, but I guess they haven't with Spring. 3) As a company, If your production system goes down, and you're losing money, you'll want to talk directly to the guys that wrote the code. Going though a middle man may waste time, so why gamble? 4) MuleSource like many open source commercial companies are the only people that can offer Indemnification and other insurances, because we own the IP. 5) We also offer value-add products as part of the support offering, that you wouldn't get though other service provides (unless they are a MuleSource partner). When we started MuleSource we understood that we would not be the only company offering services for Mule, but our approach has been to compete on quality of service and offerings, this is working well for us. We also have successful and building partner network where we offer Level 2/3 support to companies in other regions who offer support or services for Mule. There is so much global opportunity out there that we just couldn't meet demand on our own. This is also good for companies since the get a choice of providers but ultimately they can still get serious issues escalated to Mulesource. I think guys like Optaros and SpikeSource serve a purpose offering entry level support for projects, but I doubt they'll be taking business from the project founders providing they focus of differentiation on QoS. I'm not banging Spikesource for offering poor service, they should be able offer a decent entry level of support, but being a jack of all trades means that you are a master of none. Cheers, Ross MuleSource

Hi Ross, I believe that there is a role for your type of business. I also believe that companies like yours can provide a positive contribution to the software development ecosystem. I also believe that closed source software businesses have a role to play too, and that their contribution can be positive also. It is clear to everyone that these things are different. My point is that they are also different to free software as defined by the Free Software Foundation. My concern is that many OSS businesses have chosen to take a point of view that is different from the ethical stance taken by what as historically been known as free software, yet they choose to deliver a marketing message that is very similar. In a sense riding on the success of the free software movement. I believe this situation could have been resolved in 1998, when the OSI decided to split from the FSF by clearly branding their version of "openness" and as distinct to the FSF version. I believe this is needed just to remove confusion. In fact I think there are several categories of openness and freedom, all of which should be labeled differently in my view. For example you would agree that a not for profit organisation like the Apache Foundation is a very different type of organisation then yourselves. What is even more confusing is that many OS software businesses choose to license their software with the same GNU license created by the FSF (Richard Stallman), whilst also choosing to take a completely different ethical stance on the role and importance of the term "free". I don't think that most people see open source as just a technical distinction concerning whether the source code for a particular product is GPL (or some similar license) or not. They see open source as tied to ethics which in the minds of many are similar to those espoused by the FSF, and if you look at how most OSS businesses market their products you can see why many people (perhaps wrongly) think this way. At the end of the day we are all free to do what we like, and the market is free to choose. What I am arguing for is clearer labeling. I don't think the confusions and the contradictions at present are helping anyone. Paul.

I can understand yours and Rod's argument about support and open source developers that have to be paid. The thing is that we have a free market economy and the market will regulate itself. Normally a company will first contact Interface21 for consulting/support/training for Spring - I personally know customers who bought trainig from a different company because Interface21 was too expensive. Ever bought a "core developer" from JBoss? You pay 5-times more for them, than for a "normal" consultant and this can be an argument to buy the support/service from a different company. This is not only an Open Source problem - there are many companies who are getting there money for WebSphere/Weblogic consulting. My opinion is that the prices for consulting/training etc. from open source companies are to expensive because the business model doesn't scale. They can only make money if the sell "people" - and this people also have to implement new features for the product. (and you don't have 200 Spring core developers) This is difficult for a company like Interface21 which in fact sells a software -> Spring. Other software companies scale very well by having a license fee. Another point is how to decide which support a customer should buy. E.g. an application uses GridGain, Spring, Struts, Mule, Hibernate, Log4j, JBoss, MySql (and maybe 20 more dependen OSS projects) - which support should be bought? And what if an production error occurs - who will handle the problem? This ist where the support of companies like OpenLogic is getting very useful... Mirko

Another point is how to decide which support a customer should buy. E.g. an application uses GridGain, Spring, Struts, Mule, Hibernate, Log4j, JBoss, MySql (and maybe 20 more dependen OSS projects) - which support should be bought? And what if an production error occurs - who will handle the problem? This ist where the support of companies like OpenLogic is getting very useful...

Looks like OpenLogic is an expert in absolutely everything :) Forgive me for tossing doubt here, but in my own experience people usually know little about everything and a lot about something. Using this reasoning OpenLogic should definitely fall into "know-little-about-everything" category. Best, Dmitriy Setrakyan GridGain - Grid Computing Made Simple

Why are these two guys bitching at each other so much? Maybe its because their models are so similar? Spring web flow and IoC aside, how is Spring's business model any different than SourceLabs? Most of Spring is a thin value-add wrapper around technologies that Interface 21 either doesn't control and/or doesn't have contributors employed. I agree whole-heartedly with Rod that your not going to get a complete support experience without some ability to get patches propagated up to the base project. But the ironic thing here is, Rod has the exact same problem as the SourceLabs guys do... But...., so does every other open source company. For example, we've been effectively supporting Spring for years where it intersects JBoss projects. Does this mean we sell Spring support? No. Its not our core business. We've also had partnerships with companies like Sourcelabs because, well, in the end, brand is king and they really aren't much of a threat. Also doing so starts to create an ecosystem around your products. Finally, as much I would like to revel in the negative attacks on I21 here, they have earned every commercial and business advantage that they have. The thing is that the ted-neward-tards of the world don't get that visibility and brand mean as much to the success of a project as the technical quality of the project. This visibility takes a tremendous about of effort and dollars. Rod wrote, like what, 2 books? He and his minions do tireless No-fluff-just-stuff and conference tours. I bet he is also continuously meeting with potential clients and customers all around the world. He also probably has a few marketing and sales people spreading the word. And, don't forget that web site work takes a lot of effort. And doing all this stuff takes a bunch of cash to fund it. Remember guys, this is Open Source not Open Business. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

As a end-user if find the direction that OSS is going .... surprising. Interesting ending quote by Bill. "Remember guys, this is Open Source not Open Business. " The source is just not open if ONLY employee's of a commercial entity are awarded committer's right. It's understandable if a commercial entity has a strict evaluation criteria before giving others (a requester) commit access; that would be to keep their code quality high. If the requestors involved in the community process and a feedback about him from the existing committer is considered etc, then granting him the access is perfectly along the lines that OSS has grown. So to sum up the quote - Agreed, its not Open Business, but then is it Open Source either?

So to sum up the quote -
Agreed, its not Open Business, but then is it Open Source either?

Yes, as per the distribution licenses used. With most of these licenses, you are free to fork, free to hack, free to fix, free to package, etc... Open Source Businesses are NOT open cesspools for any wanna-be hacker to dump his crap in the code base. Maybe thats what Apache is for? Roy Russo http://www.loopfuse.com

Open Source Businesses are NOT open cesspools for any wanna-be hacker to dump his crap in the code base. Maybe thats what Apache is for?

:-) Nikita Ivanov. GridGain - Grid Computing Made Simple

The source is just not open if ONLY employee's of a commercial entity are awarded committer's right. It's understandable if a commercial entity has a strict evaluation criteria before giving others (a requester) commit access; that would be to keep their code quality high. If the requestors involved in the community process and a feedback about him from the existing committer is considered etc, then granting him the access is perfectly along the lines that OSS has grown.

I'll talk for MuleSource here but I'm pretty sure Interface21 do the same thing. Anyone can contribute to Mule, but the level of your work has to be proven. We do employ most people that have committer rights to the Mule source code, but that not because there is a requirement that you must work for MuleSource, it actually the other way round. If you qualify to become a fully-fledged Mule committer then you have demonstrated that you understand Mule, your coding is of a very high standard and you have a good attention to detail - and we'll offer you a job if you want it. Cheers, Ross

The source is just not open if ONLY employee's of a commercial entity are awarded committer's right.

You do not have to be an employee to be a contributor on any of our projects. I'm sure I21 is the same. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

The source is just not open if ONLY employee's of a commercial entity are awarded committer's right.

You do not have to be an employee to be a contributor on any of our projects. I'm sure I21 is the same.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Hi Bill, The issue is that you get to decide. You are in control, and the wider developer community are not free to decide for themselves. If you get to decide, then who controls the software? The community or your shareholders/investors? It is this question that liess at the root of the current confusion. Richard Stallman makes the issues very clear (especially if you choose to use the words "software", "product" and "service" interchangeably):

Misunderstandings(?) of "Open Source" The Open Source Definition is clear enough, and it is quite clear that the typical non-free program does not qualify. So you would think that "Open Source company" would mean one whose products are free software (or close to it), right? Alas, many companies are trying to give it a different meaning. At the "Open Source Developers Day" meeting in August 1998, several of the commercial developers invited said they intend to make only a part of their work free software (or "open source"). The focus of their business is on developing proprietary add-ons (software or manuals) to sell to the users of this free software. They ask us to regard this as legitimate, as part of our community, because some of the money is donated to free software development. In effect, these companies seek to gain the favorable cachet of "open source" for their proprietary software products--even though those are not "open source software"--because they have some relationship to free software or because the same company also maintains some free software. (One company founder said quite explicitly that they would put, into the free package they support, as little of their work as the community would stand for.) Over the years, many companies have contributed to free software development. Some of these companies primarily developed non-free software, but the two activities were separate; thus, we could ignore their non-free products, and work with them on free software projects. Then we could honestly thank them afterward for their free software contributions, without talking about the rest of what they did. We cannot do the same with these new companies, because they won't let us. These companies actively invite the public to lump all their activities together; they want us to regard their non-free software as favorably as we would regard a real contribution, although it is not one. They present themselves as "open source companies," hoping that we will get a warm fuzzy feeling about them, and that we will be fuzzy-minded in applying it. This manipulative practice would be no less harmful if it were done using the term "free software." But companies do not seem to use the term "free software" that way; perhaps its association with idealism makes it seem unsuitable. The term "open source" opened the door for this.

The full article can be found here: http://www.fsf.org/licensing/essays/free-software-for-freedom.html Paul.