powdermonkey

Government get your Sh** Together

Commenting on the ‘new’ government digital service and TechFAR. 

Great article here:  New US Digital Service Looks to Avoid IT Catastrophes 

Discussion by Gunner: US Digital Service is Born

Steve Kelman, FCW:  The REAL regulatory challenge of agile development

 This simply isn't bold enough. This effort simply try’s to fix whats broken instead of looking more deeply at why its broken and how to ‘reformat’ the way IT services are built and most importantly used by the government and citizens.

The Service and TechFAR is akin to what the military seems to plan for: planning and building systems to fix yesterdays battles instead of really and deeply thunking for the future. 

UK: the UK gov digital service worked because its much, much smaller than our government (think California), two the UK gov is setup very differently than our government bureaucracy. The UK digital service reports directly to the PM and as I understand it, really could walk into any UK Agency (save MoD) and demand changes + take over projects. Also in a Parliamentary system, what the PM says goes, no discussing with Parliament, arguing over budgets, etc. a number of projects get killed pretty fast when there is a gov changeover. 

The US has neither. 

GSA is a pretty widely ignored Agency (for a number of historical reasons), maybe this time it will be different, I’m sure they can help web pages load faster. But the Digital service is going to report a few levels down from POTUS and the head of GSA, both of which have many other things on their plate. 

Also US Agencies have two masters they play pretty well off each other, Congress and the Pres.  Scale: the gov is friggin huge. Also some government systems have very unique and multiple functions for only one customer (the Gov + citizens).  Fixing FAA and SSA isn’t a few agile sprints over pizza and Dew.

 Instead of fixing past problems, we need deeper thinking about HOW and WHY the government should provide services. 

Examples: 

- The government no longer runs motor pools, it outsources the entire job to companies with specific service levels and agreements (SLA).

- Failed example: SABRE (the airline reservation company) came to DoD and pitched the idea that they would take care of all military travel for something like $60 a ticket. Some govvies pitched they could do it cheaper, they tried and build a disaster of a service ++ Defense Travel continues to eat funds way above and beyond. And continues to frustrate and strand military travelers overseas. 

 There are many more, but the basic take away is this: the government must not recreate services the private sector does cheaper, better and faster unless its part of its' core mission. 

• Bombs, check - part of core military mission. 
• HR? (outside of the military and CIA), the government should license or buy as a service HR capabilities. 
• Websites? I’m having a tough time with this. If the government could come up with a list of requirements and define a serious set of SLAs, they are any number of companies who would gladly offer website as a service, with the government managing the input.
• IRS systems: parts of it could defiantly be outsourced, especially all of fraud monitoring. 

One last point: 

YAR - yet another review, I don’t see how another YAR by the Digital Service is going to add to government agility and flexibility. Make no mistake, the gov is setup with a number of very expensive and time consuming YARs already, each which must be planned for and dumbed down to senior management. 

TechFAR inculcates YAR + yet another ref doc to read, that  won’t apply to any Agency that doesn’t adopt it. 

Many of these suggestions sound good for a few projects, but crumple and slow down system creation when scaled to 1000s of project in an $80 billion portfolio. 

Some question to ask as the Gov builds systems: 

1. Is the thing your Agency needs to develop a core competency? 

2. if not, define how to buy it as a fixed price service offering w/ a tight SLA

3. if yes, first start developing small + draft off of any existing efforts (open source software, or other state, local, international gov’s) ++ be open to the outside

Errata: 

• stop fixing current problems with past thinking 
• stop telling industry how to suck the egg (i.e., stop dictating to industry what methods to use to develop technologies, CMMI was great for adding bodies - thanks for the revenue, is Agile really the endpoint of development methods? Lets not hard code something (again) into how the gov does procurement)
• automate eixsting jobs, rethink how the work gets done (IRS a body shop)
• automate existing process and rethink if you need them at all 
• Start to collapse Agencies and processes. Does every Dept and Agency really need a CIO and associated staff? 
• What things could Agencies outsource to each other (like paychecks that Dept of Ag does for smaller Agencies)

 

Cost Overruns in Large Systems (HHS take note)

From my Masters Thesis, wonder how much planning went into Healthcare.gov... so if NASA who has the brains about how to build build systems has a tough time getting it right, HHS has no hope. There were also time over runs as well. 

