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.

@See why I’d never develop at Apache

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!

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

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

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

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.

Co-existence with Hibernate, JPA, and EJB3

15 Comments

How can you slowly migrate existing Hibernate apps to JPA? How can you use Hibernate features and unique mapping capabilities with a JPA deployment? How can you take advantage of EJB3 injection and persistence context management with Hibernate? In this blog I want to show how Hibernate, JPA, and EJB 3.0 can co-exist and compliment one another. This information is fully documented between the Hibernate and JBoss EJB3 projects, but I thought I’d highlight them in this blog to make the community aware that they exist.

Mixing and matching JPA annotations within Hibernate

Using the standard JPA annotations helps out greatly in cutting down the amount of XML metadata you have to type. This annotation metadata is an exact replacement for much of the metadata in hbm.xml. Using them does not require you to use the JPA EntityManager interface. You may still use SessionFactory and Session objects to interact with your database. After downing the Hibernate Anotations project, setting things up is fairly easy:

SessionFactory sessionFactory =
                  new AnnotationConfiguration().buildSessionFactory();

You use hibernate.cfg.xml to specify which exact classes you want mapped by this SessionFactory:

<hibernate-configuration>
 <session-factory>
    <mapping class="com.acme.Flight"/>
    <mapping class="org.jboss.Sky"/>
    <mapping resource="org.acme.orm.xml"/>
 </session-factory>
</hibernate-configuration>

You can mix hbm.xml mapping files with new annotated classes. XML resources can also either be JPA-based XML or Hibernate based. This mixing and matching allows you to quickly prototype new mappings using JPA, but allows these mappings to co-exist with older Hibernate 3 applications.

There are a few more options for configuration. Check out the Hibernate Annotations documentation for more information.

Use Hibernate to configure JPA

If you want to use the JPA Entity Manager API to code a portable application, you may still want to use Hibernate metadata to map your beans. Although the JPA orm mapping is pretty rich, it is still a subset of Hibernate’s functionality. The Hibernate Annotations project provides additional Hibernate-specific annotations to elaborate a persistence mapping where JPA leaves off. If you prefer XML, you can use hbm.xml files to define the mappings for your entity beans. When loading a persistence archive, Hibernate Entity Manager will automatically scan the .jar file for any *hbm.xml files and add them to its mapping information.

Hibernate specific configuration is defined in the properties element of the persistence.xml file. You can configure any hibernate property within this XML blob

<persistence>
 <persistence-unit name="manager1" transaction-type="JTA">
    <jta-data-source>java:/DefaultDS</jta-data-source>
    <properties>
       <property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect"/>
 </persistence-unit>
</persistence>

You may also define all your hibernate configuration in the usual Hibernate way: within a hibernate.xfg.xml file. You must tell the JPA implementation to use this configuration file through the hibernate.ejb.cfgfile property.

<persistence>
 <persistence-unit name="manager1" transaction-type="JTA">
    <jta-data-source>java:/DefaultDS</jta-data-source>
    <properties>
       <property name="hibernate.ejb.cfgfile" value="/hibernate.cfg.xml"/>
    </properties>
 </persistence-unit>
</persistence>

EJB 3.0 managed persistence sessions

EJB 3.0 has some nice integration with JPA. You can have your EJB session beans manage persistent sessions for you, freeing you from having to create, destroy, and clean up your persistence sessions. It can manage your persistent sessions in two ways:

Transaction-scoped persistence contexts

Transaction-scoped persistence contexts can be injected into your stateful, stateless, or message driven beans. These transaction-scoped contexts only live for the duration of the JTA transaction they are invoked within. When you first interact with an injected transaction-scoped EntityManager within a transaction, an underlying persistence context (in other words, a Hibernate session) is transparently created and associated with the transaction. This associated context is propagated automatically to an nested EJBs that invoke on entity managers of the same persistent unit type. This means that any EJB that invokes on an entity manager will be using the same underlying Hibernate Session.

@Statelesspublic class MyBean implements MyInterface {

 @PersistenceContext(unitName="custDb") EntityManager manager;

...

Extended persistence contexts

In Hibernate terminology, an extended persistence context is one particular Hibernate session. This session may live beyond the duration of a JTA transaction. In EJB 3.0, you can inject an extended persistence context into a stateful session bean. Unlike transaction-scoped entity managers, these persistence contexts are not created and destroyed in a transaction, but instead have their lifecylce tied to that of the SFSB session. This allows you to have conversations with your database that span multiple JTA transactions.

@Statefulpublic class ShoppingCartBean implements ShoppingCart {
{
 @PersistenceContext(unitName="custDb", type=EXTENDED) EntityManager manager;
...
}

Using EJB 3.0 injection annotations with Hibernate

The JBoss EJB 3.0 implementation allows you to use Hibernate Session and SessionFactory as types for targets of the @PersistenceContext and @PersistenceUnit annotations. The injected Session or SessionFactory will behave exactly as if you were instead using the JPA counterparts EntityManager or EntityManagerFactory:

@Statelesspublic class MyBean implements MyInterface
{
 @PersistenceContext(unitName="custDb") org.hibernate.Session session;
 @PersistenceUnit(unitName="custDb") SessionFactory factory;
...
}

Just like with the EJB 3.0/JPA integration, the Hibernate Session will be associated with the JTA transaction and propagated to nested EJB invocations within the same transaction. It is also ok if these nested calls use the EntityManager API instead. The same underlying Hibernate session will still be used for both.

Hiberate Sessions can also represent extended persistence contexts:

@Statefulpublic class ShoppingCartBean implements ShoppingCart
{
 @PersistenceContext(type=EXTENDED) org.hibernate.Session session;
...
}

Again, the EJB container will manage this Hibernate Session the same way it would manage an EntityManager instance.

Obtaining Hibernate objects programmatically

You can always get access to a Hibernate Session object from an EntityManager instance through the standard EntityManager.getDelegate() method. This is a JPA specification feature.

  @PersistenceContext EntityManager manager;
  ...
{      org.hibernate.Session session = (Session)manager.getDelegate();  }

The specification, however, does not provide a way to get at the underlying implementation of a Query. Hibernate should provide most of its extended functionality through JPA query hints. For example, lets say you wanted to enable a query cache:

  javax.persistence.Query query = manager.createQuery(...);
  query.setHint("org.hibernate.cacheable", true);

Conclusion

Hibernate and the JBoss EJB 3.0 project provide multiple ways in which you can mix and match Hibernate and JPA annotations and XML metadata. JBoss EJB 3.0 can manage Hibernate typed objects the same way it can manage JPA objects. Finally the specification provides programmatic ways to get at the underlying Hibernate connection. With the features you should have the flexibility to get at the HIbernate features you need while staying as portable as possible under the JPA specification. Or conversely, you can use well-defined JPA mapping annotations within your Hibernate deployments to make coding simpler and easier.

Disclaimer 😉 This blog was meant to make you aware of certain integration features that exist between JPA, Hibernate, and JBoss EJB 3.0. You should not use it as a reference guide, but rather dive down deeper into each project’s docoumentation. Have fun.

Newer Entries

%d bloggers like this: