Is it just me or does anyone else view the timing between these reports and Google I/O a month ago launching Allo a little suspicious?
Alphabet marketing person: "Yeah, it would be good in the timeline if there was a review the month after I/O, to legitimize Allo as one of the major players in the messaging App space."
Intercept editor: "The optics wouldn't be good if it was just a review of one App. We could do a comparison of the 'top ten' Apps."
Alphabet: "Make it the 'top three'."
Intercept: "We would have to have the review about security then, otherwise we couldn't legitimately include Allo."
Gizmodo editor: "We could follow up with articles about the ones excluded, like FB Messenger and Telegram."
I make the analogy between the software dependency tree and the public park.
Hundreds of people use it, and walk their dogs, and clean up after them, but it only takes one dog owner who doesn't to stop you and your kids from rolling around in the grass.
Unless your dependency tree is locked down completely, you're just waiting for the one piece of s**t to ruin it.
And laughing at node while using maven or APT or any other public repo system is hypocrisy.
Michelle Levesque has raised some interesting points, but only a few are applicable to open source software projects.
User interface design. Few open source projects have a user interface; the majority are utilities or libraries where a GUI is superfluous. What she has focused on is the tip of the iceberg that is relevant to casual computer users.
Documentation. This is a valid point, but it is blunted for the same reason. Nine times out of ten, another programmer wants to see working code, i.e. examples, rather than documentation describing how it can be used. The myriad new uses for some obscure functionality can't be anticipated by documentation writers anyway. However, you must crawl before you can run or walk, so an introductory doco is often beneficial, if only as a means of triage to sort out which project has the functionality you want.
Feature-centric development. This too has a grain of truth, but is mostly the result of programing for the self. When you absolutely need a certain feature, and are focused on it, there is only a miniscule chance you will find and fix some other core functionality problem.
Programming for the self. OK, this is an arrow straight to the heart of the matter. Can a collection of self motivated individuals produce something of lasting significance? Would there be a Notre Dame cathedral if everybody just wanted to get out of the rain? I think not. Or at least it stands the same chance as the proverbial million monkeys... To create something that endures takes vision, and few people have that quality. No more or less so in the open source movement than in the proprietary realm.
Religious blindness. I tend to agree with Michelle here, but for a different reason. It's not that open source programmers reject lessons from proprietary software on religious grounds, rather there is no incentive to follow that lead and it is difficult to try.
Most of her argument is based on the assumption that open source is for end users. By definition, the raison d'etre of open source is accessibility to 'source code' and any functionality that is useful to a casual user is a by product.
Slashdot Mirror
Is it just me or does anyone else view the timing between these reports and Google I/O a month ago launching Allo a little suspicious?
Alphabet marketing person: "Yeah, it would be good in the timeline if there was a review the month after I/O, to legitimize Allo as one of the major players in the messaging App space."
Intercept editor: "The optics wouldn't be good if it was just a review of one App. We could do a comparison of the 'top ten' Apps."
Alphabet: "Make it the 'top three'."
Intercept: "We would have to have the review about security then, otherwise we couldn't legitimately include Allo."
Gizmodo editor: "We could follow up with articles about the ones excluded, like FB Messenger and Telegram."
I make the analogy between the software dependency tree and the public park. Hundreds of people use it, and walk their dogs, and clean up after them, but it only takes one dog owner who doesn't to stop you and your kids from rolling around in the grass. Unless your dependency tree is locked down completely, you're just waiting for the one piece of s**t to ruin it. And laughing at node while using maven or APT or any other public repo system is hypocrisy.
I would prefer these to all be integrated together, and surely someone can devise a user interface that would embrace them all.
The previously slashdotted Minty MP3 has an FM transmitter using a MAX260x chip.
Source code from tridge has been posted to FreshMeat. The SourcePuller project is hosted on SourceForge.
- User interface design. Few open source projects have a user interface; the majority are utilities or libraries where a GUI is superfluous. What she has focused on is the tip of the iceberg that is relevant to casual computer users.
- Documentation. This is a valid point, but it is blunted for the same reason. Nine times out of ten, another programmer wants to see working code, i.e. examples, rather than documentation describing how it can be used. The myriad new uses for some obscure functionality can't be anticipated by documentation writers anyway. However, you must crawl before you can run or walk, so an introductory doco is often beneficial, if only as a means of triage to sort out which project has the functionality you want.
- Feature-centric development. This too has a grain of truth, but is mostly the result of programing for the self. When you absolutely need a certain feature, and are focused on it, there is only a miniscule chance you will find and fix some other core functionality problem.
- Programming for the self. OK, this is an arrow straight to the heart of the matter. Can a collection of self motivated individuals produce something of lasting significance? Would there be a Notre Dame cathedral if everybody just wanted to get out of the rain? I think not. Or at least it stands the same chance as the proverbial million monkeys... To create something that endures takes vision, and few people have that quality. No more or less so in the open source movement than in the proprietary realm.
- Religious blindness. I tend to agree with Michelle here, but for a different reason. It's not that open source programmers reject lessons from proprietary software on religious grounds, rather there is no incentive to follow that lead and it is difficult to try.
Most of her argument is based on the assumption that open source is for end users. By definition, the raison d'etre of open source is accessibility to 'source code' and any functionality that is useful to a casual user is a by product.All in all a good article and thought provoker.