... design decisions made early in the life cycle can have a large impact later when the technology is in operation.  An example of this in the graph by Werner M. Gruhl (Cost and Analysis Branch, NASA) presented at a INCOSE (International Council of System Engineering) System Engineering Seminar in 1998.

In the Figure 1-1, Phase A & B Costs are the costs associated with early stage conceptual planning and design of a technology. One early stage decision in the life cycle of a technology is how much money to allocate to the early stages of development and design. The chart shows that (for systems at NASA) if less than ten percent of the total cost is allocated to these early stages there can be an expectation of cost overruns. Making the decision to allocate more money to these earlier stages allows for the use of more resources to make sure the technology being developed closely matches what was envisioned.

 

 

Healthcare.gov is a 4-Star Mess

 More of a mess in the Healthcare.gov website, Now with copyright violations!!!

Obama Administration Uses Pirated Code on Healthcare.gov 

per http://torrentfreak.com/ 

"The new Obamacare website Healthcare.gov has had its fair share of problems over the past weeks, and the trouble continues. As it turns out, the Government website uses the open source software DataTables, which is a plug-in for the jQuery Javascript library. While using open-source software is fine, the makers of Healthcare.gov decided to blatantly remove all references to its owners or the original copyright license." 

Why this matters: 

 What they have basically done is strip away the marking that lable this as someone’s work. Its akin to taking a friend’s homework and erasing their name at the top of the page.  

This (unfortunatly)  happens all the time wrt open source software.. 

I hope whoever owns the copyright lodges a complaint and maybe a lawsuit. 

Does your Fed, State, Local CIO/CTO know how to code?

I think we've reached the point where we can no longer have federal, defense, state or local Chief Information Officiers much less Chief Technology Officers who can't develop, inspect, compile, deploy or run modern software and source code from scratch. 

And I don't mean they did it a while ago on punch cards or remember how bad Fortan was. No we need CIOs and CTOs who can standup a VM, a server, create a cloud and even run DevOps. 

They don't need to be crazy in depth coders, but they have to still be playing around with code and even better have commits or bug reports on some open source projects. I just think with how fast technologies are moving a CIO/CTO has to have one foot planted firmly in tech land and the other in policy or the other core part of the business so that they can call BS on tech when they see it. This would probably mean moving younger folk into these positions, which isn't a bad thing. 

SEE: JFDI as an example of folks I'm talking about

Agree, disagree? why?

If we don’t want to be like the Iranians and get Stuxnetted, take these 4 steps

Thanks to Tom Ricks for allowing me to post on his blog a short piece:

If we don’t want to be like the Iranians and get Stuxnetted, take these 4 steps

It's Wednesday, and that means another story about the looming threat of cyberattack, how vulnerable the United States and its infrastructure is, how bad the Chinese are, how to retaliate, etc. But what seems to be left out of the discussion is what can practically be done about it (beyond scolding bad people). 

The first thing that should be done is to shrink surface area for attack. What does this mean? Right now the U.S. government and industry runs a pretty homogenous set of operating systems and applications that have shown to be a big part of the problem; specifically, Microsoft and Adobe are two companies whose wares have become amazing attack vectors. Why? For a few reasons: 1) if you want to create a virus/exploit weapon you tailor one for largest adoption, 2) attack large morphing code bases that give rise to known-unknown software vulnerabilities, and 3) updates don't always filter out in time once new vulnerabilities are detected and patched.

A great example is how Stuxnet is reported to have entered the Iranian nuclear program: 

The main (and initial) infection vector is the transmission of the Stuxnet malware via USB devices: if an infected USB device is inserted into a clean PC and later accessed with the Windows Explorer, then the infection of that PC is triggered. This is due to either a malicious ‘Autorun.inf' file present on the USB device (for the oldest variants of Stuxnet) or to the usage of the ‘LNK' Windows vulnerability (MS10-046,CERT-IST/AV-2010.313 advisory) for the variants found in June 2010.

The Iranians were probably running older versions of Microsoft operating system software that wasn't updated (and was probably pirated to boot). Further, the Iranians were a victim of Microsoft's business model of stitching together source code to lock-in users and conversely lock-out other software, which allowed the virus carte blanche access to anything. 

So what should we, the government, or private companies for that matter, do? First thing, we've got to get our own house in order to limit our vulnerabilities (or "know thyself," to paraphrase Sun Tzu).

