Microsoft, NASA and Open Source

All Posts
  • Port25

    What does business readiness of software really mean?

    • 0 Comments

    by jcannon on July 18, 2006 02:15pm

    There is a buzz word floating out there – “business readiness”. It seems everyone (including people here at Microsoft) are trying to capture something important to organizations and people that are responsible for selecting, deploying and maintaining software for businesses. What does it really mean though?

    Does it mean that a software package, distribution or application meets a benchmark? Does it mean that it is supportable without getting the Big Three consulting companies involved? Does it mean that all its functionality has been tested using regression test cases? Does it mean performance and scalability of the software meets needs?  Does it mean that the software will be kept alive into the future by a vibrant community?

    In my opinion it means all of the above.

    So, what is the problem?

    The problem is that business readiness is in the eye of the beholder! (Definition of beholder – the dude who happens to be holding the software when the music stops!)

    I think this is a complex problem for two reasons

    1. It is really hard to objectively measure “business readiness” for any piece of software. How would you assign a rating to software? What all would you need to consider? More about this later.
    2. Organizations may decide for business reasons that “business readiness” is not the most important factor in adopting software.

      In the good old days, when the startup I founded was in the throes of finding its first customers – a mid-sized company decided it liked us. We made B2B software – basically a marketplace engine /procurement engine / supply side engine.  The customer decided that using our software would be advantageous for them because our engine could be easily adapted to run many different models that they wanted to try out, at little cost. They knew we were still early in our product cycle but they were willing to act as guinea pigs for the business advantage that they would gain. They also benefited from the fact that they wouldn’t have to hire the engineers or the operational support people to maintain the software and that their features would find priority in our product roadmap. I would say that our software was not completely “business ready” at the time (more like early beta quality) but that we were able to help attain the business objectives of the customer, while helping our product move towards business readiness.

    I will concentrate on the first point  – how do you objectively measure business readiness, and suggest a way to look at this. This is not a recipe, just a few thoughts on what we should pay attention to.  Hopefully you can dive into the suggested links and find stuff that helps you evaluate the business readiness of some software you are considering.

    There are many levels at which software must be evaluated – I assume here that the functionality of software is not the issue. Of course this is a big assumption, but the evaluation of software “features” is a better understood art than the non-functional aspects of software. (There is even a term called “non-functional requirements” while doing requirements and specifications – I never quite got my head around how something that didn’t function could be a requirement!).

    What is the state of the art?
    This is a question that is very hard to answer. For any piece of software the best most people can do is to compare it to its competitors in the marketplace. Most organizations that use open source would not have the luxury of having the commercial software to compare against. They would have to rely on word of mouth or other such imperfect evaluations.  Even for most commercial software it is hard to get a good grasp of how that software compares with other software.

    There are some organizations such as ISBSG (International Software Benchmarking Standards Groups) that is a non-commercial organization that collects data about software projects and quality. This data is submitted voluntarily by organizations that are software organizations all across the world in many different areas of software. The software for which such data is submitted is largely proprietary and commercial.

    A good use of ISBSG data would be to compare defect density within an open source project to the benchmark for that kind of application within the ISBSG data. This would serve as an indicator of the quality of the open source software.

    Other data available includes “cost per function point” for a project – this can help evaluate if the cost of the project/product to your organization is close to the “standard” price for good quality projects for the application area chosen.

    Evaluating the software
    Once the gold standard is known other evaluation criteria for the software at hand can be applied. The gold standard provides an quantitative upper bound in terms of number of defects and cost. But IT departments do not run on cost alone….

    For open source software there are a number of evaluation benchmarks/certifications being made available. However, the criteria used to evaluate open source doesn’t exist in a vacuum – it is based on hard earned lessons in software development in general. I think that these criteria apply to all software whether open source or commercial software.

    Some of the standards bodies out there include:

    1. OpenBRR (www.openbrr.org)
      This organization is proposing a standard model for rating open source software software. The criteria proposed include Functionality, Usability, Quality, Security, Performance, Scalability, Architecture, Support, Documentation, Adoption, Community and Professionalism. It will be interesting to see how this evolves – I think a lot of work needs to be done in this area and a promising start has been made. What OpenBRR has going for it is that it is an industry wide effort incubated by a respected university (Carnegie Mellon – please excuse my bias! J) and is committed to involving open source committed companies to the process of generating the model.
    2. OSMM (Open Source Maturity Model) by NavicaSoft
      This has been proposed by Navicasoft a professional services firm focused on open source, providing strategy, implementation, and training services to its clients. The OSMM model considers the following factors Software, Support, Documentation, Training, Integration and Professional Services. Practitioners calculate overall product OSMM scores for products. OSMM has a little bit more momentum, being around longer than OpenBRR, but is less comprehensive or “academic” in its approach – being tied to one company rather than being from an independent organization may not play in its favor.
    3. OMMM (Open Source Maturity Model) by CAP-GEMINI
      This is pretty comprehensive model which aims to generate a “score card” for open source products. It applies the criteria of Age, Licensing, Human hierarchies, Selling points, Developer community, Modularity, Collaboration with other products, Standards Support, Ease of Deployment, User community and Market penetration to generate the score card. Since the model has been developed by a consulting organization there is well framed process to apply this model. They have recently moved the project to the  www.seriouslyopen.org  repository.

    There is nothing stopping you from considering criteria from each of those models to evaluate the “business readiness” of the software you are concerned with. I suspect that any good model will show comparable results, or the discordant models will fall by the wayside!

    Show me the money
    In their “Expert Letter” ,CAP Gemini - developers of the OMMM model,  try to make the point (somewhat unconvincingly in my opinion) that  because commercial software is developed differently from open source it has to be evaluated differently.

    In my opinion, its all about the value the software provides.  If the value can be derived down to dollars, that may be the best way of convincing people.

    Khaled El-emam, has this cool ROI process that starts with software metrics such as number of bugs and ends up with a dollar calculation about how much a software product/project will cost the users in terms of “cha-ching”. Maybe every product needs to be put through this “business readiness” measurement!

    I am now thinking about visualizing the business readiness using some cool graphic tools – “be the software, be the soooooooftware” (apologies to “Caddyshack”!)

  • Port25

    Hank Just Blogged About Critical Thinking

    • 0 Comments

    by admin on July 17, 2006 06:00pm


    Hank just blogged about critical thinking.  If I had to state my own concise definition of what lies at the heart of critical thinking, it would be a personal commitment to finding the right solution to any problem, regardless of whether or not figuring it out and the subsequent implications are easy or comfortable (in practice, this usually means being the resident skeptic right at the point everyone else is getting excited.)  This is not necessarily a comfortable thing to do:  we tend to have a psychological affinity for propositions that confirm or reinforce, rather than challenge, our existing beliefs.  And there are many sources of social and institutional pressure  that militate against “naysayers” and “people who make things more complicated than they need to be.”  Moreover, no matter how many tools the hardcore skeptic has in his or her toolbox—years of accumulated experience and wisdom, technical savvy, statistics and operations research skills, or sharp psychological intuition—the context for bringing those tools to bear is seldom ideal. 

    As an example, consider a team trying to lock on a project plan under some challenging time constraints:  success means leaving the room with (1) agreement on a plan; (2) shared conviction that the plan can achieve the team’s goals, if every contributor executes against their commitments; and (3) an accurate understanding of the probability of achieving the goals.  From experience, you probably know (1) and (2) are difficult enough—now think about being the one person in the room who says “you know, if you bracket our point estimates for milestones with sensitivity limits and run a Monte Carlo, I think our point-based-looks-like-99%-chance-of-success  looks a lot more like 20% chance of success…”. (I use this example deliberately, thinking of  the Carnegie-Mellon Software Engineering Institute (SEI)’s Capability Maturity Model  Index (CMMI) —“level 2” project management entails items (1) and (2) from my example—the kind of quantitative management becomes institutionalized at “level 4.”   Whether or not you are a CMMI fan, it does provide a benchmark indicating how few organizations would find our data-driven critical thinker’s suggestion easy, comfortable, or routine.)

    On Port 25 we’ve had discussion of some hard problems: about the tough choice between MS building product capabilities versus partners and ISVs and about licensing and shared source project requirements.  A big reason Port25 exists is because our point-of-view in the lab is that the best possible answers to these and other questions are unlikely to be easy or comfortable .  (To use some extreme touchpoints, in my view the position that MS could answer these questions optimally by discounting the phenomenon of open source development  and its history is just as almost certainly incorrect  as the position that MS should answer these questions optimally by discounting the phenomenon of commercialized software development and its history in favor of “opening everything.”)    If this is true, a dialogue among  diverse perspectives is essential to continuously push the thinking  of everyone involved away from the personally easy or comfortable—hence, the Port25 dialogue.  There’s a new empirical study that I hope drives this point home and offers you the same motivation to continue to read and post to Port25 that it offers me.

    Kevin Boudreau at MIT’s Sloan School of Management took an empirical approach to the question “Does Opening a Platform Generate More Innovation?”  Cleverly, he looks at handheld computers (PDAs)—an area with multiple software and hardware players—and does a deep analysis of innovation measures in relation to “openness” measures.  (What’s also clever, IMO, is that he includes different types of openness (ranging from licensing to SDK’s and documentation)—and innovation (differentiating between lots of incremental deltas and big breakthroughs)).  What he finds overall is:

    … setting an optimal open strategy may be a far more nuanced problem when trying to promote innovation, in contrast to managing the traditional trade-off between promoting adoption (by opening) versus retaining appropriability (by closing). In this traditional perspective, intermediate levels of openness might have been understood as a means of achieving some middle ground between two relatively simply opposing interests. In the case of opening to promote innovation, an intermediate level of openness might in fact be in the best interest of promoting innovation; there may not be so severe a trade-off with maintaining appropriability. However, the decision to open a little or a lot, and precisely how, will also likely involve trade-offs across multiple dimensions of innovation. (p. 25)

    “Openness” was non-monotonic in relation to innovation, meaning (depending on the particular constructs used in different analyses) the curve peaked and then declined at some point.  And the type of openness appeared to promote different types of innovation—lots of incremental or imitative innovations as opposed to a few breakthroughs:

    Openness therefore should not only affect the rate of technical change, but also its direction. Therefore, these findings offer another explanation of why we observe so few “perfectly” open strategies in practice and why there might plausibly be place for heterogeneity of open strategies, insofar as there is space for heterogenous innovations and  differentiation in a product market.” (p. 26)

    Why is this exciting?  Because it provides compelling empirical data from one technology domain that the question of optimal “openness” is an empirical question, not an ideological one.  And that “openness” in relation to a traditional software business model is not a zero-sum, oppositional game.  That means not only empirical research but also the Port25 dialogue are essential—even determinative.  The bottom line: what we discuss here matters.  If you download the paper, let me know your reaction. - Bryan

  • Port25

    Critical Thinking

    • 0 Comments

    by jcannon on July 13, 2006 01:38pm


    First of all, I will not be held accountable as it relates to typo’s and confusing sentence structures. I got back a day or so ago from Europe, so I am using the Jet Lag excuse as long as I can!

    I am going to start my blog with a little story that happened a few weeks ago. The in-laws were in town and the wife and I decided to take them to a nice restaurant. The restaurant chosen was Salish Lodge, this is a very nice place and it is famous for it’s brunch.

    The restaurant is sitting just off to a very large waterfall (Snoqualmie Falls here in Washington  State, (http://www.snoqualmiefalls.com/), and this waterfall is used to make electricity as well. Now, in this restaurant is a large gauge on the wall, This gauge supposedly shows the water flow per second over the fall.

    I was always under the impression that it was connected directly through some measuring device directly to the falls, and as such would provide real live data.

    Imagine my surprise that while we where waiting for our table I started checking this device out, the gauge was not connected to anything, but instead it is turned by hand to indicate how much water is flowing over at that moment in time.  And you might guess what I could not stop myself from doing next, Yep, turn that puppy up to the highest setting it can go. This, if you believe the
    gauge, is about 40000 cubic feet per second.

    (below is a picture after I turned it up)


    Now, this was like I said a few weeks ago and it was sunny and probably 70 degrees or so. There was no flooding, no weird high water levels. And the river feeding it (Snoqualmie River) was as calm a river as you can imagine. The amount of water going over at that time was not that much more than a trickle. And I very much doubt that in real life the falls ever had that much water go over it. I would assume that that amount of water would take the better part of the restaurant down with it.

    Anyway, so why am I writing this story? Well, it started out as a prank, but turned into an interesting social experiment. While we where waiting, people behind started forming up, I heard comments about the gauge and what it was set at. Without fail, everybody behind me took what the gauge said as fact.

    This shocked me to no end, nobody said, ‘hey, that sounds like way to much. This thing must be broken’. Nobody seemed to think about that the amount of water that the gauge was indicating was so high as to be completely incorrect to the facts. (The water they could see going over the falls)

    Nobody seemed to apply any critical thinking to what they saw.

    And this now comes to what I wanted to write about in this blog, critical thinking. I hear a lot of things in the IT industry that are considered important, or essential for a project/product to be successful. Methodology, standards and testing to name a few. All these are _very_ important, but the one thing that I never hear about is the need for critical thinking. I do not think you can be good at IT if you do not let yourself be guided by a good dose of critical thinking.

    At a previous project, I was asked to help re-design an application that was spidered into many different systems interfaces. One such interface confused me to no end. It did not seem to add any value, and resulted in delays in processing. I tried finding the documentation on the interface but was unable to locate it (sounds familiar?) and I asked the people who used the output of the interface. And they did not know why it was done the way it was done. Nobody ever questioned it, it was always done this way through this interface, so that is what was expected. The interface was removed in the new design by me, and it was an uphill struggle to get it removed. It was always there, so there must have been a reasoning for it, nobody wanted to check or question if it could be done better or was ever even needed.
    The removal resulted in a few less failure points, and noticeable customer improvement in response times.

    I constantly find that using critical thinking skills more than anything makes me more effective at my job. And I am fortunately to be able to work with my two colleagues that seem to possess this same skill, Anandeep and Kishi. And force it on me when I am not using it enough every once and a while

    So, what have you all found to be the best tool in getting the job done?

    And about the gauge? Well, it took a little over an hour and a half before somebody realized the indicator was set to an unrealistic level.

  • Port25

    Infrastructure Management and Strategic Design: Part 3

    • 0 Comments

    by jcannon on July 11, 2006 06:17pm


    Part 3 – Adaptation and simulation of Heterogeneous environments under lab conditions

    A simple question that has always perplexed me is how software and hardware OEM’s across the world simulate heterogeneous environments under lab conditions. I have witnessed several different approaches, practices and stages of this adaptation and each one of them is unique and correct in its right and merit. I guess, that leaves the “big” question which remains unanswered i.e., how do you bring a “real-life” scenario and manifest it under lab conditions. This is even more challenging because the average test lab for a medium to large organization is no match to the size and complexity of its elder sibling, the Enterprise Data Center, running its production systems, applications and operations. So why squeeze all that complexity into a smaller scale ? Is there one perfect method?– of course not, depends on what heterogeneity means to you/your business. Let’s look at this and why it’s necessary and also share some techniques that may be helpful.

    Start with why it’s necessary to represent if not an equivalent amount of heterogeneity within a lab but a comparable one. Start with simple logic – why do we need a lab in the first place ? In most cases it’s an environment we can turn to and run processes, tests and simulations which we dare not try in a Production Environment. However, the caveat here is that if we do want to test a tool or an app that we’re about to roll into a production environment, our best bet is to test it in the lab with conditions mirroring as closely to the production environment as possible. It’s also a place where we can develop workarounds, fixes, documentation, implementation practices and as much supplementary support mechanism as we’d like before we bite the bullet and push the tool or app into production. The expectation we keep in mind when we do that is that results from the lab and production rollout should bear a resemblance like that of the “Partridge Family” and hopefully not of the “Manson Family”. Okay, bad joke but you get the point.

    Now on to “Tips and Tricks” to help with the process of adaptation and simulation of a lab environment that mimics your production one. Here’s what I found useful:

    1. Deployment Methods: Using similar deployments tools, techniques and methods in the lab that are already in use in the production environments makes one aware of “delivery mechanisms” and the path, process the deployment cycle will take when released
    2. Configuration Management: Extreme familiarity and knowledge of the configuration options of not just the delivery mechanism/s but also of the tool/s or app/s is something as valuable as having that Swiss knife in your pocket – you just never know when you’re going to need it
    3. What Business Scale ?: Never hesitate to walk out of the lab and have a conversation with decision makers who chose the tool/app. Find out more about what their expectations out of this application are (by now I know some of you may be cringing in your chairs but I am dead-serious on this one). This is the best way to learn if the application should be tuned towards business scales such as Reliability, TCO, Scalability, Performance, High availability or whatever
    4. Manageability: My personal favorite – always have a lifeboat handy i.e. when the fit hits the shan, will you still be able to recover the system, do a roll-back, connect remotely and most importantly, keep the service/s up and available
    5. Driving Efficiencies: Most IT departments have to squeeze every efficiency they can out of their budgets, and labs are a luxury when they have to deliver results to CTOs. So what’s the best way to accomplish testing, or simulation, on a budget. How does someone with no extra money support such an effort. There’s some creative resource utilization that can be implemented such as:
      • Rotation of production hardware coming up for decommissioning and reallocating such resources to the lab
      • Making use of evaluation copies and licensing i.e. since most lab testing scenarios only extend to short periods to drive testing
      • Using down-time to allocate personnel to testing efforts i.e. if there’s lag time between two projects, using that time and headcount effectively to drive testing


    And finally a small anecdote to help put things in perspective. In my past life, I remember several years ago when I was still on the east coast, I worked on implementing an asset tracking tool for desktops spread through the environment. We tested the tool on individual desktops and did not care about running the entire scenario using network connectivity across the simulation. We were told by the vendor that the tool uses less than 1% of CPU as negligible amount of memory. After random tests, we rolled out the tool and the purpose of the tool was to run a script and send the results back across the network. However, due to ACL’s in place, which we forgot to account for, and lack of validation of packet delivery, the desktops stopped responding. This was an expensive lesson in why we should test the waters to the best possible extent before setting sail.

    Just a few thoughts and hope it triggers some more for everyone out there. As always, please do let me know if that has been useful and/or if you have a specific topic in mind you’d like us to write about.

    -Kishi

  • Port25

    Memtest

    • 0 Comments

    by jcannon on July 11, 2006 04:32pm


    *Updated* So, this weeks tech tip is about memtest, and yes, I am sure there are some that might scoff at this....But I think we have a tendency to loose sight of the basics. For instance, last week we had quite an interesting time debugging a problem that occurred intermittently and we where not able to find a way to consistently reproduce the problem. We ran through all kinds of things until we decided for grins and giggles to run memtest. And low and behold, it found memory errors. We replaced the memory and have not seen a recurrence of the problem.

    We decided to pull this old but trusty tool back out of the stable. Special thanks goes to Kyle Adams and Stephen Zarkos who did a lot of the footwork on this one.

    Memtest is a simple program that is designed for the x86 architecture.  You would use it for things such as when hardware hangs or when your computer doesn’t boot at all.  Either way, you could just grab memtest and throw it onto your computer. 

    Actually, there is not a hard and fast rule when to use it. There are two ways I would put it in the toolbox to use, and they have to do with methodology more than anything.

    1. I have no clue what is wrong and I am completely out of ideas, I am just stabbing in the dark.
    2. As a standard suite of checks and tests I do to debug a problem I will run memtest.


    Honestly, I think number one is one that happens more in real life. A lot of people do not think that HW like memory will be causing any problems. They forget that often with memory it is not a black or white issue. It is not an all or nothing failure. It sometimes happens and sometimes it does not. I have never really seen a failure that I would say without question, that is memory!
    You can get it here (Linux GPL, and windows version);   http://www.memtest86.com/

    (There is also a non GPL, but still free version for windows available here http://hcidesign.com/ I am not to familiar with how it works, but the web page gives you a lot on information)
    One thing to note, this can run for a very long time, several hours in some cases.

    GENERAL FEATURES
    Memtest gives a user the ability to access the memory in an effort to pinpoint a problem in the memory itself.  It uses a set of algorithms to check for consistency and errors in the placing of memory.  The algorithms that are used by memtest to test the memory are the following:

    1. Address test, walking ones, no cache
           a. Fills in the address space with ones in a sequential order
    2. Address test, own address
           a. Puts the address of the test address in itself
           b. Test for addressing errors
    3. Moving inversions, ones and zeros
           a. Checks the addresses using a series of ones and zeros
    4. Moving Inversions, 8 bit pattern
           a. Uses an 8 bit wide pattern to test for errors on “wide” memory
    5. Moving inversions, random pattern
           a. Creates a set of random numbers and its compliment, writes to address.
    6. Block Move, 64 moves
           a. Memory is initialized with 8 byte inverting patterns.
           b. Moved every 4 MB
    7. Moving inversion, 32 bit patterns
           a. Shifts data patterns one bit for each successive address
    8. Random number sequence
           a. Writes a set of random numbers into memory
           b. Checks the memory for consistency on the next pass
    9. Modulo 20, ones and zeros
           a. Uses the Modulo-X algorithm to check for errors not detected by inversions because of buffering
    10. Bit fade test, 90 minute, 2 patterns
           a. Initializes memory and then sleeps for 90 minutes
           b. Checks memory after the 90 minutes is up

    The point: applications still need error-free memory to execute correctly, especially today with application complexity increasing all the time. How do you replicate problems in your lab environment with such diverse environments across your network, or even more importantly,  separate hardware from software failure?As always, comments/suggestions etc appreciated.
    Hank Janssen

  • Port25

    How I Learned to Stop Worrying and Love Licenses

    • 0 Comments

    by jcannon on July 10, 2006 01:30pm

    When I first started writing software, my only understanding of the term ‘license’ was that it was something I needed to drive a car or to catch fish.  As my career progressed, I learned that software also has licenses that describe – ideally - how the author of the software wants his or her creation to be used (terms, conditions, permissions, etc.).  Of course, there are many types of software licenses today.  You may not follow this topic that closely, but you certainly have seen things such as End User License Agreements – that little agreement you can choose to click ‘I Accept’ or ‘I Do Not Accept’ after you read in infinite detail all the terms, conditions and restrictions (right?).  Early in my career, I typically just used a) whatever license the company I worked for used or b) whatever licenses other developers seemed to use.  It was a combination of laziness, naïveté, and general indifference to all things legal.  This perspective of course changed as I began to understand that licenses were indeed quite important and powerful in determining how I could control the thing that I wrote – or how I could lose control.

    Thus began my entrée into the legal world of software licensing.  I’m generally not one for bureaucracy or unnecessary complexity, so, to be frank, some software licenses seemed ridiculous to me.  Many still do.  But again, I’m not a lawyer (nor do I play one on TV) and I do have a high degree of respect for all my friends in this discipline, so I understand it’s not always as simple as one may desire it to be.  That said, it doesn’t hurt to try to strive for simplicity.   Programmers and IT professionals learn early on that the K.I.S.S. rule is the only true path to technical enlightenment, so I try to apply this same thinking to software licenses. 

    Licensing is a broad field, so I’m going to focus in on what we’re doing with our community software licenses.  It’s worth noting that there is an important difference between binary and source licensing. The fact of the matter is binary licensing governs the vast majority of revenue-generating activities in commercial software. Source code licensing is about the use (and re-use) of the underlying intellectual property in terms of copyright, trademark, and patent.  I’m focusing on what source licensing programs we are doing for our community projects.

    Around a year ago, we rewrote our software licenses that we will use for many of our community programs in our Shared Source Initiative.  If you’re not familiar with Shared Source, this is a program we have where we share source code with customers, partners, developers, academics, and governments worldwide.  There is a variety of software we have in this program, such as wikis, Atlas/Ajax toolkits, IronPython (Python in .NET), drivers, installers, and so on.  Jason Matusow announced these new community licenses on his blog last October.

    There were four main goals for writing these new licenses:

    • Short and easy to understand - The new licenses are typically shorter than a typewritten page and are easy to read and understand.
    • Effective and modern - Although simple, the licenses are designed to be effective and to reflect modern best practices in source code licensing.
    • Efficient - By using three simplified licenses, Microsoft will be able to streamline its own internal source code release process, which will allow for more rapid Microsoft source code releases.
    • Ecosystem-friendly - Using three simple and well-understood licenses help to simplify source code sharing throughout Microsoft’s various software ecosystems, and help to avoid excessive license proliferation.

    (To be clear, I was just a cheerleader and supporter of these efforts, smarter people than me did the actual work to meet these goals in each license .)

    The result was something we were quite happy with.  But it’s not just for Microsoft’s Shared Source projects – SugarCRM, the leading Open Source CRM solution, has chosen to use one of these new licenses, the Microsoft Community license.  As John Roberts, CEO and founder of SugarCRM commented:

    "We were really impressed by the Microsoft Shared Source Community License and like it a lot. We think it is a license that represents the ideals of our community and is one that they want to use, especially those customers who already run on the Windows platform.”

    You can read more about this news here.

    I’ll be blogging a lot more about Shared Source in the future.  As this blog entry’s title suggests, I’m a Kubrick fan and although I’m not worried about fluoridation conspiracy theories, I did want to share a snapshot into how we think about community source licensing.  Regardless if you write code, manage an IT environment, or just install applications on your desktop or server, understanding software licensing is an important aspect of the software world we live in.  It is my hope that the future of software licensing gets simpler, more pragmatic, and more empowering for the world’s software authors.

    And since I’m so lazy in writing my blogs, I now have to add in a bunch of post scripts…

    P.S.: In the same theme, we have also recently announced some interesting work with Office, giving authors the option to create Creative Commons licensed work using a plug-in within Office.  Creative Commons is a nonprofit organization that has written licenses that allow content creators to share information while retaining some rights.   Creative Commons was founded by Larry Lessig, a Stanford Law Professor I've come to respect and read often – Larry blogs about this news here.  We’ve worked with Creative Commons in the past, on a spec for RSS extensions and the PatternShare wiki site (using the Creative Commons Attribution-ShareAlike license and the Creative Commons Attribution license, respectively).

    Stephen McGibbon's has a great blog about the Creative Commons Office plug-in here, with screenshots and commentary.

    Speaking of Office, you may have caught the recent news about the new community project building an Open Document Format (ODF) converter for Word 2007 (up on SourceForge: http://sourceforge.net/projects/odf-converter).  If you are a spectator in the Open XML vs. ODF debates (a very en vogue topic for Open Source pundits), I suggest reading Chris Capossela’s letter about the differences between Open XML and ODF.  Chris is one of the key leaders of our Office organization and this letter helps clarify a lot of the FUD spread by Microsoft competitors around Open XML and ODF.

    P.S.S: On licensing, CIO Magazine Technology Editor Christopher Lindquist just wrote an article on OSS licensing that is worth reading.


  • Port25

    Server & Domain Isolation with Fernando Cima, Microsoft Brazil (Podcast)

    • 0 Comments

    by jcannon on July 07, 2006 07:43pm

     

    Our first podcast...

    This week, Sam talks with Fernando Cima from Microsoft Brazil's Security Center of Excellence about the challenges and progress being made in securing and maintaining today's mixed network environments. More specifically, the focus in this discussion is on Server and Domain Isolution. Before Microsoft, Fernando worked for the Brazilian government, as well as with Linux and FreeBSD security projects.

    - Download the MP3 Directly
    - Learn more about Server and Domain Isolation.


    Podcast Related Links:
    - Subscribe to the Port 25 Podcast Feed
    - Subscribe to Port 25 Podcasts in iTunes

     

     

  • Port25

    Port 25 Housekeeping: Podcasts, Threaded Comments & More

    • 0 Comments

    by jcannon on July 07, 2006 02:41pm


    It’s only been three months to the day since Port 25 launched. Exactly 73 interviews, posts and tips later we are only just getting started on delivering on our promise of technical and interoperability insight from the lab.  The HPC clustering analysis project is well under way and I expect to have an overview post for that project in the next week.  I’d like to see much more technical content on the site, but it is taking time to get our lab projects ready for public consumption.

    For now, I'm excited to announce some site enhancements to how Port 25 allows you to interact, discuss & debate ideas, as well as - yes - consuming content via podcasting.

      • Podcasting - we're going to start publishing podcasts on a semi-regular basis. We've heard feedback from a number of people that are interested in taking these interviews with them, or downloading the audio component...this is a step in that direction. This also lets us reach outside the limits of a video camera & talk to people all over the world & bring you those conversations. Today, we start with Fernando Cima from Brazil, a previous Linux and FreeBSD developer, and now on Microsoft's Security Center of Excellence Team. You can continue to get notices of podcasts on the main RSS feed, and we also have a podcast-only feed for those with dedicated clients. For those using iTunes, you can also subscribe to our podcast here.
      • Threaded Comments (Coming Monday) - our feedback system is a key part of Port 25. It's where we learn what we're doing right, what we're doing wrong and what you guys really care about. Some of you e-mail us directly, but most use the comments feature in the blogs. When we launched, we had a plain, flat structure with limited facilitation of discussion. By Monday morning, we're rolling out threaded comments. Threaded comments enable you to respond to each other, and to view the talkback in a conversational view. You've seen this kind of view before.  Existing comments will remain, and there will still be very limited moderation. Registration will still be required.


    I’m interested in your feedback on how much you value the comments features – I’ve heard limited feedback in the last month but it varies from keeping things the same, removing the need for registration, to eliminating comments entirely.  What do you think?

    We're looking forward to continuing to grow our community with a set of content & usability enhancements over the coming months. For now, I hope these small changes are a good surprise. Have a great weekend.

    Cheers,
    Sam

  • Port25

    Interoperability: Open Source ODF/Open XML Translator and Microsoft Office

    • 0 Comments

    by jcannon on July 06, 2006 05:42pm


    Linux Format reported on Port 25 recently with the tagline “Reports of snowballs seen in hell as Microsoft offers to work with Linux developers,” which I thought was funny.  It’s apparently getting even colder down there as we’ve now announced an open source project that adds support for ODF to Microsoft Word 2007 ("Microsoft Expands Document Interoperability").

    A few months ago I started working with Jean Paoli, whose leadership on Interoperability at Microsoft is steadily moving product teams toward the goal of consistently delivering high-quality interop.  Brian Jones notes this in his blog but doesn’t call out Jean by name.  You can be sure that you’ll see more of Jean’s handiwork in the coming months and years.

    During the time I’ve worked with him I’ve been greatly encouraged by his commitment to openness in documentation and in implementation.  The Open XML Translator project is a great example of this – it’s an open source project hosted on Sourceforge.

    I couldn’t help but hop over to Slashdot and check out the reactions to the news – and as usual there was a mixture of the rational and irrational, hope and fear, insight and suspicion of conspiracy.  It’s worth making one point over and over.

    The Open XML Translator is an Open Source project.
    The Open XML Translator is an Open Source project.
    The Open XML Translator is an Open Source project.

    By definition it can’t conceal its implementation, is open to experimentation, modification, and commercialization (it uses a BSD license), and is owned by the community.

    If you think it needs improvement, then improve it.  If you think it doesn’t matter, ignore it.  But above all, really think about it and what it means that we’ve taken this step before reacting reflexively.

    This is actually something new and different.

  • Port25

    UNIX Interop in Vista Beta 2 and Longhorn Server

    • 0 Comments

    by jcannon on July 06, 2006 03:06pm


    Another guest blog this week from Identity Management Program Manager, Shamit Patel:
    ---------------------------------------------

    Hi,
    Last week, we released two new utilities to help customers achieve UNIX / Windows Interop. The first is a set of utilities and the SDK for the Subsystem for UNIX Architecture (SUA) in Vista Beta 2 & Longhorn. For those unaware, SUA is a native subsystem residing on top of the Windows kernel, just like the Win32 subsystem. It provides the basic infrastructure to run UNIX-based applications and scripts on Windows Vista (Ultimate and Enterprise) and Longhorn Server.

    We've also released the UNIX-side components for Identity Management with UNIX. This essentially provides the utilities which enable password sync between Windows and UNIX environments. These are the UNIX-based utilities to enable successful synchronization.

    I realize many of you may not be testing Vista or Longhorn, but for those who are, or have corporate testing, we would love to hear your feedback on the product, scripts and documentation.


    Thanks all,
    Shamit

  • Port25

    Open Source Management – Commercial or Libre

    • 0 Comments

    by jcannon on July 05, 2006 03:17pm


    Free open source management projects have existed for years, as illustrated by nagios and webmin, and exist as BYOC (bring your own console) free alternatives to commercial management systems from HP, BMC, CA, IBM and Microsoft.  In the last few years, we've seen a rise in commercial software companies moving to support Linux and heterogeneous environments - including but not limited to Centrify, Vintela (Quest) and Centeris, three vendors with whom we've worked in the lab.

    It makes good economic sense to make money managing a free product - after all, Microeconomics 101 will tell you that commoditizing your complements maximizes revenue.  Sell a database?  Then make the operating system and application server free.  IBM's move into open source can be seen in this perspective (free operating systems on for-profit hardware and services) as can HP's (with management software revenues thrown into the mix).  The same logic should apply to management, especially given the relative lack of enterprise-class open source management software.  While nagios is impressive, the fact that it has been used to manage 5,000 node systems alone does not make it enterprise-class.

    Recently the Open Management Consortium was founded to unite free/libre open source management projects around a common vision for what management systems should be capable of, and under a common philosophy of open source software.  Founders include Qlusters, EmuSoftware, Zenoss, and Ayamon.  They also have a list of OSS management projects.  Notably, they don't mention OpenSSI as a cluster management technology.

    Open Source can be taken to apply to management in several ways:

      • Console
      • Monitor
      • Agents
      • Adapters


    Each of these layers is open to displacement by open source software, some more easily than others.  Agents and adapters seem to me to be the best fit for the typical open source development model - where it's easier to serve the long tail of different endpoints than under standard commercial rules.  Consoles and monitors, while at the most basic levels of logging, parsing, alerting, and displaying are well-understood, are areas of deep research and increasingly rarified technology.  The developments in the area of event aggregation and scalable management UIs require significant directed investment (and Matt Asay has disagreed with me on this before) in which commercial software companies have an advantage.

    A few Port 25 readers have contacted me about building open source integrations between Microsoft products and OSS management technology - as well as OSS projects and Microsoft management technology.  For both of these categories, it makes good sense to me and I'd like to see them developed at www.codeplex.com, where we've built an infrastructure for the community to build open source projects.

    In the management arena, where we spend significant time in the lab testing different approaches, I'd be happy to spend money and time helping to test or develop projects on Codeplex.  Drop me a note if you have something cooking and would like some help or direction.

    Cheers,
    Sam

  • Port25

    Kudos to Open Source Developers

    • 0 Comments

    by jcannon on July 03, 2006 02:30pm

    I see my last couple posts were about ambiguity, so I thought today I’d blog about something, IMO, that is not ambiguous at all—and the topic would be a fitting hat tip to Sara and Korby and all the folks involved with CodePlex

    Brief background: We had to buy our own combination padlocks on our lockers in my high school.  I used to forget the combination all the time (—I still have nightmares about that).  I finally solved this by writing my combination in hex on the back of the lock. (I figured there was only one other kid in my class who  would know what 0F was in base-10, so if anything was ever missing, I’d know where to look. ) 

    I tell this little anecdote because it made me think about the lack of a community of folks with similar interests in my little world back then.   The only reason I knew hex* went back years earlier to a similar lack of community: I couldn’t get a game I was writing on my Commodore 64 to do some things fast enough in BASIC,  so I asked my Dad what else I could do and he explained what Assembly language was, and from then on there were lots of nights when I was supposed to be asleep, sitting there in my pajamas, banging away in 6502 Assembly land—by myself.

    This was long before the concept of a home modem would have ever occurred to us, never mind the modern Internet’s enablement of community and collaborative development--but I can’t help but wonder what a difference it might have made to me (never mind the quality of that game!) if there had been a more readily accessible community of folks interesting in collaborating and mentoring at that time.

    What does this have to do with praising open source developers? This week, inspired by CodePlex, I was looking back at two of the most important studies of the motivations of open source developers.  In the two studies (Ghosh in 2002 and Lakhani (PDF) in 2004—both are available online), although slightly different sets of questions were asked, by a notable margin the leading  responses were “Learn and develop new skills” and “Share knowledge and skills” (Ghosh) and “Code for project is intellectually stimulating to write” and ‘Improve programming skills” (Lakhani).   What’s even more striking about this is comparing these types of motivations—about learning and sharing—with more “confrontational” motivations.  Developers could choose multiple answers in both studies, and, for example, in the Lakhani study four times as many volunteer developers  chose “Improve programming skills” as a reason for joining an open source community than “Dislike proprietary software and want to defeat them.” 

    To be clear, anybody’s reason is valid to them--but I am a person who would rather learn than win.  That’s true when I write code, it’s true when I play soccer; I think that is a good way to view the world—and from all the research I’ve seen, the evidence is compelling that folks who voluntarily participate in open source development communities place very high value on learning and sharing their knowledge with others.  I don’t have comparable data at hand, but I’m willing to believe it is well higher than the average person in the population at large.  And for that—kudos.  I think that means there are far more opportunities for kids like I once was not just because of technological advances, but because of people—maybe people like you reading this post.

    *I actually can’t remember if I stumbled across hex first in Traveller, where, as I recall the descriptive strings for character attributes and planets where in hex—come on, don’t snicker, you know you played it too…

  • Port25

    Security and Directory Services for UNIX Guide Released

    • 0 Comments

    by admin on June 30, 2006 04:23pm


    We've got a quick guest blog before the holiday weekend on a new set of interoperability tools released this week by Microsoft, and in conjunction with some very talented folks in our partner, sales & services group. Welcome Luis Camara Manoel, Program Manager for in Communications & Collaboration...take it away Luis:

    ------------------

    (Luis Camara Manoel)

    Hi all,
    The Interoperability and Migration Solutions team at Microsoft is very happy to have just released the Windows Security and Directory Services for UNIX Guide. This guide details step-by-step instructions for providing security and directory services for mixed Windows and UNIX environments using Active Directory. The approach we followed here describes multiple options to achieve two different system end-states:

    1.    UNIX clients are enabled to use Windows Active Directory Kerberos for authentication while continuing to use a UNIX-based store for authorization.

    2.    UNIX clients are enabled to use Windows Active Directory Kerberos for authentication and use Active Directory LDAP for authorization.

    We have also added some tools and templates to help plan, develop, deploy, and operate these solutions.

    Although this release addresses AD integration only for Solaris 9 and for RedHat 9, it is pretty simple to see how it would apply to other UNIX and UNIX-like systems.

    You can download the guide here and please let me know what you think. I am very interested in finding out how the guidance is received.

    Have a great holiday weekend,
    -Luis

  • Port25

    Testing software on multiple platforms - do we trust the tools or rely on methodology?

    • 0 Comments

    by admin on June 28, 2006 06:13pm


    Consider this scenario – the CIO’s office just called. They have decided to follow your recommendation and are going to use JBoss (substitute favorite open source software package here) as their application server (substitute database server/web server/whatever server here). They also decided to make it standard on both your Windows servers and your Linux/NetBSD (substitute favorite flavor of open source operating system here). Now, they ask you – will it handle the loads on both operating systems? They don’t want any of the servers to be idle after all that investment they made.

    You have a reputation as a “data driven” dude, i.e. you look for empirical evidence in making decisions like this. No hand wavy – “it will work …. maybe” for you. You know your workloads cold. You know you will run test scripts to simulate those workloads.

    The million dollar questions are (drum roll please):

    1. Will you use a standard tool or testing package (such as Grinder with JBoss) that works on BOTH Windows and Linux ?
    2. Will you trust your test scripting skills and your methodologies and write your own scripts – using whatever tools make sense on Windows and Linux?


    Why are these questions important?  The objective is to have consistent and comparable tests on each platform – and it is important to make sure that the testing process does not introduce any bias one way or the other.

    So which approach  - trusting the tools or trusting your methodology allows for consistent and comparable tests on each platform?

    Lets examine some pros and cons of each approach:

     

     

    Damn! The laws of physics strike again. Looks like there is no easy answer since the observer effect will always be present i.e. observing the software using testing software impacts the software being observed so that a precise observation can’t be guaranteed.

    So what do you do in such a case?

    My friend (and I think he works with me too) Hank Janssen had the following to say (I will not point you again to his handsome visage like I did in my last blog or people will start talking!)

      • If the same tools are available on both platforms, then use the same tools.
      • Stay with industry standard, and or OSS accepted methods of testing.
      • Have a list of ‘acceptable’ tools to pick from
      • Publish a list of methodologies/guidelines you are using (so that people can make their own judgments)

    I am not so married to the tool as I am married to a consistent and approved process.  There will be many different tools for different languages/applications/infra structures/protocols and the like.

    I wanted to stay away from testing methodologies that are so different between different platforms that I would have a hard time interpreting the results. For example, using Loadrunner or Winrunner on Windows and than Grinder on Linux. (In case of Java loads) This example would result in apples to not so apples comparison. Most OSS tools (jMeter and Grinder) are available on both platforms.

    Advice from the testers in Microsoft

    I spoke to a few people who do testing for a living within Microsoft and here is some advice they had to offer

    1. Do think about configuration parity of hardware. For instance you may need more RAM for Windows to run the application and a higher capacity network card for Linux. Consider if your goal is to actually establish the configuration parity or is it to find which OS scales under a given configuration?
    2. If you do end up trusting the tool – define a sample case. This is a test case for which you roughly know the performance parameters on each platform. Run it under the testing tool for both platforms to make sure there are no significant differences in performance due to the tool itself. Of course defining a sample case may not be a trivial task – but use one that tests the most critical parameter for your application – memory, CPU or I/O for instance.
    3. Consider running the software being tested on its own server  – without running any additional testing software on the servers. Provision a remote server with the testing tool (choose one), and install agents for that tool on each server with the software being tested. Measure network latency and I/O latency and run the tests simultaneously from the remote machine to each server. This works if the software being tested requires only simple parametric commands to run or is entirely run from a UI. Doesn’t work very well if complex scripting is required to run on each server.
    4. Do understand the effects of running tests through the entire system. There is at least one war story that I can vouch for, it entailed testing of a web retailers production systems under peak load conditions, using test scripts on client systems. Unfortunately the test team forgot to turn off the connection from the web systems to the warehouses that carried the inventory because someone missed that in the end to end testing plan!  Some poor soul written into a test case got umpteen gizmos from the retailer. The system worked as advertised, which was not the intent of the test team (at least for the test)!


    But enough about us, what approach do YOU take, dear readers? Please do let us know - we are looking for war stories, dispatches from the data centers, tales from the trenches and any other feedback on testing disparate platforms that you have to share!

  • Port25

    SMTPRC

    • 0 Comments

    by admin on June 28, 2006 01:30pm


    Spam is a well-known problem for many on the Internet. If you have an email account anywhere, chances are you’ve gotten something you didn’t ask for; a “stock tip”, an adult entertainment solicitation, or possibly a plea from an altruistic member of the “[Random Nation] Royal Family” to assist in some friendly money-laundering.

    As the anti-spam movement gets craftier, so do the spammers. Fortunately for the spammers and unfortunately for the internet, there are a wealth of open-relay mail servers should have never been put online. While most common and current-version SMTP software is secure by default, there are plenty of people who still run outdated software, never bothered to upgrade, or configure properly in its present state.

    If you are tasked with administering and monitoring a large portion of IP space assigned to people with autonomous control of machines on an externally visible network, this problem can get to be a thorn in your side very quickly - just ask any ISP that allows their customers to run servers.

    If you’re not allotted much (or anything) of a software budget to purchase fancy enterprise tools to hunt down open relays on your network, there are some free and lightweight tools for Linux. One such utility is a small application written in C, called “smtprc” (smtp relay check): http://freshmeat.net/projects/smtprc . This simple application takes about 10 minutes to set up.  First unzip it into your directory of choice. Next read the README file, and specifically check the Compilation/Installation section to make sure it ends up where you want it to. If not, edit the Makefile and put it where you want it to go. Do a “make” and “make install”, edit your scan configurations and go. It will output results to an html file (location specified in configuration). They will be color-coded by result. The collected data may then be used to notify administrators of vulnerable machines.

    Note: Some older versions of NT Mail and Lotus Notes will turn out false positives. The messages smtprc attempts to relay are what I would call “passively rejected”. The SMTP server being tested will accept the inbound messages, but they are never actually delivered. When in doubt, it is best to test manually.

    $ telnet mailserver.com  25   ß telnet to the host in question on port 25

    Trying 10.197.173.28...

    Connected to mailserver.com.

    Escape character is '^]'.

    220 mailserver.com ESMTP Sendmail 8.13.1/8.13.1; Wed, 14 Jun 2006 15:17:39 -0700

    helo bleh                                  ß most mta’s now require a “helo/ehlo”

    250 mailserver.com Hello [157.55.209.144], pleased to meet you

    mail from:<me@here.com> ß sender address

    250 2.1.0 <me@here.com>... Sender ok

    rcpt to:someone@wherever.com  ß intended recipient address.

    250 2.1.5 <someone@wherever.com>... Recipient ok

    data                    ß indicates message is now being written

    354 Enter mail, end with "." on a line by itself

    Subject: open relay?   ß can be anything

    Hrrrm……                  ß message.

    .        ß dot on a line by itself indicates end of message, server will queue for delivery

    250 2.0.0 k5EMHdHl028091 Message accepted for delivery

    quit

    221 2.0.0 mailserver.com closing connection

    Connection closed by foreign host.

     

    Check your mailbox in about 15-30 minutes. If it doesn’t arrive, chances are this is not an open relay.

Page 34 of 38 (563 items) «3233343536»