Commits

Maciej Fijalkowski committed 2ab8424 Draft

(fijal, confluency) more english

Comments (0)

Files changed (1)

blog/open-source.rst

 **DISCLAIMER:** This post is incredibly self-serving. It only makes sense
 if you believe that open source is a cost-effective way of building software
 and if you believe my contributions to the PyPy project are beneficial to the
-ecosystem as a whole. If you would rather want me to go and "get a real job",
+ecosystem as a whole. If you would prefer me to go and "get a real job",
 you may as well stop reading here.
 
 There is a lot of evidence that startup creation costs are plummeting. 
 to support that -- but because I'm an open source platform provider working
 on PyPy.
 
-Open source is cost-efficient. As `alex points it out`_, PyPy is operating on
+Open source is cost-efficient. As `Alex points out`_, PyPy is operating on
 a fraction of the funds and manpower that Google is putting into V8 or Mozilla
-into {Trace,Jaeger,Spider}monkey, yet you can list all three projects in
+into {Trace,Jaeger,Spider}Monkey, yet you can list all three projects in
 the same sentence without hesitation. You would call them "optimizing dynamic
 language VMs". The same can be said about projects like GCC.
 
 Let me step back a bit and explain what do I do for a living. I `work on NumPy`_,
 which has managed to generate slightly above $40,000 in donations so far. I do
 consulting about optimization under PyPy. I look for other jobs and do random
-stuff. I think this is relatively lucky, considering that I live in a
+stuff. I think I've been relatively lucky. Considering that I live in a
 `relatively cheap place`_, I can dedicate roughly
-half of my time working on other pieces of PyPy, without too much trouble.
+half of my time to other pieces of PyPy without too much trouble.
 That includes stuff that
 noone else cares about, like `performance tools`_, buildbot maintenance,
-release management, `making json faster`_ etc., etc.
+release management, `making json faster`_ etc., etc..
 
-Now, the main problems for me with regards to this lifestyle is that you can
+Now, the main problem for me with regards to this lifestyle is that you can
 only gather donations for "large" and "sellable" projects. How many people
 would actually donate to "reviews, documentation and random small performance
 improvements"? The other part is that predicting what will happen in the near
 PyPy or will I need to find a "real job" at some point?
 
 I believe we can come up with a solution that both creates a reasonable
-economy that makes creating open source a viable job and comes with
-relatively low overheads. `gittip`_ and `Kickstarter`_ are recent additions
+economy that makes working on open source a viable job and comes with
+relatively low overheads. `Gittip`_ and `Kickstarter`_ are recent additions
 to the table and I think both fit very well into some niches, although not
 particularly the one I'm talking about.
 
-I might not have the solution, however I do have a few postulates about such
+I might not have the solution, but I do have a few postulates about such
 an economical model:
 
-* It cannot be project based (like kickstarter), it's in my opinion much
-  more efficient to just tell individuals "do what you want". In other words
+* It cannot be project-based (like kickstarter), in my opinion, it's much
+  more efficient just to tell individuals "do what you want". In other words
   -- no strings attached. It would be quite a lot of admin to deliver
-  each simple feature as a kickstarter project.
+  each simple feature as a kickstarter project. This can be more in the shades
+  of gray "do stuff on PyPy" is for example a possible project that's vague
+  enough to make sense.
 
 * It must be democratic -- I don't think a government agency or any sort
   of intermediate panel should decide.
 
 * It should be possible for both corporations and individuals to donate.
-  This is probably the major shortcoming of gittip.
+  This is probably the major shortcoming of Gittip.
 
-* There should be a cap, so we don't end up with hollywoodish system where
-  the privilaged few make lots of money while everyone is struggling.
-  Personally, I would like to have a cap,
+* There should be a cap, so we don't end up with a Hollywood-ish system where
+  the privileged few make lots of money while everyone is struggling.
+  Personally, I would like to have a cap
   even before we achieve this sort of amount, at (say) 2/3 of what you could
   earn at a large company.
 
-* It might sound silly, but the can't be a requirement that a receipent must
-  reside in the U.S. Might sound selfish, but this completely rules out
+* It might sound silly, but there can't be a requirement that a receipent must
+  reside in the U.S. It might sound selfish, but this completely rules out
   Kickstarter for me.
 
 The problem is that I don't really have any good solution -- can we make
-startups sign up 5% of their future exit for funding individuals who
-work on open source with no strings attached? I heavily doubt so. Can we
-make VCs fund such work? Potential benefits are far beyond their event horizon
+startups donate 5% of their future exit to fund individuals who
+work on open source with no strings attached? I heavily doubt it. Can we
+make VCs fund such work? The potential benefits are far beyond their event horizon,
 I fear. Can we make individuals donate enough money? I doubt it, but I would
 love to be proven wrong.
 
-Leaving more questions than answers,
+Yours, leaving more questions than answers,
 fijal
 
 .. _`work on NumPy`: http://pypy.org/numydonate.html
 .. _`relatively cheap place`: http://en.wikipedia.org/wiki/Cape_Town
-.. _`alex points is out`: http://alexgaynor.net/2012/jul/04/why-personal-funding/
-.. _`gittip`: https://www.gittip.com/
+.. _`Alex points out`: http://alexgaynor.net/2012/jul/04/why-personal-funding/
+.. _`Gittip`: https://www.gittip.com/
 .. _`Kickstarter`: http://www.kickstarter.com/
 .. _`performance tools`: https://bitbucket.org/pypy/jitviewer/
 .. _`making json faster`: http://morepypy.blogspot.com/2011/10/speeding-up-json-encoding-in-pypy.html