[IPython-dev] [IPython-User] The site needs an update... Web team, anyone?

[Brian Granger]

Aaron,

On Sun, Sep 23, 2012 at 8:09 PM, Aaron Meurer <asmeurer at gmail.com> wrote:
> On Sun, Sep 23, 2012 at 7:38 PM, Carl Smith <carl.input at gmail.com> wrote:
>> Hi all
>>
>> I just saw Brian's post and wanted to offer my initial thoughts as the
>> author of nbcloud.
>>
>>> To be part of the ipython universe a subproject must:
>>>
>>> * Be hosted as a github repo under the ipython org.
>>
>> This seems fine. New projects can be developed independently, then
>> move to the ipython org once they're mature enough.
>>
>>> * Be released under a BSD license.
>>
>> Seems fine.
>>
>>> * Not charge users in any way or be funded directly through a for profit entity.
>>
>> This might be problematic. NotebookCloud is designed to work with the
>> user's EC2 machines, but I had considered providing a more integrated
>> offering, where nbcloud would bill users directly and pay Amazon
>> separately. For me, this just wasn't workable, but other projects may
>> need to charge users, even if only to recover some or all of its
>> costs. Web service provision normally costs money, sometimes lots of
>> it. Someone has to pay.
>>
>>> * Ideally, any funding would go through the ipython
>>> foundation/numfocus.  This would allow for profit entities to sponsor
>>> ipython development, but it would allow the foundation to make sure it
>>> was being done in a way that was consistent with the goals of the
>>> project.
>>
>> I'm a fan of sponsorship. If a project had a sponsor that paid the
>> bills, should this prevent it from becoming an official sub-project?
>> It's also unlikely that a company that's willing to do a deal with one
>> project is going to be equally happy to donate to a third party that
>> wont offer anything like the same package.
>>
>>> * Participate in our governance model (although we haven't formalized this).
>>
>> Would this be a requirement, or an open offer?
>
> Wouldn't this have to be a requirement?  By making it a part of the
> IPython organization, you are surrendering the governing rights of the
> project, so to speak.  For example, the admins of the IPython
> organization will be free to give people push access to the
> repository.

Yes.

> Of course, perhaps the governance model can be written so as to give
> the maintainer (i.e., possibly the original author) some higher powers
> over that particular project.  I don't really know what your
> governance model looks like or what you want it to look like, so I
> can't really say much on this point. I'm assuming you have a BDFL
> model with Fernando the BDFL.  If so, maybe the maintainers could be
> like "mini-BDFLs" of their sub-projects.  Or maybe that's a bad idea.

While it is completely informal, we effectively have mini-BDFLs over
parts of the IPython code base.  It is a pretty big code base and it
is tough for any one person to be deeply invested in all of it
(although some of our devs do an amazing job at that!).  But in my
mind, the master BDFL still has final say on everything.  Fernando is
extremely civil and gentle, but there have been times where he has
gone head-to-head with me over things related to the notebook.  I feel
that this is well within his BDFL rights and anytime I sense he is
putting his foot down, I am more than happy to submit (even when we
disagree, I respect him deeply).  But even in the middle of this, I
think that most of us feel like it is the community that drives the
process.  That too is a testament to Fernando's benevolence.

>>
>>> * Have someone who is committed to maintaining the project.
>>
>> This is a difficult thing for an open source developer to commit to
>> long term, but makes perfect sense nonetheless.
>>
>>> * Be approved for inclusion by a vote of the devs who have commit rights.
>>
>> Seems very sensible.
>>
>>> In return, the subproject would get:
>>>
>>> * Possible funding through numfocus/ipython foundation and other grants.
>>
>> This sounds cool, but not if your project is forced to depend on this
>> type of funding exclusively. It discourages commercial involvement and
>> isn't really in keeping with the spirit of BSD licensing, as I
>> understand it.
>>
>>> * Promotion on the ipython website as an official ipython subproject.
>>
>> This'd be cool.
>>
>>> * The participation of the ipython dev team in helping with development.
>>
>> I don't see how this would work. If anyone wanted to send me a patch,
>> they can now. Being an officially recognised sub-project would only
>> make this a little more likely. There's no way IPython can say that,
>> if a project's official, our volunteers will work on it.
>>
>>> * Name recognition from being part of ipython.
>>
>> Sounds good.
>>
>> P.S. As an aside: I'm currently looking to do some stuff with IPython
>> and the NAO robots. This will cost me at least £3,000 up front. I
>> can't personally donate that kind of money to the public good. I'd
>> need a way to earn it back. I think your proposals make a lot of
>> sense, but I can see the financial requirements being too restrictive,
>> possibly making official sub-projects a very cliquey affair.
>>
>> Personally, I'd probably always opt for unofficial status on every
>> project, just because I don't want to agree to something I might
>> regret down the line. It's a lot of restrictions to accept,
>> perpetually, with potentially nothing much in return.
>>
>> Sorry, if this comes across as negative. It's not meant to at all. I
>> just wanted to offer a different perspective on some of these points.
>> Ultimately, the question has nothing to do with whether nbcloud would
>> 'get in' or not, but how IPython wants to go about adopting projects.
>>
>> All the best
>>
>> Carl
>
> So I guess the question to ask is, what is the benefit from being
> "officially supported" by IPython?  I guess it would result in more
> people finding your project, because of all the official links
> (webpage, possibly in the IPython software itself, etc.).  Other than
> that, the only thing I can think of is that if you have code that
> might potentially be useful to include in IPython itself, then you
> would want to include it just to prevent code duplication and
> unnecessary wheel reinvention.  Like you said, if you are already open
> source and on GitHub, then you can receive pull requests. And if
> IPython core devs help out, you can give them push access, so there's
> little difference from the technical point of view.

I agree that the main benefit is mostly marketing.

> Aaron Meurer
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com