This is a reprint of a fantasy authored by Yutaka Kachi and translated by Mikiko Kachi. Originally from http://www.catch.jp/openoffice/whats_oss/index_en.html.

I am reprinting it because it is only available through PDF. I want to share it and make it easier to read and comment on. I found it in 2005 and saved the PDF. I found the the file this morning and thought it would be good to share and discuss.

Long long time ago, there was a tree in a field of grass near a village. One day, this tree bore a lot of delicious fruit.

The fruit were very delicious. So villagers soon harvested all of the fruits.

There was no end to the number of people who cut branch of this tree and take them home.

Because of this, the tree died in a few years.

In the village, there was a clever merchant. He grafted the tree before the tree died.

And he fertilized the tree, cut off branch when it’s too much. He took care of the tree for a long time.

Then the tree bore fruit. He sold it and made big money.

He was a real worrier. He fenced around the tree and was always watching the tree.

This merchant was not just an worrier, but also a hard worker.
His effort made the fruit more delicious and a lot of people bought it.

Some people delivered it to busy villagers, and some people made jam from the fruits and sold it.

The merchant monopolized the fruit tree.

When someone said to him “ there are many worm holes ” , he heard nothing of it and said “ It’s cheap so you can’t complain that.”

When someone asked him “ do you use any harmful fertilizer?”
he said “ it’s company secret” and wouldn’t answer that question.

When someone offered him “ I’d like to buy branch”, he said “ I don’t want to have competitors” and rejected the offer.

More and more people started to sell the fruit and more and more people bought it.

Then the merchant increased the price and made a big profit.

In this village, there was a young man who really loved this fruit. When the merchant increased price of the fruit, he couldn’t afford it any more because he was very poor.

So, he got interested in another tree near the village. This tree also bore a lot of fruit, but its taste was not so good and no one had cared for it. The young man started taking care of it with his friends.

Therefore, the tree bore more fruit than they could eat. So they put up a sign board that said “ Free”. There were some people who take the fruit away although they didn’t take care of the tree, but the young man didn’t mind at all.

The young men kept making effort for years to improve taste of the fruit as much as possible. Some people who took the fruit said “ I will help you”, “I will help you too because we don’t want to kill this tree like the first one” and helped doing time-consuming works.

The more people helped, the more people took the fruit. When the fruit run short, the people grafted the tree to grow more. They put up “ Free” sign boards on new trees also.

Some people delivered the fruit, and some people made jam from the fruit. They were very cooperative and sometimes they pay for agricultural equipment, fertilizer and inviting specialists to get advise.

So they reduced warm holes, improved the taste of the fruit, and their fruit became much more popular.

Years later, many fruit trees were planted around the village and bore a lot of delicious fruit.

The villagers started delivering the young men’s fruit together to far-off town. In that town, many people said “I’ve never had such a delicious fruit !” and the fruit became popular. It sold like hot cakes.

And not only the young man but also his friends and villagers all became happy.

By the way, what happened to the merchant who monopolized the fruit tree?

His business was also going well. For only a short while he had a fewer customers, but he expanded his business by hiring many people, shipping the fruits to far-off town, buying up fruit trees which had grown in other villages, etc.

There was no difference between the young man and the merchant in terms of making delicious fruit.

This is a great, simple explanation of how open source works and why the model it is successful. Growing a fruit tree is relatively easy compared to writing software, but as software development tools get easier to use, and more people learn to write code, it was and is inevitable that the number of open source tools and the quality of those tools will increase.

There are two more PDFs that talk around open source licensing at http://www.catch.jp/openoffice/whats_oss/index_en.html.

Architecture Rules is proud to announce that it now support wild cards.

Benefits of Wildcards

Wildcards bring the ability to match multiple packages with one Rule entry. This falls inline with the original goal of the project, which was to simplify the usage of jDepend and to define rules in a way that is very readable, understandable, and modifiable.

With wildcards, users can now define a package or violation in one line with the ability to match many packages. This means you won’t need to update your Rules each time you add a new package and your XML configuration file will be much shorter.

Wildcard Patterns

We identified a few different Wildcard Patterns. Some we don’t support and don’t plan on supporting, others we do support, and there are still a couple that we want to add.

Here is a description of what we now support:

Example

Now creating a rule to assert that the web layer does not interact with the DAO (or integration) layer is as easy as:

<rule id="web-layer">
 <comment>web and dao mix like oil and water</comment>
 <packages>
  <package>com.company.app.web..*</package>
 </packages>
 <violations>
  <violation>com.company.app.dao..*</violation>
 </violations>
</rule>    

Prior to wildcards, you might have needed to define ..web.controllers, ..web.filters, ..web.views, ..web.forms, ..web.tags as the packages, and then you would have had to defined every ..dao package as a violation. Now its easy!

Implementation

Architecture Rules uses Regular Expressions to compare the packages with wildcards against the inspected packages. The regular expression needed to be able to handle exact packages, one package deep, and one or more packages deep. We accomplished this by modifying the given package with wildcards (such as com.company.project.*) to apply regular expression characters.

Thank you to Ryan Stewart for helping us hash out this expression. This is what we came up with:

final String regex = this.path
    // foo.bar exactly foo.bar
    .replaceAll("\\.", "\\\\.")
    // foo.bar.1 or foo.bar.1.2 and so on...
    .replaceAll("\\\\.\\\\.\\\\*", "\\\\.\\[A-Za-z_0-9.]")
    // packages only
    .replaceAll("\\.\\*", "\\.[A-Za-z_0-9]*");       

The break down is this: The third line of code looks for ..* combination and replaces it with the regular expression to allow for any string with any number of periods.

The fourth line of code looks for the remaining .* combinations and replaces it the an expression to match package name but no more periods.

If you consider yourself a regular expression wizard, please consider taking a moment to review this and offer any feedback or suggestions that you might come up with. Thank you.

Outstanding Issues

One usability issue that we have uncovered is the matching of the package prior to the wildcard. For example, some users think that com.company.project.* should match com.company.project in addition to the packages under project. Others aren’t sure it should match ..project. As of right now ..project is not included as a match. We are open to comments on this and welcome feedback from the early adopters.

Roll Out

Wildcard support has been slated for the 2.1.0 release which should happen any day now. We are just waiting for a couple of our early adopters to test the wildcards with the 2.1.0-SNAPSHOT that is currently in the maven repository.

If you’ve been waiting and can’t wait to try it out, or if you can help out with testing, just grab the jar, or add our repository and dependency to your maven pom.xml.

Thanks

Finally. Thanks you to Andrew Swan for hounding us to get this feature implemented and for sticking with us while we worked on it. Also thank you for testing it for us. Thank you, again, to Ryan Stewart for helping out with the regular expression. And as always, thank you to Mykola Nickishov for working diligently on the Maven 2 plugin that will be released with the 2.1.0 release of Architecture Rules.

And thank you to you for reading this far. Now go get Architecture Rules and start Asserting Your Architecture!

I don’t know the answer. Its a question not a statement.

So lets say you’re a developer who programs in a corporate environment. You’ve found some great open source tool that you want to use at work, but your organization doesn’t use open source software. What do you do? What are your options? Where do you start?

What if you’re a manager. You don’t write code, but you’ve read about open source and think it can help your guys write better code, faster. What course of action might a middle-tier manager take to get open source into the hands of your developers?

Finally, put yourself in the shoes of your CIO. You’ve been to the conferences, you’ve enjoyed you’re free muffins and you’ve been convinced that open source is the way to go. What can you, the CIO, do to push open source down upon your developers?

Thanks for reading, but this post really requires your participation. Please share a thought or two…