Last week, the U.S. Federal District Court of Northern California found a software developer liable for unattributed use of a Java Model Railroad Interface.   The lack of attribution, as required in the license, the Court found, violated the Digital Millennium Copyright Act.  While the Court’s finding has limited legal jurisdiction, it does set a precedent which will surely be cited in future cases looking for both damages and to set further legal precedent and define more fully the cases in which stare decisis will apply.

While, analogously, no different than any other license violation, I predict that this finding will have a ripple effect in government adoption of open source projects in their applications, further dampening the adoption rates.

• Many government agencies are skeptical of open source in the first place.  Open source projects, rightly or wrongly, have a blanket aura of the two high school kids in a garage image.  Most government agencies like controls and process, which they don’t perceive exist in open source projects.  If some of them tried to become committers on major projects, perhaps the perception would change.
• Very few open source projects have sales representatives.  The sales representatives at major software companies such as Microsoft do an excellent job of the appropriate education and shepherding to provide assurances to the government buyers.
• Walking through a purchase process gives the perception of license compliance.  A contracting officer can say that they have made a purchase and have a license and feel like they are in compliance, although audits oftentimes reveal shortcomings.  With an open source project, anyone can download source code and deploy the software onto a system, creating manifold increases in risk of license violations.
• Most legal counsel isn’t familiar with open source licensing requirements and restrictions.  Rather than digging into and understanding GPL or “copy-left” restrictions, it’s easier to just stay away from it.  Again, there are probably as many, if not more, EULAs than accredited and accepted open source licenses, but there are also sales representatives to walk through EULAs whereas the open source projects do not have such champions.
• It’s easier to create blanket restrictions than to make judgments on each case based on the specific merits of the case.  The finding in Jacobsen v. Katzer makes it easier to point to a known and potentially quantifiable risk to deny use.  The Government is, and in most cases rightly so, risk-averse, and this finding creates a potentially big risk.  The risk may be a black swan, but it is very hard to measure and, in a perfect (in the Government’s view probably an imperfect) storm, could be potentially exceptionally large.

While it won’t have an immediate effect, the end result, I expect, will be an even more rigorous set of processes to complete for approval of the use of most open source software within the government.  I hope this is not the case, because there are many cases where open source software is the best solution.  Furthermore, I truly believe that:

• By and large, open source developers are not a litigious group.  They want to write software which makes life easier, and as long as they get the credit and attribution they want, they’re happy to share.  It’s what’s written in the licenses.  Plus, legal paths are expensive, and very few can afford to go down that path.  Compliance with a very few legal requirements or selection of a different platform will avoid any potential legal pratfalls.

Thanks to Onlyopensource for pointing out this article!

Yesterday, the House of Representatives introduced S.2989, the Small Business Revitalization Act, which punishes government prime contractors for failing to pay their subcontractors after the government has paid them for work performed.

While noble in trying to ensure that small businesses get compensated for work performed, the bill seems to miss the mark on the bigger issue with small business subcontracting.  I admit, I cannot find the text of the bill (and would love it if someone could point it out to me), so I could be wrong, but based on the article linked above, it appears that a couple of key issues are not addressed:

• Prime contractors actually meeting their subcontracting requirements.  In most large contracts, prime contractors are required to have a subcontracting plan and meet certain thresholds of work sharing amongst disadvantaged groups.  Very few enforcement mechanisms exist to ensure these thresholds are met, and this act does not address the issue.
• Prime contractors actually using the teams that they proposed in RFP responses.  If a prime wins a contract by describing teaming arrangements with certain companies, then it should actually utilize them as proposed to the government originally, or replace like-for-like on the team.  Again, no enforcement mechanism exists unless a contracting officer writes a constraining and binding contract.

As I have written before, set-asides and subcontracting goals go against my libertarian nature, as I want the most value for my money as a taxpayer; however, if they are going to exist, then the least the government can do is make sure that the rules are enforced.  Unfortunately, the Small Business Revitalization Act, it appears, fails to help meet those goals.

In a memorandum dated October 16, 2009, the CIO of the Department of Defense published guidance on the use of open source software within the DoD.  The CIO’s assessment of the perception of open source sums up quite well the obstacles we have seen time and time again:

“Unfortunately, there have been misconceptions and misinterpretations of the existing laws, policies and regulations that deal with software and apply to OSS, that have hampered effective DoD use and development of OSS.”

I wonder how long it will take for contracting officers to get the memorandum (so to speak) and to try to find ways around the guidance, spelled out in Attachment 2:

“In almost all cases, OSS meets the definition of commercial computer software and shall be given appropriate statutory preference in accordance with 10 USC 2377 (reference (b)) (see also FAR 2.101(b), 12.000, 12.101 (reference (c)); and DFARS 212.212, and 252.227-7014(a)(1) (reference (d))).”