• First, get rid of software for which we have to continually make excuses. Just as the U.S. military doesn't promote smugglers (Han Solo) and farm boys (Luke Skywalker) to general, stop deploying software that requires additional fixes and comes stitched together. Microsoft and Adobe might be less expensive software, but if it leaves a backdoor open, is it really "cheaper"?

• Second, only install operating systems and applications where the source code is available for widespread public inspection. Keeping source code secret increases its widespread vulnerability to exploitation when a defect is detected.

• Third, increase heterogeneity of operating systems and applications to create gaps so that a virus/exploit can't transverse between different systems.

• Fourth, fund research into more secure operating systems and make the fruits of that investment public: A rising tide lifts all (security) boats. A small investment in maturing source code can have a large impact. 

 

 

 

Issa IT reform bill now w/ Open Source Sec 405.

very interesting langauge in the new IT Reform Bill, on open source software:

Sept 6, 2012, HR ___ Disscusion Draft 

SEC. 405. PROMOTION OF GOVERNMENT-WIDE SUPPORT FOR THE USE AND

DEVELOPMENT OF OPEN SOURCE SOFTWARE.

(a) PURPOSE.—The purpose of this section is to promote the use and

collaborative development of open source software within the Federal government.

(b) STANDARDS AND GUIDELINES.—Section 11302(d) of title 40, United

States Code, is amended by adding at the end the following: “The standards and

guidelines shall include those necessary to enable effective adoption of open

source software.”

(c) GUIDANCE.—Not later than 180 days after the date of the enactment of

this Act, the Director, in consultation with the Chief Information Officers Council,

shall issue guidance for the use and collaborative development of open source

software within the Federal government.

(d) MATTERS COVERED.—In issuing guidance under subsection (c), the

Director shall include, at a minimum, the following:

(1) Guidance to clarify that the preference for commercial items in

section 3307 of title 41, United States Code, includes all open source

software that meets the definition of commercial item in section 103 of

title 40, United State Code, including all such software that is used for

non-Government purposes and is licensed to the public.

(2) Guidance regarding the conduct of market research to ensure

the inclusion of open source software.

(3) Guidance to establish a program to educate the acquisition

workforce by providing information to identify and counter

misconceptions about open source software and to keep such

information updated.

(4) Guidance to define Government-wide standards for security,

redistribution, indemnity, and copyright in the acquisition, use, release,

and collaborative development of open source software.

(5) Guidance for the establishment of a Government approval

process to qualify open source software for widespread Government

use, addressing issues such as security and redistribution rights.

(6) Guidance to establish standard service level agreements for

maintenance and support for open source software products widely

adopted by the Government, as well as the development of

Government-wide agreements that contain standard and widely

applicable contract provisions for ongoing maintenance and

development of open source software.

(7) Guidance on the role and use of the Federal Commodity

Information Technology Acquisition Center, established pursuant to

section 11501 of title 40, United States Code (as added by section 302),

for acquisition of open source software.

(e) REPORT TO CONGRESS.—Not later than 2 years after the issuance of the

guidance required by subsection (b), the Comptroller General of the United States

shall submit to the relevant congressional committees a report containing—

(1) an assessment of the effectiveness of the guidance;

(2) an identification of barriers to widespread use by the Federal

Government of open source software; and

(3) such legislative recommendations as the Comptroller General

considers appropriate to further the purposes of this section.

 

It's only your tax dollars

This is a little something I've posted to the Whitehouse.gov site, if you agree please sign up and sign the petition, it is your tax dollars. 

Maximize the public benefit of federal technology by sharing government-developed software under an open source license

Top Three Reasons to Mandate Open Sourcing of Custom Federal Software:

Openness: Open Sourcing ensures basic fairness and transparency by making software and related artifacts available to the citizens who provided funding, consistent with the President’s 2009 declaration that “Information maintained by the Federal Government is a national asset.”

Economic Multiplier: Making Provides an economic stimulus by serving as the raw material that supports a competitive software development and services industry.

Supports the Federal “Shared First” Agenda: Maximizes value to the government by significantly increasing reuse and collaborative development between federal agencies and the private sector, consistent with the current Office of Management and Budget (OMB) “Shared First” initiative.

Link Here: Maximize the public benefit of federal technology by sharing government-developed software under an open source license.

 

Someone Doesn't like Accumulo

Someone doesn't like Accumulo. And by the looks of it they are very well versed in the language of open source software (OSS).

