Everybody in that issue, except for three,.. were part of our coordinated effort. Two people threw in comments that we had to delete (and if you look closely, are in the history). The third was likely aware, and his several comments supported our ruse, so they remained.
Our various tweets, including the two from @TheASF were (of course) coordinated along with the movement on the issue.
It was about a dozen of us, spanning around 14 hours. Many April Fool's pranks are "fire and forget". Keeping it *live* was our key. Many people, many voices, and many hours.
Apache tried that game for many years. Work *within* the JCP, and as a member of the EC. Apache *has* made many useful changes to the JCP and how it operates. But even with all that, it hasn't produced the JCK without an FOU clause.
At some point, enough is enough. The Apache brand name cannot continue to be associated with a sham.
Exactly. The Apache license provides freedom for developers to work with the code (pretty much) however they wish. It does not provide freedom to end-users (like copyleft/reciprocal licenses do; such as the GPL). HTC and T-Mobile are well within their rights to do something like this. It's uncool, but it is not a violation.
You struck gold on #3. If you don't work at Mozilla Corp, then you have a LONG, HARD road ahead of you to get changes in. Much less an architectural revamp to enhance security and speed.
The concept of Public Domain is actually pretty difficult to do with software. It is kind of hard to "abandon" the fact that you wrote the software which means you will always be liable for it. And you can't attach a disclaimer of warranty because that obviates public domain:-P Throw in that France won't let you disown your copyrighted works, and the whole area about PD software grows real murky. Daniel Berlin could probably be more specific, I just know the rough bits here. This question has also come up on our google-code-hosting@googlegroups.com mailing list; there should be more details there.
In any case, if you want to provide users with lots of rights, then I'd simply recommend going with the Apache License.
That thinking was exactly why I included MPL in the list of licenses on Google Code. It was a mistake though... in practice, nobody uses it (about 2% of projects on Google Code). To further reduce proliferation, I've been thinking about removing it as a choice (and grandfathering existing projects who use it).
This is just stupid. We are not... repeat NOT... creating a new license.
On Google Code, we are taking a stand AGAINST license proliferation -- you can only use one of eight licenses there. And I've been thinking of dropping it to seven (remove MPL). Creating our own license(s) would go completely against our philosophy.
No. The simple answer is that we like to encourage people to use GPLv3 or Apache for their software, depending upon their philosophy. Dropping back to just those two licenses would be ideal. The FLOSS world would be SO much better if there were just a couple licenses because it would radically simplify the use/combination of software.
Holy crap. You really have no idea on how to use Subversion, do you? As the previous poster said... take a little time to learn your tool, rather than blaming the tool. It is *always* a bad idea to check out the root like you're doing. Of *course* it will take several gigs if you also check out all the tags and branches.
You know... we get this every year. Some whiner says "they don't pay well enough." Fine. My thought is always, "do something else with your summer."
Last year, we spent over $3 million on this program. This year, we're increasing that to $4 million. That means 800 students get an introduction to Open Source around the *world*. Your narrow view of life says the pay sucks. I don't think students in India would agree with you. Last year, an eastern European student used the money to start his own business.
Those 800 students are going to have a nice little entry on their resume which will read a lot better than "flipped hamburgers at the local burger stand." These students will get to interact with some of the best Open Source organizations on the planet. And work with mentors who can show them how these communities work. They will produce more code, for the benefit of *everybody*.
It is a fair bet those 800 students will produce more this summer than all the people who complain about the "low pay" will produce in *years*. I'm happy and fortunate to be able to do this, and I know there are thousands who are willing to participate. And I'm happy they will have a great attitude about it.
In the next couple days, I'll be posting a rough summary of some of the things that we looked for this year in the applications. Please watch the google-summer-of-code-discuss mailing list.
The first year, Chris DiBona and I just winged it and picked out about forty projects that we knew. In 2006, a bunch of people emailed us, and we manually picked some. This year, we had a web application to help organize the process, but the selection is still based on a manual review. We had something like 240 applications to sort through(!)
I understand it is disappointing, but we had to pare the list down. A lot of people are asking "why not me?", and students will ask it in a few weeks, too, when their proposal is not accepted. We probably should have come up with some advice beforehand, but this stuff is always a rush. We have a bit on the AdviceforMentors wiki page, but I'll create a whole separate page for organization applications.
Sorry if you weren't selected, but I hope you'll understand that we had to trim the list.
When you come up with a good way to pay minors in 93 different countries, then let me know. Until then, we've had to limit it to adults (i.e. 18 years or older).
Seriously... paying the students and handling the taxes associated with that is one of the most difficult aspects of GSoC. First year was a mess. Last year was better, but far from ideal. This year, we have some ideas for improving further.
Because we didn't know of good, Open Source scientific computing projects and/or they did not send us email to ask to participate.
This year, we have an application process to make it easier for projects that we're not familiar with to apply. If you have some pet projects that you'd like to participate in GSoC, then ask them to apply in a couple weeks when we open it up. It is up to them to apply.
I'm in charge of the site. We will not place any ads on the project pages.
In the future, we may allow project owners to *choose* to display AdSense and then revenue-share the proceeds. This could be an interesting way for projects to generate some funds. But even then, I think we will only place them at the *bottom* of the page so as not to interfere with the overall clean look of the page.
You should know better than to ask. It's hush-hush top secret. Feh. Chris shouldn't have even mentioned it. He's being reprogrammed right now to better follow his Google Overlords' wishes. Too bad. I kinda liked him.
Euh... who is being thick now? That page is about HTTP Headers, not elements you find in the element of an HTML page. Specifically, the Link HTTP header mentioned refers to Section 19.6.2.4 of RFC 2068.
And yeah... it ignored CSS. It's looking at page elements in order to help out the WHAT folks.
Ha! Guido would quit in a heartbeat if you tried to make him manage people. That just isn't where he's at. He's absolutely brilliant and loves to write excellent code. Great. We're gonna let him do just that:-)
In any case: yeah, we hired him because we want him to work on Python itself. And as John says later in this thread -- about half his time.
Oh, quite true. At Google, we use Python, Java, and C++ for all of our work. Python is critical to our development and infrastructure.
I gave a keynote at PyCon last year about the importance of Python at Google. Some people transcribed the talk. You should be able to find it via Google. (heh!)
I think this is the right way to describe it: the engineering/product management group provides lots of options. Management allocates people/machines/resources to the various options. But nothing happens without that initial impetus from engineering.
Case in point: I asked Eric Schmidt about a potential project based on some comments he made at an all-hands meeting. He point-blank told me, "Don't ask me about getting that going, find some coworkers and make it happen. I'm the wrong person to ask."
Projects don't come from the top. It is entirely bottoms-up. And the nice thing is that top-to-bottom agrees this is the best model.
Actually, cable companies do make ESPN pay them for access to their customers. Let's say that ESPN charges all cable companies $1 per subscriber per month. BigCable company comes along and says, "if you want access to my 10 million customers, you have to drop your rate." The rate gets negotiated down to $0.90/sub/month. Thus, the cable company has effectively charged ESPN $0.10/sub/month for access to their customers.
It definitely happens -- access providers use the "if you want access to my users..." card.
Actually, the projects aren't being developed "for us". Students who had ideas that didn't match up well with the organizations requested Google for a sponsor. So "our" projects are actually a pretty eclectic sort.
And remember that it will all be Open Source. The SoC students are developing code for *everybody*.
The counts were not based on the organizations' utility to Google. Most of it is based on popularity, on the capacity of the org, and some feedback from the orgs.
The ASF ended up with the most because it was the second-most popular, and because they have a LOT of people available for mentoring.
GAIM had the most applications, but were unable to mentor all that many.
Assuming that Google gets to approve of both the individuals and the projects they work on as a condition of receiving the money, Google is going to choose projects which are interesting to them.
Google is not choosing the projects, unless somebody requests us to be the sponsor. Proposals that are marked for (say) the Python Software Foundation will go to a group of people there for review and selection. Google has given them full autonomy in project/student selection.
In addition, we have asked for the organizations to propose some ideas, in case the students need a little inspiration.
Slashdot Mirror
Everybody in that issue, except for three, .. were part of our coordinated effort. Two people threw in comments that we had to delete (and if you look closely, are in the history). The third was likely aware, and his several comments supported our ruse, so they remained.
Our various tweets, including the two from @TheASF were (of course) coordinated along with the movement on the issue.
It was about a dozen of us, spanning around 14 hours. Many April Fool's pranks are "fire and forget". Keeping it *live* was our key. Many people, many voices, and many hours.
Hope you enjoyed :-)
Apache tried that game for many years. Work *within* the JCP, and as a member of the EC. Apache *has* made many useful changes to the JCP and how it operates. But even with all that, it hasn't produced the JCK without an FOU clause.
At some point, enough is enough. The Apache brand name cannot continue to be associated with a sham.
Exactly. The Apache license provides freedom for developers to work with the code (pretty much) however they wish. It does not provide freedom to end-users (like copyleft/reciprocal licenses do; such as the GPL). HTC and T-Mobile are well within their rights to do something like this. It's uncool, but it is not a violation.
... Braveheart.
You struck gold on #3. If you don't work at Mozilla Corp, then you have a LONG, HARD road ahead of you to get changes in. Much less an architectural revamp to enhance security and speed.
The concept of Public Domain is actually pretty difficult to do with software. It is kind of hard to "abandon" the fact that you wrote the software which means you will always be liable for it. And you can't attach a disclaimer of warranty because that obviates public domain :-P Throw in that France won't let you disown your copyrighted works, and the whole area about PD software grows real murky. Daniel Berlin could probably be more specific, I just know the rough bits here. This question has also come up on our google-code-hosting@googlegroups.com mailing list; there should be more details there.
In any case, if you want to provide users with lots of rights, then I'd simply recommend going with the Apache License.
That thinking was exactly why I included MPL in the list of licenses on Google Code. It was a mistake though... in practice, nobody uses it (about 2% of projects on Google Code). To further reduce proliferation, I've been thinking about removing it as a choice (and grandfathering existing projects who use it).
About 9% of the projects on Google Code use the "new" BSD, so we're keeping that. No worries :-)
GPLv2, GPLv3, and Apache -licensed projects make up two-thirds of all projects.
This is just stupid. We are not... repeat NOT... creating a new license.
On Google Code, we are taking a stand AGAINST license proliferation -- you can only use one of eight licenses there. And I've been thinking of dropping it to seven (remove MPL). Creating our own license(s) would go completely against our philosophy.
No. The simple answer is that we like to encourage people to use GPLv3 or Apache for their software, depending upon their philosophy. Dropping back to just those two licenses would be ideal. The FLOSS world would be SO much better if there were just a couple licenses because it would radically simplify the use/combination of software.
Sheesh.
Holy crap. You really have no idea on how to use Subversion, do you? As the previous poster said... take a little time to learn your tool, rather than blaming the tool. It is *always* a bad idea to check out the root like you're doing. Of *course* it will take several gigs if you also check out all the tags and branches.
m erge.maint.html#svn.branchmerge.maint.layout
Per project? The book covers that:
http://svnbook.red-bean.com/nightly/en/svn.branch
You know... we get this every year. Some whiner says "they don't pay well enough." Fine. My thought is always, "do something else with your summer."
Last year, we spent over $3 million on this program. This year, we're increasing that to $4 million. That means 800 students get an introduction to Open Source around the *world*. Your narrow view of life says the pay sucks. I don't think students in India would agree with you. Last year, an eastern European student used the money to start his own business.
Those 800 students are going to have a nice little entry on their resume which will read a lot better than "flipped hamburgers at the local burger stand." These students will get to interact with some of the best Open Source organizations on the planet. And work with mentors who can show them how these communities work. They will produce more code, for the benefit of *everybody*.
It is a fair bet those 800 students will produce more this summer than all the people who complain about the "low pay" will produce in *years*. I'm happy and fortunate to be able to do this, and I know there are thousands who are willing to participate. And I'm happy they will have a great attitude about it.
In the next couple days, I'll be posting a rough summary of some of the things that we looked for this year in the applications. Please watch the google-summer-of-code-discuss mailing list.
The first year, Chris DiBona and I just winged it and picked out about forty projects that we knew. In 2006, a bunch of people emailed us, and we manually picked some. This year, we had a web application to help organize the process, but the selection is still based on a manual review. We had something like 240 applications to sort through(!)
I understand it is disappointing, but we had to pare the list down. A lot of people are asking "why not me?", and students will ask it in a few weeks, too, when their proposal is not accepted. We probably should have come up with some advice beforehand, but this stuff is always a rush. We have a bit on the AdviceforMentors wiki page, but I'll create a whole separate page for organization applications.
Sorry if you weren't selected, but I hope you'll understand that we had to trim the list.
When you come up with a good way to pay minors in 93 different countries, then let me know. Until then, we've had to limit it to adults (i.e. 18 years or older).
Seriously... paying the students and handling the taxes associated with that is one of the most difficult aspects of GSoC. First year was a mess. Last year was better, but far from ideal. This year, we have some ideas for improving further.
Because we didn't know of good, Open Source scientific computing projects and/or they did not send us email to ask to participate.
This year, we have an application process to make it easier for projects that we're not familiar with to apply. If you have some pet projects that you'd like to participate in GSoC, then ask them to apply in a couple weeks when we open it up. It is up to them to apply.
I'm in charge of the site. We will not place any ads on the project pages.
In the future, we may allow project owners to *choose* to display AdSense and then revenue-share the proceeds. This could be an interesting way for projects to generate some funds. But even then, I think we will only place them at the *bottom* of the page so as not to interfere with the overall clean look of the page.
http://code.google.com/soc-results.html
You should know better than to ask. It's hush-hush top secret. Feh. Chris shouldn't have even mentioned it. He's being reprogrammed right now to better follow his Google Overlords' wishes. Too bad. I kinda liked him.
Euh... who is being thick now? That page is about HTTP Headers, not elements you find in the element of an HTML page. Specifically, the Link HTTP header mentioned refers to Section 19.6.2.4 of RFC 2068.
And yeah... it ignored CSS. It's looking at page elements in order to help out the WHAT folks.
Ha! Guido would quit in a heartbeat if you tried to make him manage people. That just isn't where he's at. He's absolutely brilliant and loves to write excellent code. Great. We're gonna let him do just that :-)
In any case: yeah, we hired him because we want him to work on Python itself. And as John says later in this thread -- about half his time.
Oh, quite true. At Google, we use Python, Java, and C++ for all of our work. Python is critical to our development and infrastructure.
I gave a keynote at PyCon last year about the importance of Python at Google. Some people transcribed the talk. You should be able to find it via Google. (heh!)
I think this is the right way to describe it: the engineering/product management group provides lots of options. Management allocates people/machines/resources to the various options. But nothing happens without that initial impetus from engineering.
:-)
Case in point: I asked Eric Schmidt about a potential project based on some comments he made at an all-hands meeting. He point-blank told me, "Don't ask me about getting that going, find some coworkers and make it happen. I'm the wrong person to ask."
Projects don't come from the top. It is entirely bottoms-up. And the nice thing is that top-to-bottom agrees this is the best model.
Damn, I love working there
Actually, cable companies do make ESPN pay them for access to their customers. Let's say that ESPN charges all cable companies $1 per subscriber per month. BigCable company comes along and says, "if you want access to my 10 million customers, you have to drop your rate." The rate gets negotiated down to $0.90/sub/month. Thus, the cable company has effectively charged ESPN $0.10/sub/month for access to their customers.
It definitely happens -- access providers use the "if you want access to my users..." card.
Actually, the projects aren't being developed "for us". Students who had ideas that didn't match up well with the organizations requested Google for a sponsor. So "our" projects are actually a pretty eclectic sort.
And remember that it will all be Open Source. The SoC students are developing code for *everybody*.
The counts were not based on the organizations' utility to Google. Most of it is based on popularity, on the capacity of the org, and some feedback from the orgs.
The ASF ended up with the most because it was the second-most popular, and because they have a LOT of people available for mentoring.
GAIM had the most applications, but were unable to mentor all that many.
Assuming that Google gets to approve of both the individuals and the projects they work on as a condition of receiving the money, Google is going to choose projects which are interesting to them.
Google is not choosing the projects, unless somebody requests us to be the sponsor. Proposals that are marked for (say) the Python Software Foundation will go to a group of people there for review and selection. Google has given them full autonomy in project/student selection.
In addition, we have asked for the organizations to propose some ideas, in case the students need a little inspiration.