We also eagerly await broader acceptance within the DoD information assurance community, but do not expect rapid change, despite the following guidance:

“DoD Instruction 8500.2, Information Assurance (IA) Implementation, (reference (g)) includes an Information Assurance Control, DCPD-1 Public Domain Software Controls, which limits the use of binary or machine-executable public domain software or other software products with limited or no warranty, on the grounds that these items are difficult or impossible to review, repair, or extend, given that the Government does not have access to the original source code and there is no owner who could make such repairs on behalf of the government. This control should not be interpreted as forbidding the use of OSS, as the source code is available for review, repair and extension by the government and its contractors.”

In sum, this is good news for those of us who believe that open source has a place in the Department of Defense.  However, word spreads slowly in the Government, and I expect that this policy will take many months, if not years, before gaining significant traction in DoD contracting policy.  A good place to start would be providing correct links in the policy memo.  Clicking on the link currently leads to a 404 error.

Edit: This is the correct link: Clarifying Guidance Regarding Open Source Software (OSS)

Thanks to the Powdermonkey blog and Dr. Mark Drapeau for sharing this!

Today, the United States Marine Corps announced that it was banning its Marines from using social networking on the job.  Citing security risks, the Marine Corps has said that it will block and ban social network sites while Marines are on the job, but doesn’t stop them from doing so when they’re not at work.

To me, this seems to be a case of letting a small bad outweigh a large good.  While I understand the desire not to expose Marine networks to hackers and not to expose secrets to the world at large, these are problems that the Marines and the military face on a daily basis.  Simply banning the use of social networks while at work will only move the problem to a less scrutinized venue.

Here are 5 reasons that the Marines shouldn’t ban social networking:

1. The security risks aren’t going away.  People are going to use their social networks at home if they’re not being used at work, so the same secrets will get out regardless.  These transgressions will range from a slip of the tongue to intentional OPSEC violations but if these occur on government computers, then there’s a better chance that they’ll be caught sooner than if they occur at home.
2. It sends the wrong message to today’s Marines.  The bottom line interpretation of this message, to the average Marine is “we don’t trust you.”  While today’s Marines and soldiers are being asked to do more at lower ranks than they were in the past–a large amount of responsibility being placed in the hands of teenagers and twenty-somethings–this message implicitly says that for all of the responsibility, there is still no trust.
3. It sends the wrong message to potential recruits.  Recruiters want to go where the recruits are, and most of them are on social networks.  Not allowing social networking sends the message that the Marine Corps is backwards and antiquated and doesn’t care about what it’s like to be a youth in society.
4. It keeps the Marines from knowing what’s being said about them.  Social media is turning into a major media outlet, and it’s often one that has a different take on events than mainstream media.  By banning the use of social networks, the Marine Corps has hamstrung their own public affairs office from both telling a good story about the Marines and knowing what is being said in the arena of public opinion about them.
5. It stifles a culture of innovation.  Terrorists continue to innovate, and as is pointed out in the NDIA’s own magazine, “to defeat terrorists, the military must innovate and disrupt [them].”  By banning the use of an innovative means of collaboration and interaction, the Marines suppresses the culture that leads to the innovations needed to win post unilateral hegemonic conflicts.

I predict that in the end, the Marines, the Pentagon, and the government will come to some sort of compromise that allows limited usage.  Giving up rights is part and parcel for live in the military; hopefully the sacrifice doesn’t come at the cost of leaving a generation of future cyberwarriors behind.

This past weekend was my first as a graduate student at the University of Virginia’s McIntire School of Commerce, where I am working on a Masters degree in Management of Information Technology.  It was a great 3 days of intensive classes on IT strategy, and I really enjoyed it.  Over the next year as I continue my studies, I will try to blog regularly about topics we are learning about.

As part of the program, the faculty regularly bring in interesting guest speakers with CIO experience.  This Saturday was a great example, since Jill Singer joined us.  Ms. Singer was formerly the Vice President for Project Management at SAIC, and is now the deputy CIO of the CIA.  She gave a great presentation on the role of the CIO, and the process they use at the CIA for evaluating, architecting and implementing their internal IT projects.

The CIA, despite the mystique and the fact that Ms Singer was not free to answer all the questions we asked, is still a lot like any other IT shop.  The process they follow for IT initiatives could easily be found in any Fortune 500 company.  In short, they follow these steps: understand the mission, establish the vision, develop the architecture, define plans, resource plans, execute plans, and measure progress.

