Many organizations have begun to adopt a “risk rating” as part of their open source software compliance and usage discussion. Some of the information gathering requirements to assess risk will be relatively easy to meet, while others require much more effort. There are many factors to consider when assessing risk and as you decide which factors are important to your organization you will need to examine the size of the time investment needed to research and obtain the information associated with each factor.
As part of our ongoing search to improve the way we deliver software, we recently tried Kanban on a new development effort. Ultimately, we ended up taking some of the positive aspects and going back to more Scrum-like process, but the effort was very worthwhile. OpenLogic has been using agile practices for many years now. Like most things, the results are cyclical. Get comfortable for a while and then something changes and forces a period of adjustment. Thus it is important to continually review in order to recognize when change happens that affects processes (and let's face it, change happens very quickly in this industry). Luckily, as engineers, we embrace change. We had the opportunity to look at a radical shift in our agile processes due to starting new development on our CloudSwing product and Kanban fit with some of the ideas we had been discussing. CloudSwing gave us the ability to try out these new ideas without incurring some conversion costs for our much larger codebases.
HtmlUnit was intended to be used for UI testing. For example, let’s say you host an eCommerce Java EE application. In order to perform some testing, you would want to simulate the entire life cycle of a user creating an account, verifying the account, logging in, filling up their shopping cart, and paying for the items.Normal Java testing methods use JUnit and only test the the back-end Java code that runs on the server. This is fine and dandy, but that is not how the user uses the website. You need to use a UI test in order to truly test. While testing the back-end is extremely valuable and should never be forgotten, you are potentially not testing several key things that can only be tested using the actual browser.For example, here are some issues that cannot be tested on the back end:
Before the cloud, it was important to run as many applications as possible on a single server. Why?
The real world example for this level of diligence goes back to having and managing an actionable open source policy. Open source review boards that have monthly, bi -monthly, weekly, or even impromptu daily meetings about what can and cannot be used and under what conditions need the ability to quickly identify and document these occurrences, make decisions, implement critical policy rule changes and communicate all of this easily to the organization. One new or changed file can make a big difference in protecting millions of dollars of development and intellectual property.
In the first two weeks of April, I attended four distinct open source related events in three different cities and two countries. It will take months to ponder, absorb, and follow-up on all of the thought-provoking presentations, conversations, and feedback I participated in or received. In spite of the range of topics and agendas being covered along the way, there were a couple themes that reverberated.
If you read a post on The Enterprise OSS Blog, please leave a comment. Let us know what you think, even if it's just a few words. Comments do not require approval, but they are moderated.OpenLogic reserves the right to remove any comments it deems inappropriate.