Submitted via IRC for TheMightyBuzzard
The Army's decision to formalize its open-source software development policy is paying off. At least two major projects have benefited from the policy announced this spring, with open source helping to speed development and save taxpayer dollars, according to officials from the U.S. Army Research Laboratory.
"Open source can reduce development time and lower overall costs, resulting in a win-win situation for the Army and the U.S. taxpayer," said ARL Deputy Chief Scientist Mary Harper.
When it comes to defense agencies embracing open-source software development, the Army is hardly at the cutting edge. The National Geospatial-Intelligence Agency paved the way with the launch of its GitHub open-source community in 2014. The Navy issued a guidance on the use of open-source code as early as 2007.
Still, ARL leaders say they expect to reap big benefits by formalizing their approach to open source, a term used to describe software for which the original source code is made freely available and may be shared and modified.
[...] Looking ahead, ARL leaders say their explicit embrace of an open-source approach should be a boon to the other military services. But they aren't yet offering insight into just what those evolutions might look like.
"It's extremely difficult to guess how the code might be used or leveraged by others," Harper said. "ARL's belief is that [the U.S. Army Tank Automotive Research Development and Engineering Center] and other groups will leverage the code as they see fit to support mission and potentially improve ARL's code at the same time. This has been the case for extremely popular open-source projects such as the Linux kernel, and ARL hopes to leverage this power as well."
Source: https://www.federaltimes.com/it-networks/2017/08/14/army-reaps-benefits-of-open-source-policy/
(Score: 0) by Anonymous Coward on Friday August 18 2017, @03:03AM (4 children)
Open source software is OLD HAT for the Army. Aside from a public proclamation, there is nothing new here.
When I got my first job out of college way back in 1995, it was writing software for the Army that ran on Linux laptops.
(Score: 0) by Anonymous Coward on Friday August 18 2017, @04:21AM (3 children)
Open Source becomes open source through the use of copyright. But copyright does not apply to government software. It is either Public Domain or Classified.
You know you need to be more specific when you say you wrote software for the Army. Did you write wholly original software which was Public Domain by law as a work of the US Government? Or did you write partially derivative software which was Open Source under copyright law and open source license?
In the context you mentioned, the mere fact that the software ran on Linux is fucking irrelevant.
Now, mod me the fuck down for saying Linux is fucking irrelevant.
(Score: 0) by Anonymous Coward on Friday August 18 2017, @05:24AM
The infrastructure for the software (operating system, common utilities, etc.) was open source.
I think that was clear.
(Score: 1, Informative) by Anonymous Coward on Friday August 18 2017, @05:54AM (1 child)
You have written quite a bit about copyright for software written for a US Govt contract.
It's too bad you don't know your subject.
Here are the facts, excerpted from
http://www.mccarter.com/Protecting-IP-When-Contracting-With-the-Government-08-31-2010/ [mccarter.com]
Copyrighted Material
Contractors may also retain ownership of any copyrighted material developed or delivered under a government contract.
(...)
In exchange for the contractor's copyright in material produced during performance of a government contract,
the government is typically granted a non-exclusive, irrevocable license to use, modify, reproduce, release,
perform, display, or disclose the copyrighted work by or on behalf of the United States throughout the world.
End excerpt.
Notice there is nothing there about public domain. If the contract was written such that the contractor retains copyright, the govt generally can do whatever it wants with the software, even up to releasing it to the public, but that doesn't give the public the right to legally modify and redistribute the software (i.e., put it in public domain).
(Score: 2) by The Mighty Buzzard on Friday August 18 2017, @10:51AM
It depends on if the software was contracted or work-for-hire. In work-for-hire situations, he's absolutely correct; you do not get copyright on your work. This generally isn't going to be the case for software contractors though as we tend to charge way, way more if you want something written that we can never reuse parts of.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Friday August 18 2017, @03:22AM (1 child)
Summary is supposed to summarize, a short gist of the main bits. TFA is neither short, nor contain anything of substance - is there actuallly any "main bits?"
(Score: 0) by Anonymous Coward on Friday August 18 2017, @03:41AM
You aren't looking in the right places. Look carefully to your crotch area, do you see any bits there?
No? Then, as you were, there aren't any bits worth of your attention.
You found them? Didn't your parents teach you it's not nice to wank in public forums?
(Score: 3, Funny) by c0lo on Friday August 18 2017, @03:49AM (5 children)
You know? Not many geeks are able to develop and/or test the software without the appropriate hardware.
So, unless you provide a tank to 400-1200** [pingdom.com] contributors, I doubt you are going to... mmm... leverage the same popularity as the Linux kernel.
---
** those numbers are 5 years old
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Friday August 18 2017, @04:24AM (1 child)
Tank emulator.
(Score: 0) by Anonymous Coward on Friday August 18 2017, @07:50PM
bzflag?
(Score: 2) by Snotnose on Friday August 18 2017, @04:34AM
*cough*China*cough*
Not to mention, the software can give pretty nifty clues as to how the hardware works.
Why shouldn't we judge a book by it's cover? It's got the author, title, and a summary of what the book's about.
(Score: 2) by coolgopher on Friday August 18 2017, @07:35AM (1 child)
Yeah, I think that whole idea will tank.
(Score: 0) by Anonymous Coward on Friday August 18 2017, @12:51PM
Is that all the tanks we get?
(Score: 3, Informative) by MostCynical on Friday August 18 2017, @07:36AM (1 child)
"we've found a way to get geeks to do stuff for us, and we don't even have to pay"
"I guess once you start doubting, there's no end to it." -Batou, Ghost in the Shell: Stand Alone Complex
(Score: 0) by Anonymous Coward on Friday August 18 2017, @11:47AM
whatever. I say scipy is a lot better than matlab because it is free and open source, and its writers use it so they benefit.
(Score: 2) by kaszz on Friday August 18 2017, @10:27AM
Military -> RedHat -> systemd
Incoming!! "sorry your system lacks /etc/poett/special/only/red/conslut/specialtypo.txt so can't reboot" .. ..... *BOOM*
RedHat: No military user has ever complained.
(Score: 0) by Anonymous Coward on Friday August 18 2017, @12:12PM
Here's the git hub site
https://github.com/USArmyResearchLab [github.com]
There are 6 projects there.
2 are not projects, but rather site usage instructions.
1 is a Python based network traffic decoder.
1 is a weather data format converter
2 are programming examples for a low power gpu competitor asic called Adapteva Epiphany
Pretty harmless stuff. Definitely not giving away any official secrets.
It's interesting that such a minor site would make the news here.
(Score: 1) by pdfernhout on Saturday August 19 2017, @01:13AM
https://groups.google.com/d/msg/openmanufacturing/RSKxwIUgB8s/e2fKPZNxWy0J [google.com]
"Re: [Open Manufacturing] Re: Roadmap for Open Hardware (ohroadmap.org)"
On 9/24/10 12:51 PM, James - Coder by day, fabber by night wrote:
> My goal with the www.ohroadmap.org wiki is to develop a technology
> roadmap which identifies current and future technologies in open
> hardware/open manufacturing as well as technology gaps, barriers,
> industry targets, and research areas.
Here is a rambling sketch of some ideas related to reusability of open
hardware designs that seeing your Wiki and your description makes me think
about.
http://www.ohroadmap.org/ [ohroadmap.org]
[Link went bad, but see: https://web.archive.org/web/20101030014314/http://www.ohroadmap.org/ [archive.org] ]
This is also inspired in part from watching the Open Hardware Summit
streamcast that Bryan posted about, where one participant (possible Eric von
Hippel?) said there were three big competing issues:
* project
* product
* platform
Each of these three (project, product, platform) may have different
requirements or social approaches from an open manufacturing perspective.
The issue of reusability of designs (especially when all you have is CAD or
CAM files) is something that has been in the back of my mind for a long
time, considering the fact that things created by hand often are adapted to
materials at hand as well as quirky circumstances. Or at least, that's
tended to be my own experience. :-) I often scrounge around for things and
adapt designs to materials, tools, and subcomponents that I have easily
available. I may iterate that process several times, too, as solutions fail
to be good enough. So, even having detailed 3D designs may not be that
useful to me, unless I had everything I needed to put together an entire
complex product. That assuming a design wasn't just all printed as a working
unit from some amazing nanotech printer, which remains a ways off -- and
even then, we would probably need to sometimes think in terms of "repair" or
"improvement" with scrounging whatever was on hand.
Here is an example inspired by your link to this with a picture of a couple
of tanks in a desert:
http://www.mitre.org/news/digest/advanced_research/08_10/layer.html [mitre.org]
Consider that image, in the context of product, project, and platform.
I'm personally not very interested in building tanks, as a "product". Tanks
(or, say, even just self-propelled Howitzers) are a product that is probably
illegal for me to own, at least if it had live ammo. And even it was legal,
a tank would be expensive to build and maintain, and having one around might
worry my neighbors a bunch and mess up the driveway. :-) Related by me:
"Intrinsic/mutual security vs. extrinsic/unilateral"
http://slashdot.org/comments.pl?sid=1783364&cid=33537044 [slashdot.org]
Likewise, I'm not interesting in using a tank to do anything in a desert as
a "project". Those are typically projects that, as my sig below suggests, I
consider a likely example of "irony". :-) Also rlated by me:
http://www.pdfernhout.net/recognizing-irony-is-a-key-to-transcending-militarism.html [pdfernhout.net]
But tanks have a lot of brackets, and I've very interested in brackets in
general (as a "platform" in at least two senses of the word. :-) That's as a
platform to hold things up, and also a platform in a general sense of
software that might help design brackets to specific needs.
So, I have a common interest with someone who designs tanks. Brackets are
just really, really, important in life. :-) I mean, where would be be
without brackets? Everything would be one big jumble. :-)
When I was a kid, my father (a merchant mariner, a machinist, and then a
manufacturing engineer), made brackets for me for some robots I made. But
now, sadly, he's not around (a casualty to heart disease -- preventable it
turns out, with the Fuhrman nutritional plan and adequate vitamin D, but I
did not know that back then).
So how do I get custom brackets made on demand? Any tank designer must have
the same problem, or at least the design side of that problem even if other
people did the manufacturing.
I could say, look through any non-secret part of a public tank design, and
hope to get lucky with something that meets my needs for, say, putting up a
bookshelf.
"World War II AFV Plans: American Armored Fighting Vehicles"
http://www.amazon.com/World-War-II-AFV-Plans/dp/0811733408 [amazon.com]
But, in practice, a bracket with specific dimensions made out of a specific
material in a specific shape used in a specific tank to hold a specific item
is probably useless to just about anyone else (except by chance). And even
if it was a very good design for a similar circumstance, how would you find
it out of all the other bracket designs out there? And chances are, the
design for some specific things, like a tank, may just not be shared,
anyway, even if, as above, you might find some old designs around to some
degree of detail.
The logical process that goes into creating an appropriate bracket for
holding an item at a particular position might be generalizable to some kind
of "bracket design" software tool. Give it some constraints, and it might
create you some candidate brackets to consider. Possibly it might do this in
an interactive and evolutionary way -- perhaps of like this software (we
wrote) for breeding 3D models of botanical plants, but for brackets? :-)
http://www.kurtz-fernhout.com/PlantStudio/ [kurtz-fernhout.com]
My father like probably most people who are handy with tools and have many
decades of experience making stuff, essentially could do that quickly, maybe
with a bit of paper and pencil work. But not everyone is so fortunate as to
have someone like that around for a time.
There probably is proprietary software already out there that does this,
like in AutoLISP for AutoCAD? But I'd guess that most everyone still goes
through these motions every time:
"Tutorials on Basic Mechanical Design Calculations (part-1) "
http://www.brighthub.com/engineering/mechanical/articles/15234.aspx [brighthub.com]
"Today I will talk about design of a simple �L� shaped bracket, one side of
it is clamped and at the other side it is carrying some amount of load. ..."
But even if there were proprietary software to do this, it doesn't help me
personally much, because I'm not going to pay a bunch of money just to
design one bracket right now. And chances are, the software runs with other
proprietary software I don't have, either.
So, one might see that FOSS bracket software tool as part of an open
"platform" for design. Same for wire routing tools, diagnostic system test
point insert tools, documentation for maintenance generation tools, viewport
design tools, and so on. If someone wants to design a new type of vehicle,
like a SpacePod,
http://code.google.com/p/openvirgle/wiki/SpacePod [google.com]
well, one might hope it might eventually be a lot easier and go a lot faster
using these tools that together make up some kind of open hardware design
platform. And then many of the same tools could be used for, say, creating
book shelves stuck on a wall that have brackets. And there's no reason to
have just the 3D CAD output in a design file. You could have a reference to
the module you used to design a bracket, and the parameters you used, so
anyone getting that design could still easily tweak it a bit at the
parameter level.
From a mass production standpoint, customization of every vehicle is
insanity. Why would a big organization want, say, 1000 vehicles each with
custom parts designed by end users to scratch some specific itch (customized
seats?) that were not interchangeable? Wasn't it a huge leap forward to have
interchangeable parts? Still, if you were 3D printing the parts at a
practically-zero-inventory repair depot that could essentially fix any
vehicle, then what does it matter if parts are custom? Also, if you had, as
discussed recently on the list, a really good recycling system, someday, if
you are really annoyed at a certain vehicle's customization, you just
recycle the whole thing locally and produce a new one. Or, if you have have
a vehicle, adapted by its users in various ways that you want to keep and
bring back into good repair, and you have the CAD files about it, then you
just print the customized broken part. You might also have automatically
generated instructions created directly from the design for troubleshooting,
disassembly, repair, and re-assembly, which a technician could use, perhaps
guided by graphics displayed on reality by a wearable computer with a heads
up display? :-) The repair could even be logged and then fed back into
design software... Thus you have a very adaptive fleet of vehicles... Ones
that are even flexible reconfigurable. A historic example: :-)
http://en.wikipedia.org/wiki/Improvised_vehicle_armour [wikipedia.org]
One key emotional point is that people customizing their equipment probably
will be motivated to understand it better and probably to take better care
of it, because it will be "theirs" in that sense. For a story about a world
of customized products, see:
http://en.wikipedia.org/wiki/The_Mote_in_God%27s_Eye [wikipedia.org]
Or for more on the emotional aspect of humans as makers, see my comments
building on Mark Frauenfelder's:
http://groups.google.com/group/openmanufacturing/msg/70fec0838320517b [google.com]
Of course, to create a good platform allowing mass customization may be a
lot more work (or, at least, different work) than doing specific projects or
creating specific products. Related to this is the notion that it is easy in
software to create a class for an "object" in object-oriented programming.
But to create a generally reusable class to create broadly usable objects
(probably with some parameters specified at creation time) generally takes
many times more work than to just create a specific "class". That's why, in
practice, "reuse" of software has not been as great as expected.
My father, Klaas Fernhout, the bracket maker (among other talents), as a
native Dutch speaker, preferred "Klaas" be pronounced different from
"class", more like the a sound in "hah" (so, customized pronunciation
compared to a typical English speaker?) But both Klaas and a class are
related in this context by being able to make things. :-) So, I want a class
that can do what my father, Klaas, could do as far as generate brackets on
demand to handle all the unique constraints of the moment. Or, more likely,
that might take a set of classes that cooperated while maybe generating sets
of designs that competed, all to help someone do what my father, Klaas,
could do in his head and with scribbling a bit of paper. :-) Granted, I can
expect eventually software tools will do bracket design "better" in some
sense than my father (though perhaps never with as much love. :-)
Now, from a narrowly defined business perspective that's where it ends.
There is essentially no point on any specific project for making reusable
classes, and tools go in and out of fashion, so investment in any platform
is problematical by a specific company (unless you are selling that platform
yourself). Who in their right mind would write a piece of software that
helps people design arbitrary brackets? Unless you were going to sell that
stand-alone program as a proprietary product -- in which case most people
probably can't use it. Or unless some big organization who saw the value of
such tools paid you to do that (and then you promptly abandoned it and went
on to other new grant-funded things, keeping it artificially scarce just in
case you might make a bit more money from it someday).
Related:
http://www.pdfernhout.net/on-funding-digital-public-works.html [pdfernhout.net]
And, likewise, for programs, we get programming methodologies like extreme
programming that design and implement everything just-in-time. And that can
be a very useful approach for a "project" or even a "product" (especially
since figuring out the true "requirements" is often most of what any project
entails). But such an ad-hoc just-in-time approach is more problematical for
a "platform" that needs to support many projects and products. To make a
good platform, you usually have to consider a lot of different cases, to see
what you can generalize from them.
However, from an open source perspective, the above may just be the
beginning, not the end. If a lot of people are engaged in using an open
platform, than it may make sense for people to keep improving different
things so each is generally reusable, with each person or team working on a
different module, and the modules somehow working together as a common
platform used to make products for projects. Someone who cares a lot about
nice looking functional elegant brackets is going to work really hard on a
parametrized bracket design module. Maybe it can't design every bracket, but
it could do a lot of them. This approach might not work well if everything
was proprietary (and also written to assume different data formats), but
this approach might work very well if everything was free and open source.
It might help if such a platform used a common semantic web infrastructure
too, so communications about design discussions (including determining needs
and priorities) could be integrated in with each design. Related Wikipedia
item (and a comment by me):
http://en.wikipedia.org/wiki/Semantic_Web [wikipedia.org]
"Raising the bar to supporting a Social Semantic Desktop"
http://groups.google.com/group/diaspora-dev/msg/8410682ec9ca87ee [google.com]
So, the platform then is really supporting an incremental design "process"
as well as an end-product manufacturing "process". So, maybe we need a
fourth "P" word up at the start, for "process"? :-) And a more
process-oriented view of open manufacturing might link up with efforts like
this at NIST:
"Sustainable and Lifecycle Information-based Manufacturing"
http://www.nist.gov/mel/msid/dpg/slim.cfm [nist.gov]
Eventually, we might end up with "designs" that were even just a collection
of reusable software tools and related parameters, like an electric motor
design tool linked to a bracket design tool, where you could scale the whole
thing to fit some need -- produced within a total lifecycle analysis process.
Now, this is not to say *everything* in a design should be a reusable
software tool to generate specific things. There may well be some categories
of things like brackets, porthole creation, wiring, and so on that relate
more to ad hoc interfacing, whereas some other items (a gyroscope? a CPU?)
might be more carefully designed items that you are connecting into a system
just as they are mass produced. One of the very first 3D CAD software, Ivan
Sutherland's SketchPad, worked in terms of constraints, which are somewhat
similar to parameterized modules.
http://en.wikipedia.org/wiki/Sketchpad [wikipedia.org]
"The main idea was to have master drawings which one could instantiate into
many duplicates. If the user changed the master drawing, all the instances
would change as well. Another major invention in Sketchpad was that it let
the user easily constrain geometric properties in the drawing�for instance,
the length of a line or the angle between two lines could be fixed."
So, any real system would probably be a mix of these things, the fixed and
the variable. And any very generic design that was scalable might well have
both types of definitions and be scalable within some range. So, for
example, you might be able to scale a space probe up and down within some
range until the point where one gyroscope was not powerful enough to orient
the craft at an acceptable rate. At that point, you'd have to revisit the
design to replace that component in the design or make other changes.
(Integrating simulation would help a lot in analysis.) Over time, as 3D
printing improves, more and more of various open hardware designs might be
made generic in this fashion. For example, shoes.
"I just reprapped a left shoe. It cost me 30 pence..."
http://blog.reprap.org/2008/05/shoe.html [reprap.org]
It seems that a big promise of open manufacturing is the flexibility to make
a variety of products to support ad hoc projects or custom fits. But to make
the most of that flexibility may involve creating a different sort of
platform than one supporting a more conventional design process where the
focus is on just one mass-produced product.
And then once you've specified what you want, scaled as you need it and
maybe adjusted for local materials and local processes, then you go ahead
and generate specific CAM files, and have it fabricated (like with SKDB).
Then, when it breaks, you either recycle it or print a custom part again or
even an adapter to hold a different part.
So, the bigger picture on open manufacturing of open hardware is that the
entire design process may eventually change leading to different products
maintained in different ways. And we probably want to be creating
infrastructures for that sort of overall dynamic social design,
manufacturing, performance analysis, and repair process. But, granted, that
big picture may be different than any one specific institution with narrow
objectives may be seeing when it looks at just one part of the open
manufacturing picture.
==
By the way, the license for the ohroadmap Wiki "Creative Commons
Attribution-NonCommercial 3.0 License" is not compatible with Wikipedia.
That may not matter to you, but it is something to consider. Personally, I
find "non-commercial" clauses problematical, because it's never clear what
is commercial and what is not (a teacher getting paid to teach about open
manufacturing seems to me to be commercial, for example). You might ask
yourself if there any particular reason you want that license as opposed to
one that is compatible with Wikipedia?
http://en.wikipedia.org/wiki/Manufacturing [wikipedia.org]
--Paul Fernhout
http://www.pdfernhout.net/ [pdfernhout.net]
====
The biggest challenge of the 21st century is the irony of technologies of
abundance in the hands of those thinking in terms of scarcity.
The biggest challenge of the 21st century: the irony of technologies of abundance used by scarcity-minded people.