RSS Toggle Comment Threads | Keyboard Shortcuts

  • Mike 9:36 pm on August 3, 2008 Permalink | Reply
    Tags: , Road-Map   

    Architecture Rules 3.0 Roadmap 

    UPDATE Aug-30-2008

    • added API package
    • added Listeners
    • added Configuration Properties
    • added default-architecture-rules.xml

    OK, lets lay out a road map for 3.0. I sent this message to the architecture-rules-user mailing list and the architecture-rules-dev mailing list tonight. I have a few things that I want to see put into it, and I’d also like to hear what you want in it.

    org.architecturerules

    First. The big change is the groupId which is finally going to be moved to org.architecturerules for the core project and the maven plugin. I don’t have the domain yet. I have a fund raiser page where I was hoping to get about $30 to secure the domain for 3 years. So far no contributions : \ Maybe if any of your work for a company that uses the project, and the company has donated money in the past, you could ask your boss for a small $30 contribution to this project. Regardless, we’ll get it eventually and the project needs to get off of com.* and the maven plugin needs to be the same groupId.

    architecture-rules-ant

    I want to refactor the ..architecturerules.ant package to its own jar so that:

    • User’s who want to use the ant interface and include this jar.
    • By including the jar, you get the Ant jars and dependencies. If you don’t use Ant, you don’t need the jar or the ant libraries.
    • As we add new functionality to architecture rules someone else could take on the task of keeping the ant task up to date on their own schedule.
    • This module also acts as an example of how to extend the core project.
    • Allows us to develop new ant features and fix ant issues without doing a major release of the core. There are a couple of open ant-related issues in the issue list.

    The downsides is that the API is broken, but I think that is OK given in the release  the packages are all changing to org.architecturerules so the API will be broken anyway.

    Issue 59: DependencyConstraintException should report the violating class

    This is sort of a tough issue. We utilize jDepend which only looks at packages. However, Mykola brought Classycle to my attention (which I included on the alternatives page) which looks at class dependencies rather than package dependencies. We could move off of jDepend and switch over to using Classclye to find dependencies, or we could continue to use jDpend, and when a rule is broken, we can jump over to Classycle to figure out which class is breaking the rule. Another benefit to Classclye is that it is able to detect static dependencies which jDpend is not. I actually got an email from SonarJ, a commercial competitor listed on the alternatives page who congratulated us on developing a good open source architecture risk mitigating project but pointed out that jDepend could not detect static dependencies. I think in the long term we need to support detecting static dependencies so this Classycle might have been an important find.

    Looking to get involved? We’re looking for contributors for this task.

    Issue 60: XML reports

    The only other current issue that I would like to tackle somehow is the output of the XML reports. I sent out a pretty detailed email on this to the user and dev mailing list. I got little response. I put a copy of the email in the issue which includes a prototype for the XML output. The premise would be that the execution of architecture rules results in the output of an XML file that describes all of the rules, the packages that were investigated because of that rule, the dependencies of each package that match that rule, and a list of each violation. One major change would be that instead of throwing an exception when a rule is broken, the rest of the packages would be investigated first and then the XML output is written, and then an exception could be thrown describing all of the rules that were broken – not just the first rule.

    The reason for this XML output is two-fold: first, it provides output for other developers to start processing and developing new tools for which could be good for this project. second: it provides a data source for our maven 2 plugin to use to generate a site report for. Or this could be a new project: maven-architecture-rules-report-plugin. Either way, this is a good stepping stone to new functionality and growth for this project.

    Looking to get involved? We’re looking for contributors for this task.

    FindBugs

    We added the FindBugs report recently to the maven-generated site. We should be able to clear this list for all of our code.

    Remove 3rd party org packages

    I had created an Issue to remove unneccessary dependencies to cut down on the number of libraries that we depended on. But I think this was implemented poorly to the point where it caused a reported bug. Also, we have a pseudo maven repository so that makes this issue almost moot.

    This list encompasses most of the open issues in the issue tracker that I want to see implemented. There are a couple of issues that I am going to leave on hold (such as inverting the project to expect the user to define the accepted packages rather than the exceptional packages) and some that I can not fix with out money (continuous integration server).

    All of these tasks are up for discussion. And most any of them are open to user contributions. If you are interested in taking on one of these tasks, just reply to this email, tell us what you want to work on, what questions you have, and maybe describe how you plan on implementing it. If its a small task, you can submit a patch, if its bigger, we can make you a contributor (for a short term or longer term depending on circumstances)

    UPDATE: Issue 68: Listener Support

    Adding support for event listeners gives us a few different things that we either need or that would benefit us in the future.  This will hopefully invite other developers to begin extending the project. For example someone someday might make a GUI tool or an IDE plugin and want to provide real-time feedback to the GUI as packages are investigated. This also enables us to develop the XML report in a very modular fashion, without littering the services with code that is not related to performing the service that the class is named for. Listeners provide a great point for adding new functionality from too.

    UPDATE: Introduce API Package

    Interfaces will be moved to a new org.architecturerules.api package so that developers who wish to extend the project have someplace to start from. This will break backwards compatibility. But so will migrating to org.architecturerules, so if this is going to be done, it should be done now. Sorry everyone.

    UPDATE: Issue 64: default-architecture-rules.xml

    The initial state of the Configuration entity will be created by reading default-architecture-rules.xml. This essentially just allows us to define the default values via XML rather than defining them with java constants which is what we are doing now. This XML file is easier for the user to read to figure out the default values, is easy to add new default values to as we develop new features, and may be used to demonstrate a sample XML configuration or how features are configured.

    UPDATE: Issue 67: Configuration Properties

    The listeners require some configuration. Some other tools that have yet to be written may also require configuration. We’ll be adding support for arbitrary properties. These allow you to define a set of keys and a values that can be handed off to the Listeners and to other features that may be created in the future. This provides a pretty robust mechanism for providing configuration values for classes that extend the project.

    Maven 2 Plugin SNAPSHOT

    And while I have your attention, Mykola has released a 0.0-SNAPSHOT of the maven 2 plugin. Has anyone tried it yet? Anyone want to try it out?

    Thanks everyone.

    http://72miles.com/architecturerules (and someday architecturerules.org)

     

  • Mike 1:35 pm on August 1, 2008 Permalink | Reply  

    Open Source is Facinating 

    It’s true. Open source is is fascinating. Consider these questions (which have been asked by many):

    How does open source work?
    Why does open source work?
    What motivates the developers?
    Who is making money and how?
    What are the open source business models?
    How ubiquitous is open source?
    What is the future of open source?
    Whats with all of these licenses?

    The questions are asked and answered every day. In books, in podcasts, and in hundreds if not thousands of blog posts. I have been looking for these blog posts and I have found a lot of them – but certainly not all of them. Since I was looking for them and finding them, I figured I might as well share them with everyone else who is interested in what makes open source tick. I setup OssSpyglass.com.

    OssSpyglass.com

    Each day I go out and find these new posts and quote them and link to them on this site. But there is so much out there, I had to find a focus. Here is what i came up with, from the about page:

    We aggregate open source news and analysis from the blogosphere. You’re not going to learn about the next FireFox release here, but you might read about their open source distribution model, or how they transparently develop cutting edge software.

    We are interested in how open source works, why it is successful. We are interested in its past, and its future. We want to know whats going on in the open source communities, and what open source users think. We are interested in analysis and development of the open source movement, culture, and process.

    So hopefully these are topics that interest you or that you find important for the future of your career. If so, come check out the site, and consider bookmarking it or subscribing to the feed.

    OSS Job Base

    A second project that I setup off of OssSpyglass is OSS Job Base, using the open source job board JobberBase. The premise is that there are thousands of open source projects out there looking to find development help be it with coding, documentation, or even testing. There are also developers looking to get onto a project, but don’t want to scour bug lists to find issues to fix.

    This job board is setup for leaders of open source projects to post a task. A typical task post should consist if a couple lines to introduce the project, followed by the description of a task. Then developers can subscribe to these job lists and finally find a worthwhile project to put their time into.

    If you’re an open source project leader, come post a task or two. You might be surprised at how many people want to help you, but just don’t know that you’re looking for help. I am aware of sourceforge’s job list but they are anything but free, and if you have a job listed there I invite you to also post it on the OSS Job Base.

    So come check them out. Comments are are appreciated.

     

  • Mike 7:06 pm on July 29, 2008 Permalink | Reply
    Tags: standards   

    Software Development Standards 

    It all comes down to this.

    When I put this depiction in to word, I would say it as “Industry Standards > Organization > Team > Personal > No Standards“.

    It is that simple. Everyone has standards. However, some standards are more important than others. When developing your own standards you should consider those standards that are greater than you first. So your standards should extend those standards that are defined above your position.

    As an example, consider a Java developer working for a major US Bank.

    Industry Standards

    Most developers have two industry-level standards to consider. First, the language that you are developing in. Our example developer is a java developer. Sun publishes a Code Conventions for the Java Programming Language. This document provides a broad range of guidelines for various facets of the language. Next, consider the financial sector’s software development guidelines. You may or may not be able to find such guidelines, and when you do they will probably not be specific to your language. I’d imagine there are rules for how many decimal places into dollar amounts you should keep, and how to store currency types are all documented somewhere.

    Organization Standards

    Now that you’ve adopted the industry’s standards, look to your organization. You might be a member of a huge multinational corporation, or a small 2 developer shop. Whenever the industry does not cover a specfic aspect of your software, your organization has the opportunity to define standards. These standards may be how to name your SVN repositories, or how many characters long your variables must be. These are things not covered by, for example, the Sun Code Conventions for the Java Programming Language.

    Team Standards

    Your organizaiton may not care about some aspects of their software, but your project manager or project team may still have rules that they follow. These are standards that you and the other developers on your software project or team follow.

    Personal Standards

    Finally, you have a situation where there is no defined standard anywhere. So you get to decide how you will perform some task or format some code. Whatever you decide to do, think it though, and do the same thing the same way next time. Personal standards are important weather you are working in the office or working at home on your own project. You are the same developer on both projects. Your code should reflect that fact.

    No Standards

    Why would you code in one style in the office only to drive home and code differently on your home project. This is chaotic. This can prevent you from effectivly transfering experience from your office projects to your home projects.

    Documentation

    De Facto standards are those that tend to happen not because they are law, but more out of practice. There are no such things as de facto standards. Standards should be and must be documented and developers must know where to find this documentaiton in order for the standards to be effective. This documentation should be easy to find, easy to access, and even easy to update.

    It is sometimes hard to define a standard that covers all situations. When developing your doucmentaiton, you might consider defining the typicial situations that those standards fit into. These leaves the hands of your developers untied so that they can focus on producing high quality software and not be bogged down by unneccesary blanket rules.

    Wikis are great tools for maintaining software development standards for a small organizaiton or development team. They allow team members to update the documentation as new standards are developed and as new situations are encourntered. Other developers can usually subscribe to the wiki to be notified of changes so that everyone is always up to date.

    Why are standards important?

    Following standards are not about making software development harder or more tedious. They are about making development easier and cheaper. InfoQ recently posted an article called Better Best Practices which listed a few great reasons for developing best practices, but it turns out the same reasons for developing best practices hold true for following standards too. Their list is titled “The motivation for Best Practices” but I could easily title this list “The motivation for following Standards”:

    • They ensure consistency. We are introducing [insert initiative] and we want to ensure that everyone goes about it the same way. We don’t want to abandon people without offering them any direction and the alternative would be chaos.
    • They support learning. We are trying to get everyone up to speed on this new approach with the minimum of fuss, and having a standard set of well-structured material means people can see exactly what they have to do, and ideally how well they are adapting.
    • They help limit (potential) impact or damage. (Now we are starting to see their true colours.) In any organisation there’s a bell curve of people’s abilities, and we know that a small but significant number of people will be at the wrong end of it. Implementing this program badly could leave us exposed to significant financial or legal business risks, so we’re going to need very clearly defined practices to protect ourselves. They are called Best Practices because they are tried and tested so I can be reasonably sure they are going to work.
    • They help to build a more mobile and flexible workforce. In these fast-moving times, projects can materialise or be cancelled almost overnight. People move between project teams, projects move between offices, countries or timezones. With all our people trained up to use the same Best Practices we – and they – have many more options in terms of career mobility. We call it “commoditising resources”.
    • They allow us to enforce control. In a large, hierarchical organisation, this is the real crux of the matter. A division manager or vice president may well be responsible for thousands of people. The only way to provide accountability on that scale is to have a system of clearly-defined and strongly-enforced Best Practices.

    What do you think? Are standards a waste of time? Or do they create time? What good or bad experiences have you had with some enforcer pushing standards down your throat. Were those enforcers in the right or the wrong?

     

  • Mike 11:30 am on July 29, 2008 Permalink | Reply
    Tags: licensing,   

    Open Source Revenue with Dual Licensing 

    Introduction

    The aim of this post is to explain how open sourcing a proprietary tool under a duel license can be more profitable than a solely proprietary venture. With such a license you could generate more revenue and share your code and software with the world.

    Dual licensing is a strategy that combines open source distribution with proprietary licensing. I don’t want to spend too much time explaining duel licensing and would rather point out its benefits and how it makes money. But if you don’t know what duel licensing is, wikipedia describes it as

    In this model, one option is a proprietary software license, which allows the possibility of creating proprietary applications derived from it, while the other license is a copyleft free software/open-source license, thus requiring any derived work to be released under the same license. The copyright holder of the software then typically gives away the free/open source version of the software at no cost, and profits by selling licenses to commercial operations looking to incorporate the software into their own business.

    So, in order to use the free half of this duel license, the using organization would have to contribute back anything they develop using your product. This means their proprietary trade secrets are potentially being made available to the public. Many organizations would rather pay a small fee to protect their competitive advantage.

    So lets review some of the ways that duel licensing grants an advantage to business that release their products under two or more conditions.

    Low Cost Distribution

    Open source software depends on the Internet for distribution. The internet is cheap, ubiquitous throughout the world, and fast. There is no need to mail a product to the other side of the world, there is no packaging, Usually the customer uses 100% of their own efforts to get the software. That is to say, the find your site, they download it, and they install it. It doesn’t get any cheaper than that.

    Product Marketing

    First, your product is potentially free. That’s some awesome marketing. So right away you have eyes looking at your tool so you’re way ahead of your proprietary competition. You’ve got the Internet which is almost free to promote your software tool on. And with a good product, you’re going to have advocates around the internet talking up your tool.

    High Margin

    Duel licensing provides a means for producing a very high margin for your product. With a service based offering, in order to offer more services, you need to spend more money – for tools, personnel, time. Duel licensed software requires no additional resources, just enough time to generate and mail out a new license. Once the code is created and ready for public consumption its all profit from there.

    Market Entrance

    You may be able to capture users that you never would have had a chance with if they have not found your product to be free, and then determined that they needed to change it, and thus buy a a license to protect their proprietary information.

    Learn More

    I learned all about duel licensing open source products from a great book called Open Sources 2.0. From amazon:

    “Open Sources 2.0″ is a collection of insightful and thought-provoking essays from today’s technology leaders that continues painting the evolutionary picture that developed in the 1999 book “Open Sources: Voices from the Revolution” .

    These essays are very well written, cover a very broad range of topics, and is written by open source contributors that we have all grown to know and love. Buy the book and check out Chapter 5:Duel Licensing.

     

    • Eric 11:51 am on July 29, 2008 Permalink

      would you have the same revenue benefits if you did not use a viral oss license (e.g. lgpl or apache)?

    • Mike 12:17 pm on July 29, 2008 Permalink

      @Eric – No. Duel licensing will not effectively make you any money if you do not use a license that requires the users to contribute their derivative of your project back to the open source community. The only reason that a business would pay for your license is to prevent themselves from having to share their proprietary secrets.

      So with this type of duel license, other open source projects can use your product without purchasing a license, while businesses that are likely to generate their own revenue with your product will likely purchase the license and generate revenue for you.

    • Tom 6:54 am on July 30, 2008 Permalink

      “So, in order to use the free half of this duel license, the using organization would have to contribute back anything they develop using your product. This means their proprietary trade secrets are potentially being made available to the public. Many organizations would rather pay a small fee to protect their competitive advantage.”

      Hmmm… sounds a bit misleading!! Taking LGPL as an example… organisations using software distributed under this license would only have to contribute back changes/enhancements they make to that LGPL software. They don’t have to LGPL their own proprietary software that has a dependency on the LGPL software. So, your statement that “… their proprietary trade secrets are potentially being made available to the public” is not at all accurate!!

    • Mike 8:58 am on July 30, 2008 Permalink

      @Tom – The more restrictive the license that you use, the more effective the duel licensing will work. I’d recommend the most copyleft you can get: GNU General Public License.

      In fact, I found a specific example. GlassFish is duel licensed. From wikipepdia:

      GlassFish is free software, dual-licensed under two free software licences: the Common Development and Distribution License (CDDL) and the GNU General Public License (GPL)

    • Nick 11:03 am on July 30, 2008 Permalink

      So does this concept of duel licensing involve 50 paces with vintage revolvers as sidearms? I much prefer discussions about dual licensing personally….

      (I’m sorry, I just couldn’t help myself! :-) )

  • Mike 10:32 pm on July 10, 2008 Permalink | Reply
    Tags:   

    architecture rules on delicious 

    I try to keep an eye on what Internet users are saying about Architecture Rules. I checked del.icio.us for architecture rules. Its bookmarked by 60 people, which is pretty cool.

    I read one description which concerned me. Chris suggested in his description that architecture rules as “way to ‘test architecture’, although it seems to be limited to detecting cyclic package dependencies”. Whoa, hold on. That’s not what we are about. Detecting cyclical dependencies is something that we can do, because we wrap JDepend, but the whole point of the project is to assert that the Rules that you have defined are not violated.

    So, I tracked down Chris’s email address, which I found in his resume, which I found on his site. I emailed him.

    I started by apologizing for the unsolicited email. Next I explained that I found his comment delicious, I reiterated his comment to him, then briefly explained and showed (with XML) how architecture rules was about asserting architecture through the definition of rules. I sent off the email assuming that Chris probably wouldn’t read it, and certainly wouldn’t respond favorably. Fortunately, I underestimated Chris.

    Chris wrote back to me and thanked me for taking the time to write to him. He also pointed out that it is “always a good sign to me when an open-source project is interested in what people are saying about it.”

    I just wanted to share this experience. I have no great analysis of it yet. I hope that it might encourage you to think about reaching out to your user base weather they be paying customers or users of your open source tool.  After all, thats why we write the code, right? To satisfy the end users, to make their jobs easier, or to change the way that people do business.

     

    • Jamo 8:05 am on July 17, 2008 Permalink

      Wow, I’m glad you didn’t catch me talking bad about your project on some obscure forum somewhere!! I’ll be sure to call it arkitexture rools to avoid discovery!

    • Mike 10:12 am on July 17, 2008 Permalink

      @Jamo – I think if you are talking bad about the project you have already discarded it and are not going to use it. I would not try to convince you otherwise with an email.

      This particular prospective user, however, just didn’t realize the full potential of the project so I went out on a limb and sent him a targeted email. Hopefully we got a new user.

  • Mike 9:37 pm on July 10, 2008 Permalink | Reply
    Tags: Add new tag,   

    architecture-rules 2.1.1 

    It is an open source project. That means our failures are out there for everyone to see. Read about our major release that contained a major problem. Hopefully can learn from our mistake (and we get some of those users back).

    2.1.0 Release not so Good

    Architecture Rules 2.1.0 was released this past weekend. It was going great. The project was getting a lot of attention on dzone, freshmeat.net drove some good traffic, it made the front page of The Server Side’s news section. All of these sites brought in a huge 128 downloads over the weekend while the previous version was out for seven months and only claims 222 downloads (by the way, I hope there are many times more users using the maven repository, which we don’t yet track for downloads). So it was a good weekend. And then it was pointed out that wildcards don’t work…

    What Happend?

    We implemented wildcards a few weeks ago and released a 2.1.0-SNAPSHOT for users to test out. Unfortunately, we don’t have a huge number of early adopters who are pulling down snapshots. So It seemed worked well and we planned a release for the weekend of July 4th.  On June 29th, I got a friendly email from Andrew Swan. He had graciously taken the time to review the 2.1.0 code before the release. He discovered that the JPackage equals method delegated the work to the JPackage matches method. This broke the contract of the Java equals method because, in his words, “if a.equals(b), then b.equals(a) should also be true.” We all know that he is absolutely 100% correct. He even pointed me to Effective Java. We were excited to have Andrew reviewing the code and of course wanted to fix this problem. So we modified each reference to JPackge.equals to use JPackage.matches, ran our tests, and got a green “tests pass 82 of 82″.

    I quickly followed that up by creating the binaries, committing everything to SVN, updating the documentation, and promoting the 2.1.0 release. However, one reference to .equals remained in the AbstractRuleService. This is the service that itterates over each package defined in each rule and checks to see if a given package is dependent on a package that it is not allowed to depend on. So now, if a package is defined using wildcards, it tries to match “com.company.application.*”, the String, to fully qualified String such as “java.util”. Of course, no package is ever going to be named with an asterisk character, so now if a package is defined with a wildcard, its not looked at. So wildcards are busted.

    What Now?

    Now, we released a 2.1.1 just to fix this bug and pray that the 128 (and hopefully many many more though the maven repository) java developers who are rightfully concerned with mitigating architectural risk take some time to come back and grab the 2.1.1 release.

    We have fixed the problem and quickly put up 2.1.1. Please download it, or update your pom.xml, give us another try, and Assert your Architecture.

     

← Newer Posts | Older Posts →

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
esc
cancel