Yet another reason to avoid Apache.org

August 29, 2009

billburke flame bait, JAX-RS, opensource 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

August 28, 2009

billburke opensource 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?

August 16, 2009

billburke business, opensource 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

August 13, 2009

billburke opensource 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

September 22, 2008

billburke java, JAX-RS, jboss, opensource, REST, Webservices 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.

@See why I’d never develop at Apache

May 23, 2008

billburke flame bait, opensource 13 Comments

I was forwarded a pretty interesting (and funny) email thread on Apache MINA‘s mail list.  It seems a MINA developer was upset that a particular checkin did not have @See Javadoc comments.  So much so, he vetoed the commit.

“I’m on the project *management* committee.

I would like to see the code you commit adheres to some standard.

Until this is resolved my right to veto holds so please revert your commit until we figure out the best choice for Javadoc. If you won’t revert it, I can do it for you.”

A huge flamewar ensued thereafter.  This is why I would never, ever host an open source project at Apache.  Its not because a silly flamewar happened over a trivial issue.  We had a similar one errupt over Steve Ebersole putting in SL4J in Hibernate.  Poor Steve had a few of us flaming him.  In true JBossian fashion, Steve, the project lead, basically said, “bleep you.  I’ve researched the issue thoroughly and I’ll do what I want and think is right.”  No, the actual reason I’d never go to Apache is that anybody is allowed to veto your commit via the Apache rules:

