Weekly Edition
Return to the Development page
| |||||||||||||
Quotes of the week
We need t-shirts with "I am a user too!"
-- Arjan
van de Ven (in the comments)
Frankly, and GNOME is by far not the only one suffering from this, a project like this SHOULD have "open source contributor" as one of their prime audiences (note that I say "contributor" not "developer"). These contributors, like you and me, are the folks that will write bugreports in diff -u form. Heck we're the folks that conquer your bugzilla and FILE the bug in the first place. We're the folks that give you the translations you want. We're the folks who very vocally tell you what is wrong (and sometimes we even tell you what is right) with your software. We're the folks who advocate your software to our tech-noob friends. We're the folks that look at your code sometimes, to find security issues and tell you nicely about it before we go public. We're the folks who form the pool out of which you're going to be fishing your next developer set. We are the 99%^Wone percent, I will grant you that. But we are the one percent you as project NEED to get better in the long term, we are the one percent that your project needs to survive.
It is my belief that we are, right now, in the middle of a very
large evolution in the ecology of open source. The language of
contribution has infected a new generation of open source
contributors. Much of the potential first imagined by open source
pioneers is being realized by high school kids on a daily basis who
contribute effectively with less effort than has ever been
required.
-- Mikeal RogersThe reason I am so convinced of the importance of this change is so simple it took me nearly a year to identify it. While the ethos of Apache may have been "Community over Code" it required those in the community to understand and internalize that ethos for it to be fully realized. Social problems became political problems because the ethos had to be enforced by the institution. The new era, the "GitHub Era", requires no such internalization of ethos. People and their contributions are as transparent as we can imagine and the direct connection of these people to each other turn social problems back in to social problems rather than political problems. The barrier to getting a contribution somewhere meaningful has become entirely social, in other words it is now the responsibility of the community, whether that community is 2 or 2000 people. (Log in to post comments)
Quotes of the week Posted Nov 24, 2011 1:49 UTC (Thu) by daglwn (subscriber, #65432) [Link]
Mikeal is hitting on something important but he dances around it a bit.
git, by its nature, forces ceding of control. Because it is so easy to fork projects, project leaders don't have as many tools to limit development or restrict ideas.
git is a tool to implement the bazaar.
This can be both good and bad. Good in the sense that experimentation is allowed, even if not encouraged by the project's culture. Bad in that it also limits the ability of project members to ensure quality.
In my experience, there is more good than bad. People generally act with good intentions and forks only happen over irreconcilable differences. Developers are generally open to code review and quality feedback and want to produce a good product. Forks, if they happen, are more likely than not to be of the "linux staging" variety where various trees containing various features pop up and folks are free to pick and choose what they want if necessary.
"But that's crazy!" some will say, "The software won't be stable if everyone is picking bits and pieces." That's true in the current environment in which we operate. Things like bullet-proof build systems, continuous mandatory testing, defensive programming and other QA activities will have to become more robust and ubiquitous. We've already started down that road a bit with time-based released and continuous rolling releases. This is a good thing. It will make our software more robust.
Imagine if git had been around for the emacs/xemacs fork. Imagine that both projects still exist but are able to share contributions and ideas using a tool designed to do exactly that. Of course software architecture changes will necessarily present barriers but I think git and distributed SCM in general can help us think of a fork not as a "fork" but quite literally as a branch that may or may not be merged someday.
"Fork" is no longer a dirty word in this environment. It's a major shift in social constructs and thus it takes time for those invested in the current constructs to get comfortable with it. But Mikeal is absolutely right that the younger generation has already made the switch and us old dinosaurs are going to get left behind unless we give up some of our preconceived notions.
Quotes of the week Posted Nov 24, 2011 11:40 UTC (Thu) by dgm (subscriber, #49227) [Link]
You almost got it. It's not that git facilitates forks, for that you only need a tarball of the code. It's that it facilitates _merges_. That's the killer feature of git, IMHO.
Quotes of the week Posted Nov 24, 2011 17:21 UTC (Thu) by daglwn (subscriber, #65432) [Link]
git facilitates forks because it makes merges easy. So it really does both and that's its killer feature.
What Mikeal is running into is the social upheaval such a model causes. It forces projects from a cathedral to a bazaar operation. That makes people uncomfortable. Not because they're bad people or have some nefarious agenda, but just because it's a fundamental change and it's scary.
Quotes of the week Posted Dec 24, 2011 0:57 UTC (Sat) by steffen780 (guest, #68142) [Link]
This is the kind of comment that makes LWN not just high quality, but truly special - thanks :)
Quotes of the week Posted Nov 24, 2011 14:39 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
The 99% referred to are presumably the group of (potential) users who never voice their opinions. Of course it is an interesting idea to aim at the portion of the user base who's needs and preferences you can only guess because they don't actually tell you.
Quotes of the week Posted Dec 2, 2011 9:56 UTC (Fri) by robbe (guest, #16131) [Link]
> Of course it is an interesting idea to aim at the portion of the user base
> who's needs and preferences you can only guess because they don't actually > tell you. Isn't that the textbook definition of marketing?
For any product sold more than a hundred times it holds that most of its consumers will not give you feedback. You have to seek it out and go from statistical samples.
... or invest you marketing budget into making your consumers want what you produce. The standard example being Swatch.
|
|||||||||||||