Back ground: Accumulo was recently released as OSS to the Apache foundation and has to do with securoty features using a cloud architecture. What was interesting is that NSA funded, created and released it to build a community around these features that they wanted. 

Let the guessing begin on who put this in...

Department of Defense use of National Security Agency
cloud computing database and intelligence community
cloud computing infrastructure and services (sec. 929)
The committee recommends a provision that would prohibit the
use of the National Security Agency’s (NSA) Accumulo cloud computing database by other Department of Defense (DOD) components after September 30, 2013, unless the Chief Information Officer certifies that there are no viable commercial open source databases that have the security features of Accumulo, or that
Accumulo itself has become a successful open source database
project. The provision also would require that Department of Defense and intelligence community officials coordinate fully on the
use by DOD components of cloud computing infrastructure and
services offered by the intelligence community for purposes other
than intelligence analysis to ensure consistency with the DOD information technology efficiencies initiative, data center and server
consolidation plans, and cybersecurity plans and policies.
The committee applauds NSA’s decision to adopt open source architectures and software for most of its cloud computing development. However, the committee disagrees with NSA’s decision to develop its own cloud computing database—called Accumulo—rather
than adapt an open source version of the Google BigTable product.
The committee understands that NSA decided to build a government solution several years ago because the open source systems
lacked security features that NSA considers essential. In hindsight,
the committee believes it would have been smarter for NSA to have
worked with industry and the open source community to add NSA’s
security features to the open source database systems. Indeed, the
committee believes that NSA should pursue that course now.
The downside of using a government-unique database is that,
compared to open source products, there will be far fewer developers contributing to technology advances, and all of the applications, analytic tools, and functionality that the open source community and commercial industry are developing for cloud computing
will not be compatible or interoperable with the NSA database, depriving the government of valuable innovation. The committee believes it is very likely that the rapidly expanding and innovating
cloud computing industry will pass NSA by in a hurry, with lagging performance and higher costs. The consequences would not be
confined to NSA, since the Army intelligence community has already adopted the NSA cloud architecture, and NSA is strongly
urging the entire Department of Defense to do likewise. One of
NSA’s arguments is that the security features of Accumulo are essential for the cybersecurity of DOD as a whole.
NSA is making an effort to heal its divergence from the open
source community by proposing Accumulo as an open source project
under the Apache Foundation as a competitor to existing Apache
Foundation open source databases like HBase and Cassandra,
which are widely used and supported in industry.
The committee believes it is important to ensure that there are
options available if Accumulo does not in fact become a viable and
widely supported open source project. The committee is aware of
commercial interest in the cell-level data tagging security features
that NSA built into Accumulo. These features should be as useful
to industry clients who need to protect and control access to the
data resident in cloud facilities as they are to the intelligence community and DOD.
If Accumulo is successful, or if the commercial open source community produces nothing comparable to Accumulo’s security features, this provision would permit Accumulo to be used in DOD
outside of NSA. But if Accumulo is not an open source success, and
if industry follows NSA’s security lead, the Department should use
a commercial product. This provision would give NSA almost 2
years since it made the Accumulo open source proposal to Apache
to succeed. The deadline in this provision is also sufficiently distant
to enable DOD components and industry to plan accordingly.
Under the direction of the Director of National Intelligence, the
Central Intelligence Agency (CIA) and NSA are planning to provide
cloud infrastructure and software ‘‘as a service’’ to all of the intelligence community. As noted, NSA is offering a government implementation of open source standards. CIA is offering a competitively
awarded commercial solution. These cloud services would cover all
manner of computing needs and capabilities, not just intelligence
analysis. This provision is also intended to ensure that DOD components’ use of these cloud services is consistent with DOD information technology policies and plans. The committee notes that the
software services that the CIA may offer to DOD customers could
include analytic databases like HBase and Cassandra, and other
commercial open source products, potentially providing an alternative to Accumulo.

Notes from the CERN Open Hardware Workshop

Notes from the CERN Open Hardware Workshop

http://www.ohwr.org/projects/ohr-meta/wiki/OHWorkshop

The workshop was held during the Sunday preceding ICALEPCS 2011, i.e. 9 October 2011 in Grenoble, France.

Session 1: Introduction and legal framework. This was an opportunity to define exactly what we mean by OH and discuss the latest developments on the legal side, such as the CERN Open Hardware License.