Sounds pretty traditional, right?  Many other federal agencies probably follow a similar approach, which sounds a lot like a spiral development method.  But even within the constraints of this process, I was very pleased to hear Ms. Singer talk about regularly using Agile methodologies.

According to Ms. Singer, the CIA regularly uses Scrum, most often in 4 week development cycles.  Their customers, which would generally be some sort of internal analyst, really like the fact that Scrum encourages regular and tangible deliveries.  This allows them to try out the prototypes, and their customers also enjoy being able to add features and change priorities during each iteration.

This has worked very well for them on many projects, and Ms. Singer feels that the move from a more waterfall style to Scrum has really helped them improve many of their projects, though with an interesting side effect.

The biggest challenge she has seen on their is knowing when they are done, or as she put it, “defining what 1.0 is.”  They can’t fund their projects forever, just like any other IT shop.  Sometimes they end up doing iterations indefinitely though, and then realize they have gone longer than they originally thought because they keep adding features.  But unlike most project methodologies, if they slip on a project schedule using Scrum, Ms. Singer has found their customers are much more forgiving then when a waterfall project is late.

The reason for this is simple, and it is one of the fundamental advantages of Scrum and Agile, regardless of whether you are a start up company, a government agency, or even the CIA.  By engaging your business owners with burndowns, daily stand ups, and short iterations for which the customer helps set the priorities, you are empowering your customer.  It’s important to note that this is done in a way that does not infringe on the creativity of your development team.  Your developers are likewise empowered by choosing what they work on and in what order within a sprint, setting their own estimates, and providing regular feedback and ideas directly to the customers.

It’s never good when a project is late, but if the customer has seen constant progress along the way, and they are empowered to help decide what features should be added or removed, then you have successfully created a collaborative environment between your customers and your IT staff.

Determining “what 1.0 is” can be a real challenge – we just had a good discussion on that today with one of our current clients.  By employing Scrum, it sounds like the CIA has also learned the advantages of a highly iterative and collaborative process, and it is helping them to stay efficient and productive.  By the very nature of what they do, the CIA must be innovative, and so it should come as no surprise that they are using the latest in software development methodology.  I hope that other federal agencies will follow their lead.

Today, OpenSource Connections received notification that they had been chosen as a University of Virginia preferred vendor for Web Design, Development, and Programming Services.  The new contract should appear on the University of Virginia Preferred Vendor page within the next two weeks.

The range of services covered under the contract include:

• Information design
• Web site design/redesign/implementation
• Programming and scripting, to include HTML, Java, C, C++, PHP, CSS, RSS, C#, ASP, XML, .NET
• Interactive database design and programming (SQL Server, MySQL, PostgreSQL)
• Flash development
• Javascript development (JSON, DOM, AJAX)
• Designing for handheld devices
• Interactive design (polls, wikis, social media, learning management systems)
• Webmaster services
• Training
• Web standards (Section 508, Dublin Core, WCAG 2, etc.)
• Project management
• Search engine optimization (SEO)
• Online marketing, to include social media
• Ruby on Rails programming
• Search engine implementation (Solr, Lucene, Nutch)
• Database design

We are thrilled with the honor and look forward to working with many of our colleagues in the University on future opportunities.

On April 1, the Texas State Senate banned Microsoft Vista use by Texas state government agencies.  Citing issues with Micosoft Vista and their current level of satisfaction with XP, the Senate specifically called out Microsoft in its budget.  Will Texas be the canary in the coal mine for other government agencies?  I imagine that RedHat sent a thank you note or two to Texas state Senators.  It will be interesting to see if Microsoft can convince the Texas Senate that its issues have been sufficiently ironed out, or if other O/Ses such as Linux get a shot.  Given nationwide state budget shortfalls, it would not surprise me to see a trend in that direction, particularly smaller states who could use Texas as an example to justify a deeper evaluation of open source alternatives.  Texas near-neighbors Nebraska and Mississippi have already adopted Linux use.

What’s next?  Ubuntu?

Thanks to Steve Stedman for pointing this out!

Jim Stogdill of O’Reilly relates a presentation by LTG Sorenson about the new Battle Command system.  I dare not try to recast his insight here.  However, he did bring up one topic which I want to elaborate slightly on.  We have noticed a trend to tack on new trends and buzzwords to systems rather than either building modular, loosely coupled systems or building new platforms to take advantage of new capabilities.  The result is that while systems last longer, they become outdated more quickly, and because each new capability is simply appended rather than integrated (or the code refactored), maintenance costs grow exponentially.  Look at FBO and see how many large scale efforts are underway to deal with outdated systems.  Stogdill’s post and the subsequent discussion in the comments illuminate what happens when concepts are misunderstood.

You can read Stogdill’s excellent analysis here.