dm to Eclipse: Does it really matter?

14 Comments

I was just reading on Adrian Coyler’s blog that Spring’s dm Server is moving to Eclipse.org.  Cutting through all the blah blah blah, this is what I came up with as the reason for this move:

“At SpringSource we know that open source development and community involvement can play a huge role in evolving simple, pragmatic solutions that enable a technology to bridge from early adopter to mainstream usage. We know because it is a path we have successfully taken many times. In creating the Virgo project at Eclipse.org, we seek to accelerate the journey of the dm Server and of enterprise OSGi along this path.”

What I extrapolate from this is that they want to accelerate adoption.  I have a simple fundamental question:

Does it really matter if you host your project at an OSS organization like Eclipse.org or Apache?

I’ve been living in the Java OSS community for about 9 years now.  IMO, based on my experiences with JBoss, the only thing that Eclipse.org or Apache really gives you is an established brand to promote your project.  I’ve always felt that a move to Apache or Eclipse, while may be beneficial in the short run with a bump in your adoption curve, in the long run it is bad for both your project and ultimately your business.  Why?  Because you lose control of both your brand and the governance of your project.  Brands cost money and time to build.  Governance introduces the inefficiencies of any bureaucracy (see my previous blogs on problems at Apache.org).  So, with both of those disadvantages, I question the advantages of moving dmServer to Eclipse.org.  JBoss has never had a problem starting a new project and building new communities on our own.  Neither has Spring for that matter.  Our brands are strong enough so that we don’t need the bump of an Apache or Eclipse to drive adoption.

The only real benefit I see to move to Eclipse or Apache is if you’re trying to build a consortium of companies that build off of a base core technology.  I really don’t see that happening with dmServer, even if that is there goal.  I know we wouldn’t use the technology.  Would Oracle?  IBM?  SpringSource is no longer the little guy.  VMWare is a serious competitor to all of us.

Standardization more important

IMO, a better route to grow adoption is standardization.  Hibernate got a huge bump in adoption by aligning itself under the JPA banner and EE 5.  We are seeing the same with Seam->CDI->Weld and Bean Validation.  Standardization drives adoption because it frees competing companies from having to depend on a competitor’s code base.  Since the APIs are public, vendors can provide their own implementations and value add on their own terms.  At the same time, standardization gives an easier entry point for vendors that want to enter into the space and gives users the peace of mind that they have less vendor lock-in.  Just because something is open source doesn’t mean that it is immune to lock-in.  The lock-in here is to the implementation.  Standardization breeds multiple implementations.

With dmServer, yeah, it is built upon the OSGi specification (and OSGi implementations), but that is just not the same.  You have to bring your innovations to a standards body to create the ecosystem.

What do you think?

So please help me optimize my personal algorithm for professional open source.  Do you think it really matter if you bring your project to an established organization if you yourself are already established?  I say no…


We’re listening: REST-*.org changes

1 Comment

Message Change

  • It is now an open source project.
  • We will be publishing the final content on IETF as a set of RFCs.
  • We’re still focusing on middleware and middleware services.

“REST-* is an open source project dedicated to bringing the architecture
of the web to traditional middleware services.”

“REST has a the potential to re-define how application developers
interact with traditional middleware services. The REST-* community
aims to re-examine which of these traditional services fits within the
REST model by defining new standards, guidelines, and specifications.
Where appropriate, any end product will be published at the IETF.”

Governance Changes

  • *No more trying to be a better JCP. We’ll let the IETF RFC process govern us when we’re ready to submit something.
  • An open source contributor agreement similar to what Apache, Eclipse, or JBoss has to protect users and contributors.

(FYI we already required ASL, open source processes, NO-field-of-use
restrictions, etc…)

If you have any other suggestions, let me know:

http://www.jboss.org/reststar/community/gov2.html

RESTful Interfaces for Un-RESTful Services

Many traditional middleware services do not fit into the RESTful style
of development. An example is 2PC transaction management. Still, these
services can benefit from having their distributed interface defined
RESTfully. The nomenclature will be RESTful Service vs. RESTful Interface.

  • 2PC transactions would be considered a RESTful interface under REST-*.org. Meaning using it makes your stuff less-RESTful, but at least the service has a restful interface.
  • Messaging, compensations, and workflow services would be considered “RESTful Services” that fit in the model.

Guidelines Section

This is where I want to talk about how existing patterns, RFC’s and such
fit in with the rest of what we’re doing. An example here could be
Security. What authentication models are good when? When should you
use OAuth and OpenID? How could something like OAuth interact with
middleware services?

Some of this stuff is already up on the website. (You may have to reload
it to see it due to cache-control policies.)

Finally, apologies for the jboss.org redirection. We don’t want is as a JBoss.org project.  It was meant to be a separate entity.  It is a problem with
our infrastructure.

Yet another reason to avoid Apache.org

4 Comments

I find  it strange how Apache.org allows for competing projects as they don’t really position themselves as a Sourceforge or Google Code.  I know I’m pretty stupid for creating buzz about a competitor, but IBM and HP have launched a new JAX-RS effort at Apache.org.  The thing is, the Apache CXF project already has a pretty good certified JAX-RS implementation.  If I were Sergey or Dan I’d be pretty pissed.  This just solidifies my opinion that Apache.org is a horrible place to host an open source project or to build start an open source business.