• Open Hardware: what, why, how, when, who (Javier Serrano, video CC BY-SA). This presentation will introduce the concept of Open Source Hardware (OSHW) and gave a summary of current efforts in the OSHW world. Introduced legal and commercial issues, as well as considerations on how to improve collaboration on hardware design among labs, universities and companies.

/

ppt here: http://www.ohwr.org/attachments/824/javier.pdf

see http://freedomdefined.org/oshw for software freedoms translated into the hardware domain

Reasons for OSHW:

for designers:

-        avoid duplication

-        get peer review/help

-        spend time tackling more ambitious problems

for companies:

-        peer review

-        compensate weak areas in a company with external help

-        build hybrid solutions

for clients:

-        no vendor lock-in

-        easier management of obsolescence

how to:

-        put your staff online, e.g., CERN open hardware repo

-        use OSHW definition

-        deal properly with liability

use FOSS tools for development

Find a good community model  

/

• Summary of the Open Hardware Summit (Tomasz Wlostowski, video CC BY-SA). A quick summary of the Open Hardware Summit, held on September 15th in New York City.

/

Open hardware superstar was Arduino + Arduino deploying ARM chips

Good talks by instructables.com (recently bought by AutoCad) and ifixit.com

Session on OH and the law

Ohanda.org is creating a sort of licensed hardware meta directory

Legal threats against OH were also discussed: DMCA, etc.

Protei: a project to create an autonomous sailboat to clean oil spills

Fukushima earthquake: an OH project was quickly created in a week for how to build your own gieger counter

Eyewriter: OH project to enable people with ALS the ability to use a computer

Amanda Wozniak: great session on open sourcing the engineering process  

/

• Open Hardware Licensing (Myriam Ayass, video CC BY-SA). The CERN Open Hardware Licence v.1.1 was released on July 7 2011. The purpose of this presentation is to provide some background information as to the context in which it was developed, the reasons and rationale for developing it and expected outcomes. A description of the main provisions will be given together with the main issues and solutions that were discussed during the process. Furthermore, thanks to the feedback received from the community, plans for v.1.2 of the license will be presented.

/

Ms. Ayass is part of the CERN Knowledge Transfer Group

Options for legal OH legal framework:

-        use current open source licenses? No

-        use creative commons (CC) license? No

-        use other open hardware license? No

CERN needed/wanted to track the spread of their hardware work, hence the reason behind the “inform licensor” section in the license

so they created the CERN OHL to partially meet this need

the next version 1.2 waters down the “inform” section

how does the TAPR OHL compare with CERN?

-        TAPR was drafted with specific jurisdiction – US

-         Core concept: reciprocal immunity from patent suits

-        distribution of documentation with product sold

-        in-kind request to notify licensor when product manufactured and sold

http://www.ohwr.org/projects/cernoh

/

• Arduino (David Cuartielles, video CC BY-SA). Arduino is an open source hardware platform created in 2005. The platform itself is made of circuit boards, a software development environment, a website to gather documentation about projects, and a series of tools to empower a community of users.

/

Arduino is a non-profit and receives license fees from its design for operating funds. Only about 10 people work at Arduino.

There was an open source hardware workshop about Arduino in Madrid, Spain (in Spanish, so not many English speakers heard about it). 600 people in attendance

Arduino gets about 45 (?) mil hits a month

2011 August 1 million units cumulatively sold, next expect 2 million

How open is Arduino:

1. Software IDE is GPL (inherited)
2. Core is GPL (inherited)
3. Hardware/blueprints are CC 3.0 SA (creative commons version 3.0 share alike)
4. Documentation is CC 3.0 SA

He told an interesting story about how Google-Android copied and modified one of the Arduino designs for the IO board and then Arduino in 40 hours replicated and posted the design as OH.

Business Model: keep a new design closed/secret before release and cut deals with manufacturers, then publish version 1.0 of the circuit board because almost immediately clones will begin to show up. The go after manufacturers who use the Arduino name brand without license. Clones come out quickly – 3 weeks in some cases.

/

Session 2: Business models. It is very interesting to discuss the role(s) of companies and how they can make business under an open paradigm.

