[IPython-dev] [IPython-User] The site needs an update... Web team, anyone?
Mon Sep 24 00:38:15 CDT 2012
On Sun, Sep 23, 2012 at 6:38 PM, Carl Smith <firstname.lastname@example.org> 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.
Essentially, what you are talking about is running a business. It
might not be a for-profit business, but it is still a legal business
entity with interests that are outside the ipython project. We are
completely fine if businesses want to develop software based on
ipython and charge users for usage of it. In fact, our choice of the
BSD license is precisely to encourage this type of thing. But, I
don't think we want to tie the open source project to such entities.
The reason is that in the long run, it is likely that there will be
many businesses that offer IPython related services for $. We want to
ensure the open source ipython project remains a neutral playing
ground for such entities. Allowing subprojects that are directly
sponsored by a one particular business would erode that neutrality.
If you want to start to charge users for using notebook cloud and
create a legal entity to manage those revenues and expenses, I think
it should remain completely independent of ipython. That not to say
we don't welcome the development, but it should be separate.
>> * 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
> 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?
Again, the goal is neutrality in situations where there are multiple
independent businesses in the ipython ecosystem. It depends on how
the sponsorship was setup. Let's say that nbviewer grows and we
eventually have more hosting costs. If a company (let's say Enthought
for the sake of argument) wanted to cover those costs, they should
donate to the foundation and run the money through there. That would
be fine. What I don't want to get into is having subprojects that are
essentially commercial products that users pay for and that sponsors
also try to fund through the foundation. That creates too much
entanglement between the open source project and external businesses
that may or may not have goals that line up with the 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?
Even though we don't have a formal governance model, I think it would
need to be required. My rough summary of our governance model is
* Fernando is BDFL - theoretically he has final say on everything.
* In practice, he almost never exercises his right as dictator.
Instead, he acts benevolently by deferring i) to community vote and
ii) to others who are closer to different parts of the code base.
Thus, if you or anyone wanted to contribute a subproject, you would
need to be willing to agree that ultimately Fernando has final say and
that the community would be the primary guide on a daily, practical
>> * 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.
Yes, no one can make long term promises, but that is part of what the
dev team would have to vote on, i.e., do we want this project to be
part of ipython even if the primary maintainer stops contributing.
>> * 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.
The term "commercial involvement" can mean different things here:
* A company like Enthought or Microsoft funding the development of IPython.
* Employees of a particular company contributing to the project.
* A company using IPython as part of their own commercial product.
This is the spirit of the BSD part you mention above.
All of these things have happened many times over the years and we
strongly encourage this type of commercial involvement. The type of
commercial involvement that I am personally not OK with is a
commercial entity or external non-profit trying to run one of their
"for pay" products under the IPython umbrella. I feel that
people/businesses/non-profits who want to build products on top of
ipython that cost users money should do that on their own. There are
also good legal and financial reasons to keep these efforts separate
as well. Please don't misunderstand me - I am happy to see this type
of thing happening, it just needs to be separate.
>> * 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.
I am not quite following you, but it sounds like you need/want to make
money off of notebook cloud. If this is the case, in my mind, you
should just do it separately from ipython. We will support and
encourage you, but I think the constraints of the open source project
will only hinder you.
> 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.
No, this doesn't come across as negative. Part of the challenge here
is to try to foresee the future and come up with guidelines that we
can apply in a consistent manner moving forward. Personally, I think
things like notebook cloud and nbviewer are just the beginning.
Would love to hear what the other core devs think about all of this.
> All the best
> IPython-dev mailing list
Brian E. Granger
Cal Poly State University, San Luis Obispo
email@example.com and firstname.lastname@example.org
More information about the IPython-dev