“PS : for the record, here is the veto definition (http://www.apache.org/foundation/glossary.html) :

*Veto* According to the Apache methodology, a change which has been made or proposed may be made moot through the exercise of a veto by a committer to the codebase <http://www.apache.org/foundation/glossary.html#Codebase> in question. If the R-T-C <http://www.apache.org/foundation/glossary.html#ReviewThenCommit> commit policy is in effect, a veto prevents the change from being made. In either the R-T-C or C-T-R <http://www.apache.org/foundation/glossary.html#CommitThenReview> environments, a veto applied to a change that has already been made forces it to be reverted. Vetos may not be overridden nor voted down, and only cease to apply when the committer who issued the veto withdraws it. All vetos /must/ be accompanied by a valid technical justification; a veto without such a justification is invalid. Vetos only apply to code changes; they do not apply to procedural issues such as software releases.”

Imagine going to your boss or project lead at work and saying “I veto this commit.”  How hilarious would it be to see the look on their face?  Seriously though, democracy just doesn’t work in software development.  There are too many ways to skin a cat in software.  Its hard enough to get code released on budget and on time without some stupid random schmuck vetoing your work.

BTW, if you think this is funny, check out this old PMC complaint.  In this case, it wasn’t a developer vetoing a commit, it was some Apache bureaucrat putting down the hammer.

Resteasy JAX-RS 1.0 Beta 2 Released!

April 7, 2008

billburke java, JAX-RS, opensource, REST, Webservices 2 Comments

I finally got around to creating a new release for the next rev of our JAX-RS, Java RESTful Web Services, implementation. This release targets the 0.7 release of the JAX-RS specification. There’s a still a few features I haven’t implemented yet, but hope to get them out soon as the spec starts to solidify. Especially new in this release is a new embeddable container so you can run things within junit tests, or just serve up a small restful web service from your classpath. We’ve been using this embeddable container to unit test our implementation and finally made it available to the masses.

Check out our project page or download the new release.

Release Notes – Resteasy – Version Beta2

Bug

  • [RESTEASY-1] – DefaultPlainText.MessageBodyWriter should not write anything (arrays especially)
  • [RESTEASY-2] – If Response has set Content-Type, then that content type should be used
  • [RESTEASY-9] – Subresources erroneously considered as root resources
  • [RESTEASY-17] – Spec mandates supporting MultivaluedMap for form-urlencoded media types
  • [RESTEASY-18] – @QueryParam should not return x-www-form-urlencoded parameters
  • [RESTEASY-24] – WebApplicationException and http status codes

Feature Request

Task

  • [RESTEASY-4] – Implement variants
  • [RESTEASY-13] – Support @Context field injection
  • [RESTEASY-14] – Support @Context injeciton of HttpServletRequest/Response
  • [RESTEASY-16] – Support injection of javax.ws.rs.core.SecurityContext
  • [RESTEASY-19] – Support for StreamingOutput
  • [RESTEASY-23] – Integration test for SecurityContext

Radiohead and Open Source

November 7, 2007

billburke business, opensource 2 Comments

Let me preface by saying I’m an old man. I have never ripped and burned music CDs. I don’t have any music on my iPod (only TV shows and movies). And if you’ve read Why Angry Bill? you know that I don’t listen to music on the radio. So, if this blog is old news to you, then apologies.

Was on Google news today and saw discussion on the band Radiohead’s attempt to give away a free album with fans deciding how much they wanted to pay (if at all). The article said that only 38% of downloaders decided to pay anything and marked it as a failure. I was scratching my head at this. A failure? A disappointment? Are you bleepin crazy? I don’t know what the ratio is now, I’m out of the loop on such discussions, but pre-acquistion, I know JBoss’s percentage of paying users was something like 5%, and they got 38%? IMO, that’s a huge success! If JBoss had had that ratio of paying users we would have gone public in 2004 instead of getting bought-out in 2006. The article then went on to say that the band must average $1.50 per download to break even (they’re currently averaging $6.50 per download, pretty good margin!).

Most of the articles on the subject questioned whether the Radiohead model would work with smaller bands since Radiohead already had a strong brand and a fanbase of millions. I think the business model could parallel the evolution of an open source business model. Really, all it is is establishing a trademark and cross-selling your ‘free’ offering to what value-add you are selling.

In the beginning of an open source business, your main value-add is usually consulting and training. This is business that brings in easy revenue, but that you can’t scale effectively because of the amount of people that is required to drive this. For the music world, maybe a band could cross-sell on-site gigs. Yeah, maybe this is unrealistic to expect a fan to want to book a particular band, so something more creative is needed. Maybe the music download would require the fan to solely enter in their age and zipcode. Then the band could know where they are popular. For instance, if they were very popular in the Greater Boston area, they could call up nightclubs in the area and say “Hey, 100 people downloaded our album in Boston. There’s a good chance we’d be able to fill the place.” As the band gained a small following, this information could be used to drive up their fee.

Another way JBoss bootstrapped themselves was through documentation sales. At the height of this these sales totally funded the salary of Scott Stark, and subsidized the salaries of me, Dain, and Sacha. For a band, it could be as simple as selling a professional PDF of their song lyrics. Would you be willing to pay $1 for a printable PDF of your favorite band’s song lyrics? Then there is of course always band merchandise of t-shirts, mugs, towels, posters, etc. All this stuff is so easy and cheap to set up to sell online. We did it at JBoss.

The last step in the evolution of an pure open source business is selling subscriptions. This is where I’m at a loss of how a music band could push such an offering. There is always the possibility of going un-pure. Radiohead seems to be doing it by cross-selling their $80 dollar deluxe box set. JBoss did much of the same with JBoss ON. I know other open source companies are taking similar tacts.

All and all, it might be hard to break even on the Radiohead “honesty box” model for small startup bands, but there’s a lot of creative different ways I think bands could make money off of free IP. I really think open source business models could be applied to other forms of IP. It will be interesting to see how this evolves in the music industry and kudos to Radiohead for thinking out of the box.

Websphere Children’s Edition

August 9, 2007

billburke business, flame bait, opensource 4 Comments

Its funny to see Novell re-hash a 10 month old press release that it is bundling Websphere Children’s Edition with Suse. My favorite quote from this newsclip is:

Users looking for more advanced features are steered towards paid WebSphere products, which offer more advanced features.

This is why we will never take Apache Geranium seriously.  As long as IBM is the major contributor to the project, they’ll never be interested in elevating Geranimo to the feature set of JBoss.   It will always be a hobbled platform.  This is why you should always read the fine print in vendor friendly open source projects.  If the project is dominated by a vendor which has a competing closed-source, expensive product, the project will never get anywhere.

Apache Business Model failure

July 17, 2007

billburke business, opensource 1 Comment

I recently read on TSS how Iona is rebranding their ServiceMix acquisition. This is what sucks about the Apache model. If you ever want to build a business upon an Apache project, you’d have to spend your own time and money to create your own brand. It begs the question, what did Iona get from purchasing LogicBlaze? Since they are rebranding ServiceMix anyways, why not just hire away great developers like James Strachan instead of ponying up all this money to LogicBlaze’s VCs?

Your only value as an Apache.org based business is your people and your customer list. This is why I would never ever start a project at Apache.org. They own the brand. Its harder for you to cross-sell without competition. Without a strong brand, what incentive does a company have to acquire your business as a whole? Why not just hire away your developers and sales people instead? Its hard enough to build a successful business with a brand, why make it harder by hosting yourself at Apache?

I’m not saying that Apache isn’t a great organization. It is in many respects. But as a OSS developer, you have to really think about the pros and cons before starting up shop there.

If you’re looking for a different opinion, Savio Rodrigues has some great contrary opinions on business effect of the Apache model both on companies and users. You’ll have to dig around in his archives though.

Older Entries Newer Entries