• Open Hardware in Creotech (Grzegorz Kasprowicz, video CC BY-SA). Creotech is a company set up by former CERN and other scientific laboratories workers. Its mission is to create innovative, ready-to-implement solutions of electronics and electromechanics. We specialize in digital cameras (including solutions for astronomy), multichannel measurement systems (e.g. for ITER and JET), acquisitions cards (designed for CERN), systems of data transmission and special power supplies (e.g. for GEM detectors).

/

Creotech builds detectors. As a result with more things going fully digital with software, having open source hardware and software makes its easier for their customers (primarily CERN) to track down bugs and anomalies in readouts.

Uses and gives back to the White Rabbit project: http://www.ohwr.org/projects/wr-cores

/

• Open Hardware perspectives in National Instruments (Ravi Marawar). National Instruments (NI) is a Commercial-off-the-Shelf (COTS) system provider that combines heavily researched designs manufactured with state-of-the-art quality control processes and guaranteed long term lifecycle management. NI product designs are influenced by reliability and quality goals, calibration needs, safety certifications, environmental and security compliance requirements and longevity expectations.

/

It seems NI is being forced into OSS by its customers

Uses White Rabbit: http://www.ohwr.org/projects/wr-cores

/

• First experience in Seven Solutions (Eduardo Ros, video CC BY-SA). Seven Solutions is a technology based company (intensively engineering based company). The company offers services of design, technology consulting, custom electronics, embedded computing, etc. After launching its own hardware based products, Seven Solutions is aware of how the OHR paradigm can benefit SMEs in this field, by providing a shield of confidence (making SMEs dependable entities), facilitating the active participation in medium scale designs as part of an engineering community and making easier the process of how an SME offers its services as add-ons on projects conjointly run by different institutions. Furthermore, OHR allows development cost sharing among different institutions since Intellectual property does not create borders between participating companies.

/

Motto: learn fast or die

They use and publish open hardware designs for press and to let people know what they do

The might publish their FPGA high performance processing platform

The stated that its helpful to have a “tractor” Agency/company pulling open hardware along to:

-        Start and funs projects

-        Give credibility to

-        Provide other customer access to

/

• Clear roadmap for Open HW in Instrumentation Technologies (Borut Repič, video CC BY-SA). Instrumentation Technologies has been addressing Open HW for quite a while even though it has not been called so officially. Apart from the main line of its top-end products, forming the base of knowledge, experience and practices it launched a separate line under the umbrella of so called "Working together". Thus, the result of a development project may be a "classical", Libera–type product or it may be a totally independent project resulting in a solution completely tailored to customer needs

/

www.i-tech.si

/

• The Facebook Open Compute Project (John Kenevey). Facebook's Open Compute Project is a nascent community which is actively seeking participants who are passionate about making strong technical contributions to defining and delivering the most efficient server, storage and data center designs. One of the enablers of said community is to ensure they have the necessary tools to provide open electrical and mechanical designs to the Open Compute Project.

/

http://opencompute.org/

Facebook is in the process of releasing software and hardware designs for its server centers. The official kick-off is October 27^th, more data coming out soon.

/

Session 3: Tools. Most of our tools are not open themselves yet. Here we discuss about what is the current offer and possible future plans. This affects mainly HDL simulation and PCB design.

• gEDA (Larry Doolittle, video CC BY-SA). gEDA is an umbrella term for a collection of Free Software EDA tools that share the philosophy of modular, flexible software that has proven so powerful in the Unix software world. Conventional modules like schematic capture and PCB layout interact with each other, and with other gEDA tools such as simulators and footprint generators, and also with proprietary tools through documented human-readable file formats and easy scripting. gEDA is also home to gerbv (Gerber viewer), icarus (Verilog compiler and simulator), and gtkwave (waveform viewer). While flexibility of these tools is their strength, this talk will provide a concrete example of how they can tie together for a single design. It will also demonstrate the user interface of the graphical tools, which has been slowly refined since 1998 (gschem) and 1994 (PCB).

/

Larry Doolittle, Lawrence Berkeley National Lab

http://www.gpleda.org/, What is gEDA?

The gEDA project has produced and continues working on a full GPL'd suite and toolkit of Electronic Design Automation tools. These tools are used for electrical circuit design, schematic capture, simulation, prototyping, and production. Currently, the gEDA project offers a mature suite of free software applications for electronics design, including schematic capture, attribute management, bill of materials (BOM) generation, netlisting into over 20 netlist formats, analog and digital simulation, and printed circuit board (PCB) layout.