Not only do you have to worry about some Apache bureaucrat pulling rank on you or disallowing you to commit too much work to a project, you also have to worry about sharing your already diluted brand with a  competing project.  With a competing project the “Apache” in front of your project’s name ceases to add any value to the uniqueness of your project.

BTW, I don’t mean to pick on IBM and HP.  I’m just annoyed at Apache.org.  While it may be a great place for big vendors to collaborate at a neutral site, Apache.org is just a horrible place for the little people of the world.

I also shouldn’t pick on Apache.org so much.  They are a good organization with a good message and good ideals.  I just want to encourage future OSS developers to try and go at things on their own.  Learn to promote their project on their own without relying on the Apache brand.  Its better for them in the long run.

Be Liberal with OSS Commit Access

7 Comments

Commit access allows an independent open source contribute access to your project’s source tree.  Over the years I’ve found that it is best to be very liberal when granting commit access to my projects.  If the developers has submitted a patch that has solved a particular problem that even remotely shows they understand how my project is designed, I grant them access.  Think about it.  Somebody that has posted a patch has: learned how to download the source, has learned how to build your project, has stepped through your code to find and understand their bug or new feature, and most importantly has shown a tremendous amount of initiative.  Contributors are usually very honored when they are granted commit access.  It gives them a sense of ownership and pride.  They are usually relatively careful because they are so afraid that their code is out in the wild and can be viewed by anybody.

Sure, you may have a lot of turnover on who commits or not, but you sometimes get somebody that wants to stick around for the long term.  Especially if you start to give them more resposibility on the project and respect their abilities.  Sure, being so liberal often leads to poor commits and you having to rewrite some things.  The real value here is the unit tests and blazing the initial trail if we’re talking about a new feature.  As long as the potential contributor has unit tests that go along with their bug or feature patch, I’m usually more than happy to welcome them to the community.

What are your experiences?

BTW, liberal policy is my own.  Other projects at Red Hat may or may not be as liberal.

Success for Apache or for ASL?

3 Comments

This is an add-on to my previous post…

Now this Spring acquisition is it really a big win for Apache as Matt says?  Or is it really only a (minor) win for the ASL license?  I would say the latter.  When has there been a business success story for any project hosted at Apache.org on the magnitude of the SS, JBoss, or MySql?  I don’t think the Gluecode guys or ServiceMix guys got much money.

This goes to an original point I made some time ago that Apache.org is a horrible place to build a business as Apache owns your brand.  I know that’s how they like it and to each his own.

Your OSS License Is Mostly Irrelevant

2 Comments

I was reading Matt Asay’s blog on how the Apache license has made its first big business win with the Spring/VMWare acquisition.  In my experience, I don’t think the OSS license you choose has much bearing on an open source business model.  Red Hat/RHEL proved you could build a business and launch an IPO off of GPL-based software.  JBoss proved that you could make a lot of money and get acquired for a lot of money off of LGPL-based software.  Now Spring, at least, has shown you can get a healthy acquisition of ASL-based software.  We now have successful businesses that use the wide spectrum of OSS licenses.  GPL->viral, ASL->non-viral, and LGPL->somewhere in between.

I think what this has shown is that brand is the most important factor in creating an open source business.  If you have a strong brand, it really doesn’t matter if somebody tries to steal your secrets or even fork your project.  Case in point is RHEL.  I remember Larry Ellison stating that JBoss and Red Hat weren’t worth the price tag because Oracle could just steal the code.  Well, they tried it with OEL and have yet to dent Red Hat’s growth or revenue.

I do think though that license can only be a factor to protect you becoming an Apache or Eclipse fork.  Both Apache and Eclipse are strong organizations with strong, instant-brand recognition.  If your OSS license is Apache.org or Eclipse.org compatible, there’s nothing stopping a company or individuals from forking your project and setting up shop at one of these organizations.  Sure, it is a lot harder to build a business off of a project that is hosted at Apache.org or Eclipse.org because you’ve given a large portion of your brand to these organizations, but a fork like this can do a lot of damanage to your own brand.

Case in point, remember 2003 when a few JBoss developers split with the old JBoss Group company and tried to first fork JBoss, then finally ended up creating the Geronimo project?  In retrospect, I think Apache’s LGPL aversion saved us from Geronimo being an outright fork of the entire JBoss codebase.  In the end, I think we still would have won out based on both the leadership, company structure, engineering organization, and the brand Marc Fleury built, but I think it would have damaged us a lot more than a few defectors leaving the company.

All and all what OSS license you pick should be a personal choice rather than a business decision.  Since Red Hat and JBoss’s brand is uber-strong nowadays I’ve seriously considered licensing projects like RESTEasy under ASL to be Apache.org friendly.  Still, on a personal level I’ve always preffered LGPL as its a nice middle-ground between GPL and ASL from an idealistic position…

RESTEasy DZone articles and Beta 8

6 Comments

If you’re wondering why I haven’t done a signficant blog since June, wonder no more.  Instead of creating content for my blog, I’ve written a couple of articles for DZone.com:

Also, today I put out RESTEasy 1.0 Beta 8.  I small tiny bug was found by the community which I rolled up quick into a release.  Follow the downloads link at http://jboss.org/resteasy to check it out.

Older Entries Newer Entries

%d bloggers like this: