What design philosophy for your projects?

2012-04-12  |   |  jboss   oss  

We had a hotted debate recently in the Hibernate Validator team on a given feature. As a result, we started to write down our design philosophy for the library. This is still a work in progress but here it is (original here):

The goal of these projects is to improve developer productivity and ease of use.

When adding a feature, we ask this pool of questions:

  1. Does it feel like the right way of doing things?
    If it is not we tend to wait till the idea matures
  2. Can it be done with an existing construct with similar or less complexity?
    Several ways of doing things is counter productive
  3. Is this feature wrong?
    Does it encourage bad practice for example?
  4. Is this a popular request?
  5. Is this feature useful?
    That is the reason for asking "What's your use case?"
  6. Is it the most readable approach?
  7. Is the feature designed consistently with the rest of the library?

None of these questions should slow down innovation but we want high quality libraries. Keeping them both useful and simple is a constant battle against the easier way of adding features ad nauseum. The team believes it is his responsibility to be the guardian of these principles. We are here to make the world a better place, not give food to guideline writers.

What do you think? And what are your design philosophies?

Packt Open Source Awards and some reflections on CMSes

2011-09-15  |   |  oss   tool  

Packt Publishing, a fairly known technical book publisher is organizing an Open Source Awards contest. Some of the categories are interesting like mobile toolkit and libraries, business applications (always tough for OSS software), Javascript libs and multimedia. It's funny to see the categories evolve over time. Back in my days, it used to be best Java Middleware framework, best database tool etc.

Votes start soon (sept 19th) and end oct 31st. Go cast your vote, it's always nice for an (open source) team to receive such a prize. And no I don't think any JBoss framework is contending.

One of the category is Open Source CMS. Two of the big contenders in this space are Drupal and Joomla!. I have been involved in setting up Joomla! for my friend and... wife. I've got to admit that if I had to do it again, I would use something like Jekyll or Awestruct (my current favorite in this category). The website targeted was fairly simple but very quickly she ran into limitations and badly generated HTML (at least not customizable enough from a CSS point of view). She is a marketing person, so if she has decided that the picture, menu, color, text need to be that way, it must be that way. Teaching her Markdown and a few extra HTML tag is trivial. Heck she even learnt how to hack some CSS sheets. The big limitation is of course the lack of ready to use templates. That's about the main issues for simple solutions like Jekyll or Awestruct.

Next time you deploy a CMS, consider a simpler HTML generator and see if it could fit your needs.

PS: My wife's website is at Innora.fr.

From a Bug blooms a thousand Features

2007-06-06  |   |  oss  

When a severe bug hits a product, you have to fix and release quickly (at least I feel I have to). But, especially in the beta phase, it's fairly humiliating to release with one single ticket resolution.

Call it pride, pair pressure, ego, unwillingness to face reality, teenager knee jerk, I just can't release a beta with one single lonely closed ticket.

This is what happened on Hibernate Search. Beta2 introduced a severe bug in object retrievals. So I ended up coding a few new features, fixing a few additional annoyances to hide the obvious.

That's one of the things I like in the Software as a Service model, transparent bug fixing, but that's another story.

Obviously, such aggressive release cycles can only work as long as a Product Manager don't look over your shoulder.

Who said bugs were a bad thing? ;-)

Licensing and trademark

2007-03-26  |   |  oss  

There has been lots of turmoils last week on two not so related subjects. Let's clarify them a bit.

LGPL rights and duty

Lot's have been said about this license, and lot's of people out there don't understand the rights and duty of this license.

  • Goal
From the GNU LGPL Preambule:
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users.
The goal is to guaranty freedom (of speech) to he users of a given software.

  • Can I use a verbatim copy of a LGPL library in my software? What about my code license? What if I distribute my software?
You can use a verbatim (unmodified) copy of an LGPL library in your code and distribute your application. Your application can use any license (commercial or open source), in other words your code does not fall into the LGPL license. The library remains LGPL of course.

  • Can I modify the library? What happens then?
You can modify the LGPL library, any modification has to be LGPL. If you distribute those modifications, you have to comply with the LGPL and distribute the modified source code as well. In other words, a user of yours will be able to see the code changes and do whatever it pleases him with it provided that he follows the LGPL rules.
Your application (aside from those modifications) does not fall into the LGPL license.

It is usually admitted (while not required), as a courtesy, to provide (all) your modifications to everybody (not only the third party you distribute your application to). It usually doesn't matter in the end, because any of your application users will be able to freely redistribute for free the modifications you made on the LGPL library. There is nothing you can do about it.

  • Goal (once again)
The goal is to be sure that any change to an LGPL library will remain LGPL, be contributed back to the community, and never be hidden in a closed source program.

Check the LGPL license for more info.


A trademark includes any word, name, symbol, or device, or any combination, used, or intended to be used, in commerce to identify and distinguish the goods of one manufacturer or seller from goods manufactured or sold by others, and to indicate the source of the goods. In short, a trademark is a brand name.[1]
A trademark does not prevent you from providing a service based on a given product. It restricts and organize, however, the way you can use a given (combination of) word.
(Protection of) Trademarks is actually a fairly common practice, including in the Open Source world, to name a few
All of them, at one time or an other, have made sure their trademark is enforced.

For all of them, to protect the brand, to protect the message the brand is pushing.

That is the reason why I changed the name Hibernate Lucene to Hibernate Search, it violated the ASF trademark, so I went ahead and fixed it.

To clarify the turmoil with Hibernate, please check the clarification by Mark Webbing. It's in the comments here but I will reproduce it for clarity.

I am writing to clarify the issues raised by the publication of Ms. Robertson's communication on behalf of Red Hat. First, the letter is not placed into the context of the situation it was addressing. That presents the opportunity for misinterpretation. At the same time, I would agree that the letter is less than precise in defining what has been done wrong and the corrective action that is required. Ultimately, that is my fault as the person in charge of trademark enforcement at Red Hat.

Contrary to Gavin's statements above, you cannot offer HIBERNATE Training or JBOSS Training. This is an improper use of Red Hat trademarks in that the marks are being used (a) either as nouns or (b) to promote a good or service that is directly branded with Red Hat owned marks. What is permissable, and I am sure this is what Gavin meant, is that you are permitted to offer HIBERNATE(R) Object Relational Mapping Software Training or, as another example, JBoss(R) Application Server Training. Here the marks are being applied to the goods in a proper manner and it is clear that the training is being provided for that branded technology, not by the brand owner. As a further common courtesy, it would also be appropriate for those properly using the marks in this manner to make clear that they are not in anyway associated with Red Hat or its JBoss Division.

With that clarification I hope I have resolved the confusion and/or discontent around this issue. More extensive information on the permitted uses of Red Hat marks can be found at http://www.redhat.com/about/companyprofile/trademark/

I would also ask, as a courtesy to Ms. Robertson, that the party who posted her letter please indicate that they were the party posting the letter, not Ms. Robertson.

My apologies for any confusion that has been caused.

Mark Webbink
Deputy General Counsel
Red Hat, Inc.


Contrary to some claims, you don't have to have a @jboss.com address to contribute to JBoss projects (I mean commit access). All you have to do is being accepted by the community and the project lead (as any open source project), and sign a contributor agreement (in a similar manner an ASF contributor agreement is signed). To name Hibernate, I can count at least twice as many active contributors not having a @jboss.com address than having one :-)

By the way, I am not a lawyer, so take my words as is etc etc. My dog knows a dog who knows a lawyer, but I am not sure that qualifies me ;-)

Name: Emmanuel Bernard
Bio tags: French, Open Source actor, Hibernate, (No)SQL, JCP, JBoss, Snowboard, Economy
Employer: JBoss by Red Hat
Resume: LinkedIn
Team blog: in.relation.to
Personal blog: No relation to
Microblog: Twitter, Google+
Geoloc: Paris, France