The gEDA project was started because of the lack of free EDA tools for POSIX systems with the primary purpose of advancing the state of free hardware or open source hardware. The suite is mainly being developed on the GNU/Linux platform with some development effort going into making sure the tools run on other platforms as well.

/

• Kicad (Dick Hollenbeck, video CC BY-SA). KiCad is a an open source software tool suite for the design of printed circuit boards. It includes internationalized tools for hierarchical schematics, board layout, component assignments, gerber generation and viewing, and a calculator for board signal integrity. A quick and simple overview is given of the schematic and layout tools using sample datafiles from a working 6 layer ARM9 board. Discussed are source code quality, rate of advancement, datafile formats, project philosophies and major contributors, as these are predictors of KiCad's viability as a foundation on which to embody open source hardware designs for the OHW community.

/

Very mature printed circuit board (PCB) layout OSS tool

http://www.lis.inpg.fr/realise_au_lis/kicad/

http://kicad.sourceforge.net/wiki/Main_Page

User interface is in 20 different languages + user manuals

May 2007: 3 people 75% of commits

-        lead developer is Jean-Pierre Charras, 40 years of experience

-        Wayne Stanbaugh

-        Dick Hollenbeck

Uses a DCVS – Bazaar

Project coding standards do exist

Code quality is very good, this helps to involve more people, more easily

