I think the real problem, as unpopular as it is to discuss, is people. People want to do certain things, behave in certain ways. When you have a F/OSS group, you can’t force people to behave in particular ways because they always have the option to go join a group that lets them do what they want. This could be true for code style, revision control, unit tests, when/how often releases should happen, etc. Almost every aspect has groups on both sides for what and how things should happen. I believe that until you figure out a way to solve the human problems, adding/creating/changing tools won’t make any real difference.
> On Jul 12, 2015, at 2:37 PM, Keith Lofstrom <[email protected]> wrote: > > Firefox, Flash, Gnome ... > > It seems that F/OSS development is migrating away from stability > and towards inept and self-indulgent experimentation. > > Traditionally, F/OSS development is a way to develop skills and > demonstrate competence - which is a path to "A Real Job". When > competence actually earns a job (and a family, and a house, and > aging parents, and ...) there is no longer time for major > participation in F/OSS, and the boring but necessary tracking > down of security flaws and functional bugs. > > ( note: boring == not properly automated ) > > So we are left with the less employable developers, and those > participating in order to Try Glitzy New Stuff as opposed to those > interested in bullet-proof bug-free iterations of old-but-complete > functionality. Meanwhile, many of us users would like a platform > that worked the same way forever (without the bugs, and with drivers > for new hardware), so we can build our own elaborations on top. > I want software bedrock for my own intellectual skyscrapers, > I do not want to be a temporary visitor in someone else's. > > If we must make transitions (say from 32 to 64 bits) we want our > old stuff to remain working, and new 64 bit tools to retain all > the legacy capabilities of the 32 bit tools. Most of us have > plenty of other Real World change to cope with. We want to use > the tools we already have to help us with that Real World. If > I have a bit of wonky but usable code from 1990, I want to keep > using it in 2015 or 2025, perhaps emulated in a secure container. > > Richard Stallman natters about software's Four Freedoms, but as > the trite saying goes, "freedom isn't free". When I've argued > with him (is there any other way to interact with this guy?), > he seems oblivious to the fact that the freedoms he demands are > purchased by supporting the equally valid (and different) > freedoms of those who have come to depend on the software he > and his allies have developed. If user freedoms are ignored, > then "free" software becomes too expensive to use, and is > regretfully abandoned. Stallman and his posse then must > find Real Jobs, possibly involving sinks and dishes. > > It does not have to be this way. Stallman can have Four > Freedoms (or five or six or twenty) if he helps create freedoms > for others. Creating freedom can be a lot more efficient with > adequate attention to efficient and robust production tools. > This is where F/OSS can really shine. Give us control of the > tools, and we shape what is made from them. > > A small device like an iPhone goes through thousands of tests > during assembly. It is made from components that go through > hundreds of thousands of tests on their way from candidate > geological ore body to reliable subcomponent. All those steps > are hyperautomated, not touched by human hands. This results in > an iPhone sells for hundreds rather than millions of dollars. > The electronics industry, and the materials and equipment > industries that feed it, are a vast assembly of automated > procedures and billions of lines of code, with well defined > interfaces, transforming the messy cacaphony of raw nature > and human personality into discrete and predictable products. > > Meanwhile, almost all software, libre or proprietary, suffers > from way too many flaws, and way too few tools and techniques > to prevent or detect and repair those flaws. So software > breaks, and we expend vast effort working around the flaws > until somebody is motivated to fix it with quite primitive > software diagnosis, development, and repair tools. Which > AFAIK, still mostly consists of eyeballs and human experience. > > So, I should not call for chastizing sloppy, inept developers > and their ideological leaders, as emotionally tempting as > that is. Instead, let's treat this as an engineering and > automation problem. What tools can we create to take human > weakness out of the development loop, what systems can we > create to automate the production and testing of software? > How can we multiply eyeballs with algorithms? > > What certifications can we create for software that show > ordinary software consumers that these tools and systems have > been used properly? How do we evolve the certifications so > that the inevitable sociopathic manipulators cannot game > the system to produce crap with high quality metrics? > > A new generation of F/OSS, built on trustworthy measures of > quality and "repairability", with tools that guide mediocre > developers towards exceptional productivity, could obliterate > the bad old ways, and generate a rich and unbounded software > ecosystem with products and projects for everyone. > > We already have the historical record of physical engineering > to build on. Causal chains extend from the latest Intel > processor to the mechanical geniuses of the late 18th century. > We do not have nearly as much to invent. We have many more > capable brains to harness and invent with. Indeed, software > capable of evolving into precision tools for software creation > and measurement probably already exists, which is why I write > about this on the PLUG list rather than PLUG-talk. This > mailing list is probably large enough to become the nucleus of > software producers and testers that conquer the software world. > > I am a mediocre coder, a marginal machine builder, and an adept > silicon designer - I have helped chip designs evolve from tens > to tens of billions of transistors, and elaborated tools and > procedures necessary to make that happen. If there are young > and ambitious software engineers who want to see their personal > software creativity expand by similar factors over their career, > lets discuss this and see what processes we can adapt from > hardware and silicon engineering. Next, world domination! > > Keith > > -- > Keith Lofstrom [email protected] > _______________________________________________ > PLUG mailing list > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug -- Louis Kowolowski [email protected] <mailto:[email protected]> Cryptomonkeys: http://www.cryptomonkeys.com/ <http://www.cryptomonkeys.com/> Making life more interesting for people since 1977 _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
