Tag Archives: oss

DC Metro Open Source Community Summit May 10, 2013

The Open Source Initiative (OSI) is hosting the non-profit DC Metro Open Source Community Summit, to be held in Washington, DC on May 10th, 2013.  The program will include short sessions by community notables and an “unconference” format for maximum attendee participation, collaboration, and learning.
Open source community and user group leadership, open source project leads, committers and developers, non-profit foundations, open data engineers and others with an interest in learning more about growing and sustaining open source should attend.  Registration is free to government employees, $20 to non, and includes lunch.
Program details and registration information is available at the event web site.
Event sponsors underwriting the non-profit event include Google, Eclipse Foundation, Red Hat, GitHub, Georgia Tech Research Institute, and MIL-OSS.

The latest White House moves on open source: Connecting citizen developers to tools

This week, in the latest step to connect citizen developers with the tools they need to unlock government data, the White House updated their website to include a developers resources section. More than a mere technical reference post, the White House affirmed that:

“We believe in using and contributing back to open source software as a way of making it easier for the government to share data, improve tools and services, and return value to taxpayers.”

The section includes a list of their open source projects. GitHub and Drupal get top billing in the list.

In 2010, the White House was recognized by Open Source for America for its leadership in using and recognizing open source. This latest affirmation confirms that commitment.

But, it is not only manifestation of that engagement. For example:

On August 23, they released the code for the White House apps and the code for the “We the People” online petition system. Releasing the source code for We the People is like a double dose of open source. The program allows citizens to create online petitions. If the petitions reach 25,000 signatures, the topic receives special attention from the Obama Administration. Since October 2011, 30 petitions have crossed the threshold and spurred change. This allows citizens to have direct influence on important topics and is a fantastic example of open government in practice.

Bringing the issue to the international stage, President Obama spoke about it at the Open Government Partnership. He made clear that steps like those taken by his own White House on open source are an important component of the US Government’s efforts to “share the technology so any government in the world can enable its citizens to do the same.” In so doing, the Administration sees a direct connection to the goal of the Partnership, which seeks to foster a “global effort to make governments better … more transparent, effective and accountable … with institutions that empower citizens and are responsive to their aspirations.”

On September 4, they released the source code for the White House apps made for iOS and Android on GitHub. The administration hopes that anyone “from civic hackers and local organizations to federal agencies” will download the apps, make changes, and use them for their own projects, according to the White House blog. President Obama’s goal for these apps is to make the government more open by sharing more information.

Thanks to Casey Brown for her research and contributions to this post.

Original article authored by Mark Bohanan on opensource.org .

New source code policy: open and shared

For the first time a U.S. Federal Agency (The Consumer Financial Protection Bureau) has come out with a policy that clearly delineates how taxpayer investments in technology should be handled. since they say it best:

“The Consumer Financial Protection Bureau was fortunate to be born in the digital era. We’ve been able to rethink many of the practices that make financial products confusing to consumers and certain regulations burdensome for businesses. We’ve also been able to launch the CFPB with a state-of-the-art technical infrastructure that’s more stable and more cost-effective than an equivalent system was just ten years ago.

Good internal technology policies can help, especially the policy that governs our use of software source code.

Some software lets users modify its source code, so that they can tweak the code to achieve their own goals if the software doesn’t specifically do what users want. Source code that can be freely modified and redistributed is known as “open-source software,” and it has been instrumental to the CFPB’s innovation efforts for a few reasons:

• It is usually very easy to acquire, as there are no ongoing licensing fees. Just pay once, and the product is yours.

• It keeps our data open. If we decide one day to move our web site to another platform, we don’t have to worry about whether the current platform is going to keep us from exporting all of our data. (Only some proprietary software keeps its data open, but all open source software does so.)

• It lets us use tailor-made tools without having to build those tools from scratch. This lets us do things that nobody else has ever done, and do them quickly.

Until recently, the federal government was hesitant to adopt open-source software due to a perceived ambiguity around its legal status as a commercial good. In 2009, however, the Department of Defense made it clear that open-source software products are on equal footing with their proprietary counterparts.

We agree, and the first section of our source code policy is unequivocal:

We use open-source software, and we do so because it helps us fulfill our mission.

Open-source software works because it enables people from around the world to share their contributions with each other. The CFPB has benefited tremendously from other people’s efforts, so it’s only right that we give back to the community by sharing our work with others.

This brings us to the second part of our policy:

When we build our own software or contract with a third party to build it for us, we will share the code with the public at no charge. 

Exceptions will be made when source code exposes sensitive details that would put the Bureau at risk for security breaches; but we believe that, in general, hiding source code does not make the software safer.

2012 CFPB Source Code Policy