Is looking to move to S-expressions instead of XML because in XML designs can be enormous: the language is called SWEET (http://sweet.xtronics.com/main.html). SWEET is a declarative schematic part language description language based on s-expressions.

SWEET is peer-to-peer and able to operate from within the interent

Wheeler on SWEET: http://www.dwheeler.com/blog/2006/06/17/ , http://www.dwheeler.com/readable/sweet-expressions.html

/

• What's missing in current FOSS PCB design tools (Tomasz Wlostowski, video CC BY-SA). An assessment of missing features in current FOSS PCB design tools as discussed in the foss-pcb mailing list, along with some plans to palliate these shortcomings.

/

a big need is a web-based distributed library model

email list here: [email protected]

/

• Makefile-driven HDL flow (Pawel Szostek, video CC BY-SA). Maintaining HDL is a source of many problems, not necessarily related to design issues. When developers want to perform a synthesis, they have to struggle through massive clicking job in an IDE and face compatibility problems among different versions of the same tool. What is more, synthesis of big projects is a time and resource-consuming process that makes the edit-compile-test cycle unreasonably long and makes it harder to introduce trivial modification to the hardware. When simulating VHDL models developers usually have to set correct compilation order. Hdlmake is a kind of swiss-army knife that tries to solve mentioned problems by generating a multi-purpose makefile. Hdlmake automatically detects file dependencies, generates IDE-specific project files, facilitates remote synthesis. It also offers a solution that makes modularization and managing of a project easier.

/

hdlmake – stored in OWWR and python

can make files for:

-        simulation

-        sythesis

/

• Icarus Verilog/VHDL (Pawel Szostek, video CC BY-SA). In the era of open source many companies and institutes are in the process of streamlining their hardware design flow to adopt open software development tools which will facilitate collaboration with external actors. We aim to build an open source tool that would allow developers to simulate and to share easily their designs, even if they cannot afford buying a powerful but expensive commercial piece of software. To achieve our goal we picked Icarus Verilog which is one of the most popular Verilog simulation tools. It is now being extended by a group of programmers who are concentrating their efforts on implementing support for SystemVerilog and synthesizable part of the VHDL. The final version of Icarus should allow people to simulate their mixed-language models along with testbenches written in Verilog or SystemVerilog.

/

-        co-existance of VHDL, Verilog, Systems Verilog

-        VHDL not suitable for complex TB

-        No operating systems for language simulation

-        Collaboration between Europe/US is tough

-        Commercial systems are expensive

-        http://verilog.wikia.org

/

• How to design logic synthesis and place&route tools (Sébastien Bourdeauducq, video CC BY-SA). While many researchers and engineers agree that several obstacles stem from the proprietary tools of the FPGA vendors, writing an alternative from scratch has always been perceived to be far too complex of a task. This perception comes largely from the lack of generic knowledge about the internals of a synthesis and place-and-route tool and the absence of published details regarding particular FPGA architectures and bitstream formats. In order to encourage the development of alternative tools, we will attempt to shed some light on these concepts and give hints about how the Xilinx Spartan-6 architecture and bitstream format work and how they could be fully understood.

Session 4: Ongoing projects in labs and institutes. A selection of current projects illustrating OH practice.

/

How to build an OSS FPGA toolchain

http://eeeg.toronto.edu/vtr

http://milkymist.org/fpgatools

/

• CERN OH developments (Erik van der Bij, video CC BY-SA). CERN has been practicing OSHW for more than two years now. The talk outlines some of the technical choices and discusses the current state of developments, both technically and in terms of collaboration with companies and other labs. The advantages of OSHW will be illustrated with concrete examples.
• OH developments in Soleil (Pascale Betinelli, video CC BY-SA). The Synchrotron SOLEIL is a third-generation light source located near Paris. The facility receives each year more than 2500 international scientific users. SOLEIL covers fundamental research needs in physics, chemistry, material sciences, life sciences, earth sciences… In applied research, SOLEIL is involved in very different fields such as pharmacy, medicine, chemistry, petrochemistry, environment, nuclear energy, as well as nanotechnologies, micromechanics and microelectronics, and more. Many other synchrotrons are present all around the world with similar or complementary performance. Today the synchrotron community encourages collaboration and sharing of development between synchrotron facility and at the same time competition. Other synchrotron facilities are interested in some of our hardware developments and because we can share this development with them, it is evident for us (the technical team) to join the open hardware initiative. But some conditions have to be taken into account, requiring stages in the process. After a short presentation of Soleil, I will explain our mission, our organization, what we want to share and our difficulties to convince people of the interest of this initiative.
• The Rhino Project (Brandon Hamilton, video CC BY-SA). The RHINO Project is an Open Source effort born out of the radar remote sensing group at the University of Cape Town in South Africa and motivated by CASPER and the SKA Africa project. Rhino, which stands for Reconfigurable Hardware Interface for computiNg and radiO, consists of a hardware platform that includes an ARM running Borph Linux, a Spartan 6 FPGA, DDR3 memory, dual FMC-LPC as well as numerous standard IO interfaces. The goal of the project is to provide a hardware platform and software tool-chain for Software Defined Radio (SDR) which is both easy to use, easy to learn and affordable to a broad audience. It is hoped that this effort will consolidate and enhance the teaching and research resources available for Software Defined Radio (SDR), nationally and among the hacker community. This talk will provide an overview of the hardware and software that make up the Rhino ecosystem, along with some current and future applications that show the potential of the platform.

/

Target is software defined radios and applications

Uses:

-        CASPER software out of Berkeley

-        BORPH – Berkeley Operating System for Reprogrammable Hardware: http://www.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-92.html

/

• Open Discussion/Closing

Transparency & Failure in .Gov/.Mil IT

Recently at the Gov 2.0 summit Fed CIO Viveck Kundra talked about stopping/killing some very expensive .gov IT programs, video here:

Gov 2.0 Summit 2010: Aneesh Chopra and Vivek Kundra, "Closing the Technology Gap"

But I was left wondering what were the programs and more over why killed? Oftentimes federal (and military) IT programs will be killed or left to die, without a postmortem or documeting lessons learned. Sometimes an intrepid reporter will try to one, but that usually just scratches the surface. GAO or internal Government offices will sometimes do them if asked to by Congress, but GAO reports are usually only for the largest of the large failing programs. .Gov internal reports are usually not published or done, much less published.

Its always struck me as weird that the government doesn't push more of a lessons learned culture like the one ingrained in the military (but sadly not in the military IT field). We do this for plane crashes, but there doesn't seem to be a systematic process for documenting IT failure?

(if there is please post)

I'm hoping that Viveck and Team can come up with some sort of simplified lessons learned document, this would do a few things:

1. Put government / contractors on notice that failure will be documented, like Gunnar says "The gov doesn't look good Naked" but it might be in better shape if it was

2. Learn, Learn, Learn: doomed to repeat mistakes if we don't learn

3. Gather requirements for potential changes in process, law, promotion schedules, etc. IF need be

A lessons learned doc should include: original cost of program (estimate and contractor proposed), original period of performance, winning contractor team, dollars spent, government intellectual property developed, reasons for cancellation, etc. I'd put a floor on the study and get a small team 2-3 weeks to prepare a doc, maybe only document failure under $ xx millions?

Or maybe this would be better as a wiki somewhere?

thoughts? unworkable? makes folks too uncomfortable?