Talk:Wikimedia Enterprise/Archives/2023

Additional members of the LLC besides the Wikimedia Foundation

The LLC was formed with the Wikimedia Foundation as its Sole Member. However, the Wikimedia, LLC Operating Agreement contains a section on "Additional Members" and "transferee members" of the LLC. It begins as follows:

• 5.1 Additional Members. The Sole Member may admit additional members to the Company.
• 5.2 Transfers. A Member may transfer all or any part of its interest in the Company to an assignee only upon the written consent of the Sole Member.

What does this mean? Andreas JN466 08:34, 23 January 2023 (UTC)

Given the specific concerns you have raised about this clause on WereSpielChequers’ talkpage (here and here), it doesn't seem you are asking for an explanation of this clause’s meaning. Instead, I understand that you are asking for the reason why these clauses are included in the first place.

I have checked and confirmed with WMF Legal that text you have quoted from Section 5 of the Operating Agreement is indeed a “boilerplate clause”. There neither is, nor was, any specific intent behind its inclusion. Rather, it is standard text which many LLCs have. For comparison, searching for the phrase "member may admit additional members" on the Law Insider database produces ~150 separate examples. This is the same way that there is no special meaning behind including section 8.1 of the Operating Agreement, the "integration clause", which states that this document is the complete document. It is just “standard stuff”.

I understand from the comments on the previously-linked talkpage that you are concerned that the WMF could, would, has previously, or intends to, change the ownership of the LLC - and to do so without telling anyone. I should therefore be clear in stating that to change the ownership of the LLC to anything other than being anything wholly-owned by the WMF would be contrary to its raison d’etre and to do so secretly would directly contradict our stated principles (notably that of transparency). The LLC was, is, and will remain, wholly-owned by the Wikimedia Foundation. The sole purpose and benefit of the existence of the LLC as a legal structure is so that it can sign contracts with commercial customers and take the legal responsibility for those promises. That legal clarity is also the sole motivation for being registered in Delaware - It is the legal system that is most established and most well understood by American corporate-law/lawyers. See the Delaware Chancery Court's description: "...widely recognized as the nation's preeminent forum for the determination of disputes involving the internal affairs of the thousands upon thousands of Delaware corporations and other business entities through which a vast amount of the world's commercial affairs is conducted." Also notice that an overwhelming majority of those ~150 operating agreements on Law Insider with this wording are for Delaware corporations.

Given that the Enterprise LLC is wholly-owned by a non-profit (the WMF), the fact of being an LLC (and of that LLC being registered in Delaware) has virtually zero impact from a financial, taxation, corporate transparency, intellectual property, employment, etc. etc. perspective. Furthermore, since the LLC is under the governance/oversight of the Wikimedia Foundation Board of Trustees, any changes to its ownership structure would also need to be recorded in the Board’s meeting minutes.

In order to avoid any future confusion, I am recommending to WMF legal that the next time the aforementioned Operating Agreement is reviewed, that “Section 5: Additional members” be removed entirely. LWyatt (WMF) (talk) 18:13, 24 January 2023 (UTC)

Liam, whether we like it or not, Section 5 is currently a valid and enforceable part of the Operating Agreement. An explanation of what the current text of the Operating Agreement means is a legitimate thing to ask for. Please ask the legal team to supply such an explanation.

In particular, I do not understand what "transferring all or any part of its interest to an assignee" means in practice. Could you or the legal team give a practical example of how this would work? Would it result in profits being shared?

This explanation will inform community discussions elsewhere (including potential Signpost coverage). In this spirit, could the legal team also confirm whether or not the following statements are true or false (and if false, how so):

1. Delaware is one of only four US states allowing a for-profit LLC to have anonymous members, i.e., members whose names are not part of the public record.
2. A Delaware LLC can change or replace its members without this change entering the public record.
3. A member of a Delaware LLC can assign all or part of its interest in the LLC to another individual or entity without this change entering the public record.

Alternatively, just ask the legal team to remove Section 5 right away and upload a new Operating Agreement, stating clearly that the WMF is now, and will always remain, the Sole Member of Wikimedia, LLC, and has not assigned, and will never assign, the whole or any part of its interest in the LLC to anyone else.

If there is no intent to make use of these clauses, and they are indeed only present by accident, then there should be no objection to removing them forthwith. Andreas JN466 20:24, 24 January 2023 (UTC)

I had a look at the Law Insider database you mentioned, Liam. You said there were 150 examples of the phrase "member may admit additional members" in the database. That is true enough (147, to be precise).

Now could I ask you to please search for the phrase "A Member may transfer all or any part of its interest in the Company to an assignee only upon the written consent of the Sole Member"? This is the verbatim wording of paragraph 5.2 on page 7 of 15 of the Wikimedia, LLC Operating Agreement.

I cannot find a single match in the database. The result shown is: Bad News! :( We don't have any results for your search. Even just searching for the final part of the sentence, "assignee only upon the written consent of the Sole Member.", yields zero matches. Do you get a different result?

This means this phrase is not a "boilerplate clause" as you say and/or have been informed.

It is a unique wording, which seems to have been drafted specifically for the Wikimedia, LLC Operating Agreement. --Andreas JN466 01:56, 25 January 2023 (UTC)

A better search may be "member may admit additional members". The main source of this database appears to be the SEC, so I wouldn't be entirely surprised to learn it's not representative of smaller untraded companies. The entire concept of a "sole membership" company admitting new members also sounds slightly contradictory to an EU ear, and such things often have state-specific rules, so it's natural to be confused and it would be useful if WMF's corporate lawyers shared pointers to some specific relevant learning resource.

That said, if you look at pages like transfer of interest of the members, the phrases sound quite standard (either in the positive or in the negative). I don't know about the specific structure being used here but it's quite normal to allow some way to change the company structure without starting from scratch, while making sure that controlling interest in the company can't be changed against the will of (whoever controls) the company.

Whether this allows secretive changes in corporate structure I don't know, but if one wanted to achieve that it would probably be easier to sell or rent everything that the company contains to someone else, a bit like ISC was going to do with .org, no? Nemo 07:13, 25 January 2023 (UTC)

Both Liam and I mentioned above that the phrase "member may admit additional members" is common. Clauses 5.2 and 5.3 are a bit more unusual (as well as the result of some clumsy editing, it seems to me).

I would like to understand why the drafters thought the Agreement should allow the Sole Member (the WMF) to assign all or part of its interest (which presumably includes all or part of the LLC's profits) to some other individual or entity. Andreas JN466 10:45, 25 January 2023 (UTC)

┌─────────────┘
Hi Andreas,
I’m Shaun Spalding from WMF Legal. Liam had spoken to me that you had additional questions, so I thought it may be more helpful to you if I responded directly. I write mostly on behalf of myself – a normal person who recognizes that you have deeply felt concerns -- who would like to help you.

I hope the length of this reply shows that what I'm writing here is not an afterthought or an attempt to appease you. I personally care about you getting what you need to feel comfortable with WMF Legal’s approach. My responses below:

“An explanation of what the current text of the Operating Agreement means is a legitimate thing to ask for.”

The explanation is just as Liam provided it. It is standard language. Liam’s example of the integration clause was good: there are 100+ examples of differently-worded integration clauses in the database he referred to, but they basically all do the same thing from a technical perspective.

One could go through the operating agreement and find many other instances of language that don't necessarily apply to Enterprise's unique circumstances that nonetheless are included because of the realities of efficient drafting. Yes, I understand that these words in particular are troubling to you. But there are lots of other standard clauses that are also in the Operating Agreement that you'd find completely innocuous.

Legal documents tend not to be redrafted from scratch every time they are put together for a variety of reasons. Some reasons may include to save money and time in drafting and to maintain consistency with other standard documents because courts rely on precedent. If a document is basically the same as another one that has already been litigated in the past, then it is easier to predict the outcome if it needs to be interpreted. In addition to saving money and time during the drafting process, efforts like these to maintain standard language (and avoid reinventing the wheel) would also save the Foundation on costs in the unlikely event something is ever subject to dispute.

From other posts and Wikimedia-L emails, I know that you have a great deal of concern for WMF using financial resources well and using staff time efficiently, so I hope you see the point in all of that.

With that background, I can respond to your general questions:

(1) Did Delaware's rules concerning the transfer to or registration of new LLC members have any influence on the decision to incorporate there? No. Delaware was chosen for the reasons given by Liam. It is very much the norm in the United States to incorporate in Delaware.

(2) Would the Foundation attempt to - secretly or otherwise - transfer all or part of its ownership of Wikimedia LLC to some third party? No. That would be wrong, and contrary to our principles and public commitments.

(3) Was Section 5 of the agreement customized to allow or facilitate such a transfer? No. The agreement was prepared by outside counsel and was presumably based on their internal templates. This is very much standard language. It's natural and normal to have a section on transfers and new members in such an agreement.

(4) Would the Foundation be open to removing or changing Section 5? Yes. This would require a vote from the LLC Board and approval from the Foundation, as well as some drafting time. In order to use resources efficiently, we can commit to making this change in the regular course of business.

“Could you or the legal team give a practical example of how this would work?”

Assuming that you're asking a good faith question about a hypothetical situation and not looking for a forgone conclusion, then here’s my best, simplified explanation:

A "member" in the context of an LLC is like an owner. In theory, under this language, a sole member could want to bring on another member. For example, a family pizzeria owned by a husband and wife could trigger this language to make their daughter a “member” (sharing an ownership interest) once their daughter reaches the age of majority. The family might do this if they wanted that daughter to own part of the business while they’re alive (rather than having the ownership descend through their estate after death).

Unfortunately, I can't give you a practical, real world example of how this would be triggered in the context of Enterprise because of all of the things that Liam explained (the principles, the raison d'etre for Enterprise existing, etc.)..

As I was drafting this, I noted another post by user:Levivich who underscores useful points:

A. That the publication of the operating agreement itself is a demonstration of good faith and upholding of the principle of transparency. The operating agreements in the SEC database / Law Insider are required by law since those are U.S. public company disclosures. WMF does it voluntarily because we’d like to be transparent.

B. That the oversight/transparency of the WMF Board of Trustees is much more important than whatever is in this document. However, I note that your response was to try and think of a potential workaround to even that oversight. If you are seeking to identify hypothetical ways for bad-faith actions, then you will always be able to imagine a possible means of doing so.

If there is no intent to make use of these clauses, and they are indeed only present by accident, then there should be no objection to removing them forthwith.

This is not an open issue of any importance that needs to be immediately “corrected.” This is language that will never be triggered.

Liam DID respond forthwith to your concern: he alerted myself and a colleague in Legal that you had made a suggestion to revise this language. The suggestion seemed reasonable since the language is not intended to be used. We noted that this should be addressed if / when the operating agreement is ever updated.

In conclusion, you successfully asked the Foundation to do something, and within 24 hours I am personally giving you the heads up that it is both heard by us and completely non-controversial. Our commitments like the Enterprise principles remain the same. I can also confirm what you asked us to confirm using the exact same words that you requested us to use:

WMF is now, and will always remain, the Sole Member of Wikimedia, LLC, and has not assigned, and will never assign, the whole or any part of its interest in the LLC to anyone else.

As for actually editing the document: it’s important to understand that these documents are not of the kind that get regularly updated in the general course of doing business. This page gives a good list of times when an operating agreement ought to be modified: Out of the bullet points on the page, the only ones that actually apply to Enterprise are (1) If the high-level decision-making and voting processes are changing or (2) If your LLC ceases doing business.

In situation #1, an edit like the kind we’ve already agreed to do to make you more comfortable would be very easy. In situation #2, it wouldn’t matter what the operating agreement looked like because the LLC would be dissolved. So despite the fact that your request to resolve a practical non-issue has been agreed to, it might take a while to happen.

Naturally, you may want to know why we can’t just edit it now just to satisfy you….

upload a new Operating Agreement

Editing a document like this would require us to engage outside (Delaware corporate) counsel to review the document, coordinate with us on the implications of any changes, invoice us, fulfill the invoice, etc. It’s very easy to accumulate outside counsel fees and staff time on something like this.

What we feel like is the much more fiscally responsible strategy is the one that Liam suggested that we agreed to: next time that we need to make edits for any sort of compliance reason (see situations #1 and #2 above), this will be one of the changes we will suggest. This will mean the money spend on the update is used efficiently because we can do several things at once.

I know you may not agree on this strategy since you'd like this to be done immediately, but reasonable minds can differ. I’m not here to change your mind if you feel like this is important to you. My only point here is that we're happy to do it whenever it makes sense to, but it's not a good use of funds to do so right now just because you asked us to.

Let’s assume that you feel so strongly about this that you might argue that “money should be no object in a situation like this.” It still couldn’t be done immediately by just “uploading a document” because changes in formation documents have to be approved by the LLC board, they need to be operationalized by the LLC leadership. For legal purposes, operating agreements can’t just be changed by editing a few lines of text. If they were, that would have made this conversation easy. I would have just edited some text rather than spend two hours drafting this reply.

As a staff member at WMF, I work for every community member. I am trying to work for you by answering your questions to the best of my ability as transparently as possible. But every other community member who I work for needs the things that they are requesting done as well. That’s why if you want to continue this discussion, I'd like to keep any discussion here scoped accordingly and focused on what will make you feel like you have walked away from here with what you need to feel heard on this specific topic (rather than other more general grievances).

“It is a unique wording, which seems to have been drafted specifically for the Wikimedia, LLC Operating Agreement”

I hope that now that I’ve answered your questions here that we can settle that this is not uniquely drafted intentional language to undermine the integrity of Enterprise. It’s difficult to figure out how else to continue the discussion fruitfully if you don’t believe that.

I share your interest in having constructive conversations more often. I only have control and site over the limited amount of things that touch me in the legal department. But I am willing to be transparent about those things as long as you continue engaging with me in good faith. I would not want to waste either of our times. I believe that you care a great deal about the projects and their success.

Finally, reading your posts over the last year, you've also encouraged me to participate more directly on-wiki in the future. So I have also taken some valuable feedback from you that WMF should participate more directly. I can’t control others, but I can take your feedback myself and do what I can to help you and others to get more thorough answers from Legal if there’s still confusion after Liam answers your concerns.

In conclusion:
We can continue this conversation under the assumptions

1. That I am trying to actually answer your questions to the best of my ability.
2. That I think that you are an important part of the community who has put in an enormous amount of work over the years making the projects what they are today, so you deserve that.
3. That I don’t control any of your other grievances with the Foundation except for my limited ability to influence this one.

My only requirement from you is that any response should be directed on getting information that might actually be useful, covering ground that hasn’t already been covered.

I honestly would like to discuss any remaining open points with you. I can’t guarantee that answers will come swiftly. For example, it may take me a week to respond to whatever your reply is. Please don’t see any delay as unwillingness to have a robust discussion with you.

SSpalding (WMF) (talk) 20:00, 25 January 2023 (UTC)

#CalledIt - (well, at a minimum, I'd assumed that this clause was here because external legal had drafted the contract and they were saving themselves a few dollars by duplicating a prior contract/template as a starting point.)

I can't speak for if Andreas likes your response, @SSpalding (WMF): but I, at least, appreciated it (and the speed of . It holds up under a common sense evaluation as well. Beyond that, Legal posts on-wiki tend to actually be somewhat sparse in detail on areas they're either still thinking about or handling in a more coy sense (IP masking comes to mind) - this does not read as either of those. Nosebagbear (talk) 09:36, 30 January 2023 (UTC)

Shaun, I am remiss in not expressing my appreciation for your long reply sooner, other than by thanking you for the edit. But as you say, a slow pace of conversation may be helpful in a case like this. It allows time for reflection, as well as time for keeping up with the day job.

Thanks for coming onto the wiki! I hope you will make many more edits with your account, and enjoy your time spent here.

As I said before, I was surprised that Google could not find any matches for the Section 5 wording, not even for snippets of it, like may transfer all or any part of its interest in the Company to an assignee, other than this talk page.

By playing around with Google, I have since found at least one other LLC operating agreement from 2015 that contains the almost identical phrase A Member may transfer all or any part of its interest in the Company to an assignee only upon the written consent of the Managing Member (Section 4 of that agreement). The entire document has very similar, often identical phrasings and formatting to the Wikimedia, LLC Operating Agreement, and it – or a document very much like it – is very likely to have formed the template from which the Wikimedia, LLC Operating Agreement was adapted (in the case of this quote, by changing Managing Member to Sole Member, even though the resulting sentence didn't really make much sense). I am therefore persuaded that this was a case of an existing text being adapted. (I still do not feel particularly sanguine about this phrase being in the agreement, but I can imagine that I might feel more sanguine about it if our positions were reversed.)

I thank you for your other answers, though I will note that you answered some questions (the numbered ones) I didn't ask, and failed to answer some of the ones I actually did ask.

Three you didn't answer were whether each of the following statements was true or false:

1. Delaware is one of only four US states allowing a for-profit LLC to have anonymous members, i.e., members whose names are not part of the public record.
2. A Delaware LLC can change or replace its members without this change entering the public record.
3. A member of a Delaware LLC can assign all or part of its interest in the LLC to another individual or entity without this change entering the public record.

Unless you tell me otherwise, I will assume those statements are indeed true. I note your assurance, however, that this was not why Delaware was chosen.

I also readily understood the concept of adding a new member to a partnership (your example of a daughter joining her parents' business). What I was interested in understanding was the case of a member "assigning" all or part of their interest. I will assume that if a member assigns x% of their interest to another entity or individual, this means that x% of the company's profits (though not necessarily other member privileges like voting or management rights) will go to them.

I confess that whenever I am faced with a WMF statement my first instinct is to wonder in what way the spokesperson may be covering something up. There are reasons for that.

This said, this conversation doesn't feel like that. I truly appreciate your taking the time, and hope we will have many fruitful conversations in the future. Regards, --Andreas JN466 22:30, 30 January 2023 (UTC)

Thanks for the kind words and starting things off on a good foot. I honestly really appreciate it.

1. Your three questions.

Anonymous members wasn't a topic we researched when setting up the LLC, since our goal was not anonymity, so I don't have the answer to your question. We don't have a Delaware corporate lawyer on staff either. This is what necessitates us to call outside counsel for one-off activities - such as the formation of a wholly-owned LLC.

As a result, I don’t know the answers to these questions. It would not be an appropriate use of WMF resources to hire outside counsel to research a comparative-law topic since it provides no utility for the projects.

One note: You have posted your own research onto this topic on WereSpielChequers’ talkpage (here), where you’ve cited three privately operated websites for those claims - respectively Wyoming LLC Attorney, delawareinc.com, and incnow.com - but as mentioned above, I can’t speculate on their conclusions because that's not anyone on staff's area of specific expertise.

What is absolutely true: I can confirm that Delaware was chosen for its robust precedent and experienced judiciary, not because of any of those reasons you list. Those reasons did not come up in conversation. Just like one might file an entertainment-related dispute in the U.S. in a Federal Court in California because of the massive amount of intellectual property related precedent in that geographic area (Hollywood, Silicon Valley, etc.), it’s generally understood that Delaware is the place with the most legal precedent and experienced judges (hence predictable decisions) relating to corporate law - are located. This makes Delaware a common and cost-effective place for setting up corporate entities in the United States.

2. Fruitful conversations in the future

Again, much appreciated! I can only speak from my own experience (not as a spokesperson for the org). For the things in my orbit, I will be as frank as possible.

One thing that I think we can do a better job about is making it clear when “we can’t say something” due to Legal or ethical reasons. If we make it more clear that we are “not saying something” to protect a user, follow privacy laws, or adhere to attorney-client privilege, then there’s less of a chance that we could be misunderstood or construed as “having something to hide.” Of course, this isn’t bullet proof: I can think of a handful of debates on-Wiki where it could have jeopardized a legitimate legal or ethical position protecting a community member just by saying “anything” about it publicly (think: state actors and the like).

Over the holiday, I literally read every non-technical village pump post on en-Wikipedia and Wikimedia Commons posted in the last 2 years. I did this because my supervisors in Legal have impressed on me the idea that what the community is saying is important. I waited a year to do this because reading posts for 20+ hours (that are not actually part of your job) is really something one can only do on a long holiday 🙂

In doing this, I learned a lot. One thing that struck me was how many times that a better explanation of “why” we can’t comment on something could have answered a lot of questions and saved people a lot of discussion. To give a concrete example here, I explained that to answer your Delaware questions, I’d have to hire someone to do so. Since it’s non-controversial that the language will be changed at some point, it’s not worth the outlay of time and funds. While I don’t know if that would be a satisfactory answer to everyone, at least it’s a specific answer that doesn’t look like I’m just dodging the questions because of what the answers might reveal.

3. Some final opinions, more about my hopes for better dialogue on wiki generally:

I was the Assistant Director of a digital rights organization before starting at WMF. We provided, (amongst other things), free legal services to creators being bullied by large companies with bogus intellectual property demand letters. Imagine for example, a documentary filmmaker who makes an expose about a company and then that company – upset at being publicly criticized – tries to get the documentary taken out of distribution. I’m not a person who simply believes institutions at face value either. I take a lot of pleasure in defending truth against power in the limited ways my career has allowed me to do so.

But there are institutions, which include the WMF that I have been working at as of 2022, that I feel really do care about transparency. When I read the things that staff has posted over the last 2 years on Wiki much of it is completely accurate to my experience. From my perspective, there has been an enormous amount of interest in trying to communicate with the community better and more often.

All of these are opinions. No need to continue any of the threads above. And I’m sure you heartily disagree with some of what’s here, so not trying to persuade you of anything, just giving you an idea of where I stand: at a crossroads that I see is much more hopeful than negative.

I do have an optimistic view about the future of the relationship between WMF and the en-Wiki community because I see people internally trying hard to create systems to strengthen it. We may disagree because we start from different places – you have 15 years of history and I have less than a year and a half. So I realize that I’m not going to convince you that “things are changing” just by saying it. I’ll just have to keep doing my small part to “show” the community things are changing. Take care. – SSpalding (WMF) (talk) 16:21, 1 February 2023 (UTC)

Thanks Shaun, two suggestions on my part that I think would help build bridges or avoid problems. Firstly re investing the endowment, I'd be inclined to put large parts of it into tracker funds. This isn't because I think certain investments are going to perform better than others financially - I am not qualified to give such financial advice. But the community will want a "chinese wall" between any decision about which company we invest the endowment in just as it would want to avoid endorsing any product by advertising it. Tracker funds are a step towards a blind trust in that your investment is spread across the major stocks in a stock exchange, and they tend to have lower charges than managed funds. Secondly re the use of that endowment, at some point the endowment will be big enough that the WMF could give a guarantee that Wikimedia Commons and or WikiSource will be around for the foreseeable future. Such a guarantee would make a real difference to the GLAM community and the Wikipedians involved in that area as we would be able to assure our partners and potential partners in that sector that an image release to us would have a chance of longterm persistence. WereSpielChequers (talk) 17:23, 1 February 2023 (UTC)

Just to jump in here: given that both of these suggestions pertain specifically and only to the Endowment (its investment strategy; and the use to which the funds are put), the best place to make those suggestions is on the talkpage for the Endowment itself. This page is specifically for discussions of the Enterprise project, which has no particular connection to the Endowment (other than that they are both 'revenue diversification' actions of the WMF, of course). LWyatt (WMF) (talk) 17:30, 1 February 2023 (UTC)

Source Code?

The mwwiki page states that the source code for Wikimedia Enterprise is at github.com/wikimedia/OKAPI. However that repo hasn't had any commits since last June, while Phabricator and the updates here suggest that there's been steady progress since then.

I was a bit confused by this, so I looked through the Phab board, and a few of the tickets (eg this one) have links to a GitLab instance at "gitlab.gluzdov.com" which requires login (and the Phab workboard has a status of "Merge Request", which suggests that this is the source of truth).

My questions are:

• why hasn't the linked code repo been updated in 8 months? Is the OKAPI repository still in use?
• is Wikimedia Enterprise open source?
• if so, why is it using a private GitLab instance rather than Gerrit or wikimedia GitHub?

Marksomnian (talk) 00:06, 27 January 2023 (UTC)

Dear Marksomnian thank you for this question and your patience in waiting for a reply.

For reference, Okapi is the original “codename” for the Wikimedia Enterprise API in its early development and yes, the Okapi repo is indeed the Wikimedia Enterprise source code and where the major releases are published. That last was eight months ago but your asking this question now is very serendipitous: it will be updated again in just a few days, in association with the next major release (the published code update will be a slightly delayed version to that which will be 'in-production'). There will be an announcement about the new release’s features on the “diff” blog, the Enterprise “News” page, and on the subsequent quarterly update summary on our MediaWiki page.

At the start, the decision was taken to have the source code published as stable versions – the first being prototypes and then with steady platform upgrades along the way, averaging every six months. There are a few reasons for this - historical and organizational.

The “historical” refers to the fact that the product is being developed from scratch (and in a different coding language) rather than as a branch of existing code, and on independent infrastructure (as documented on the MediaWiki page, subsection “Application Hosting”). For your interest, the choice of that deliberate separation was, in part, as a risk mitigation effort: if the project was unsuccessful, there would not be technical dependencies that had been created needing ‘undoing’ and the existing resources (both engineering staff and infrastructure) would not have been diverted away from their existing responsibilities. Another major reason is that the server load caused by API usage was, and is, expected to be both very heavy and also fluctuate wildly during the initial years - it is not something we wished to “inflict” upon the core Wikimedia architecture until there is predictable stability: in the product; its user-base; and most importantly in its utilization volume (aka “data egress”).

The “organizational” refers to the specific purpose of this code, this product, compared to most (if not all?) other aspects of MediaWiki - this is being built for the express purpose of being useful to very large commercial organizations and their unique infrastructural, legal, and metadata requirements. Unique not just in the sense of unique compared to smaller re-users, but also unique relative to each other: Each has its own mutually incompatible way of dealing with similar problems. As it states in our Principles document there will not be any exclusivity - either by contract or by features - of the API. Thus, we want to ensure that no user (free or paid should) be unintentionally excluded from being able to use a feature. Therefore, it was considered preferable to publish stable code versions and not every step along the way. This ensures that no one builds upon, or has expectations for, code that we ourselves are not yet sure is fit for all purposes. Nevertheless, as you noted, all of the development work itself is tracked as per Wikimedia standard practice publicly and “live” on phabricator. As a side issue, it is also important to note that the “Enterprise API” is entirely scoped for read, not write - which means there are no editorial policy/workflow implications that the community needs to adjust.

The Wikimedia Foundation, for various reasons, is in the process of moving to a publicly hosted Gitlab instance. As part of this transition the Wikimedia Enterprise team is in talks with the Foundation gitlab management team to facilitate moving over the privately held repos to the Foundations servers, and this way all code will be kept in the same servers. Initially we had chosen to go with Gitlab since it provided more dev support and integrations for the “greenfield” project we were starting. With the Wikimedia Foundation moving to Gitlab we would be able to keep those integrations and move our source code.

I acknowledge that this approach described above is non-standard for the Wikimedia technical ecosystem, but hope you can appreciate the reasoning that has gone into it, and the genuine attempts to make it as consistent with movement principles even if it is not consistent with movement practices. Sincerely, LWyatt (WMF) (talk) 20:14, 30 January 2023 (UTC)

Followup: As promised, Stable v1 has just been updated. LWyatt (WMF) (talk) 11:29, 1 February 2023 (UTC)

Why a tarball instead of a tree? If volunteers want to contribute, is there a process in place to use? Δπ (talk) 18:37, 8 February 2023 (UTC)

Dear @Δπ,

We use the programming language Go to generate snapshots, as it has a good native support for tarbal and, as we use gzip compression. That was a simple choice that works well and has proven to be effective in the past.

For volunteer technical contributions: because this software is being built specifically for large commercial organisations’ use, following a roadmap that is determined by their product needs, its development cycle is quite dissimilar to the rest of development in Wikimedia. Consequently we are not structured as a team to triage and respond to code that wasn’t allocated by the engineering manager to a specific employee to write. Nonetheless, the workboard IS available, as per standard wikimedia practice, in order that anyone can see - and comment on - the work is being done.

More generally: Volunteer developer skill is such a valuable but limited resource within the movement, and this is the last place where volunteer energy should be spent - because the primary beneficiary is large commercial organisations. If commercial orgs want to commission a specific feature they should (and are - through this) pay for its development, and not rely on volunteers.

However, if you mean volunteer technical access - then yes! Wikimedians can access the API in various methods/structures, at no cost. Details provided at: Wikimedia_Enterprise#Access.

Sincerely, LWyatt (WMF) (talk) 12:09, 9 February 2023 (UTC)

@LWyatt (WMF): This is pretty alarming to read. By non-standard for the Wikimedia technical ecosystem it seems like you actually mean that it's just proprietary. Is the API running code that has not been publicly published? Legoktm (talk) 06:16, 11 March 2023 (UTC)

Hi Kunal, it was good to see you at the NYC meetup a few months ago!

I tried to give a sufficiently nuanced/detailed answer in the text replying to Marksomnian above - specifically in the two paragraphs named as the “historical” and “organisational” reasons for the current setup - whereby the Enterprise API source code published as stable versions in circa 6 month increments. I acknowledged then, and reiterate now, that the team knows full-well this is not the norm for Wikimedia. Nonetheless I hope you can appreciate the reasoning that has gone into it, and the attempt to make the workflow as consistent with movement principles even if it is not completely consistent with movement practices.

Looking to the next year or two, we expect that the code will become more stable, more ‘stress-tested’, more feature-rich, and with more organisations utilising it for different use-cases. For those reasons, we’ll also be hoping to move the hosting in-house. As those two things progress we could then also increase the frequency (i.e. decrease the latency) of the public stable versions of the code, working towards the goal of matching normal Wikimedia practices. I understand from your initial statement that you disagree with the current procedures, but I hope that with the explanation given you can agree we’re trying to work in good faith as close to the spirit of the standard practice as possible, and working towards an improving it.

Finally, allow me to introduce you to Haroon Shaikh, the team's Senior Engineering Manager. If you've some further questions about this (or another topic) he is best placed to give you a more technically specific answer. LWyatt (WMF) (talk) 20:17, 13 March 2023 (UTC)

Always good to see you as well :)

I think there are two issues here: 1) whether it's okay for Enterprise to develop proprietary source code and 2) whether the broader community should be dependent upon dumps created by proprietary tools.

On the first point, I don't understand how this is consistent with the principles vs practices. Even Wikimedia Enterprise/Principles explicitly says "All software built for and by Wikimedia Enterprise will be F/LOSS". If the source code isn't being released, how is it FLOSS?

To the second point, the broader community is taking advantage of these HTML dumps - on a technical level they're pretty great. I was recently told that WMDE did some analysis using them that, "... would have been painful to impossible with any previous data stream". I've started brainstorming on an idea to make them accessible to everyone (like Quarry). But it's also alarming for me that these dumps, which we are starting to become dependent on are being produced by proprietary tools. That is certainly out of line with movement principles. This is not really an issue for the Enterprise team per se, but if it's not resolved I would expect others to begin working on a truly free re-implementation.

I think the second point reveals a disconnect with the Enterprise POV and my own experience. Specifically you said, "...this is the last place where volunteer energy should be spent - because the primary beneficiary is large commercial organisations". I don't think this is really true, community members are taking advantage of the dumps and because of the lack of ability to submit patches, are probably burning more time and energy in workarounds (e.g. T298436, T331765) than just fixing the code. Legoktm (talk) 19:05, 20 March 2023 (UTC)

FYI Legoktm - This is just to acknowledge receipt of your comment. It might be a few days before I (or a colleague) can post a proper reply, but wanted you to know in the meantime that it has been noted. LWyatt (WMF) (talk) 17:29, 21 March 2023 (UTC)

@LWyatt (WMF) I share Legoktm's concerns here, and await a response. The expectations of the Wikimedia community is that Wikimedia resources, paid for by corporations or otherwise, will be used to create software that is both freely licensed open source (not merely source available, nor freely licensed and unpublished). It would be incredibly disappointing to already see Wikimedia Enterprise fail to live up to Wikimedia Enterprise/Principles. AntiCompositeNumber (talk) 04:32, 28 March 2023 (UTC)

┌────────────────┘
Thank you Legoktm for sharing your concerns with us. I’m Haroon, the manager for the Enterprise Engineering team, Liam asked me to look into your questions. You mentioned your concern on proprietary tools being used to create dumps. As Liam mentioned, the code that is published is stable code, which will not be changing significantly in the upcoming months as part of the development process. The code for the latest features will also be published as the features mature enough and we believe that it will not require us to make big changes. I acknowledge this approach is not as immediately Open Source as everyone would like, but nor would it be correct to classify this as Proprietary.

Now this leads into the question/concern of being able to contribute to the code for use cases that the community is trying to use them for. This poses a different question of whether the changes being proposed by the community, if incorporated/accepted, would be acceptable or potentially cause incompatibility for the primary and intended use-case of the software. The Enterprise team is watching the tickets you mentioned and will respond/make changes if they are compatible with the needs of the primary users of the APIs as well.

This brings us to the comment "...this is the last place where volunteer energy should be spent - because the primary beneficiary is large commercial organisations". If the community is proposing patches that would create a maintenance burden or scope expansion of the software which is contradictory to the intended users of the API, we as the Enterprise team won’t be able to accept them because that would reduce the effectiveness of the software as a whole. This is where the team is spending energy to see how a true FLOSS mechanism can be implemented, while keeping in mind that all proposed changes can not be hosted on our infrastructure. The best solution in that case might be to provide a sandbox where community code could be run to change or provide a secondary output that would be more aligned with the request from the community. How such a sandbox would work/integrate with existing pipelines and provide a secondary output would still need to be figured out.

Pragmatically: Until that functionality would be available, providing open source code immediately will only give you visibility on how the dumps are being created but not be able to contribute back. The community could always fork and run the code on some compute instance but that functionality is already available via our current stable release of the code.

In summary: We see, and work on, requests that are submitted by the community. We track them on our Phab board under the Volunteer request tag: https://phabricator.wikimedia.org/maniphest/query/dCqJONt4cmHn/#R In parallel we will work to find a solution to incorporate community contributions without unintended disruptions of service to our current users. I would also like to offer having a meeting to talk through all of this in detail as well if you would like. If interested, please contact Liam and he can arrange it for us.

Sincerely, HShaikh (WMF) (talk) 17:27, 28 March 2023 (UTC)

Trying to confuse the definitions of "open source" and "proprietary" really isn't helpful here. They already have well understood meanings. If it's not public, it's not open, period. If it's not available under a free license, it's proprietary. As it stands, Wikimedia Enterprise is not living up to the principles it devised.

I honestly don't understand why this is an issue. No one expects that just because code is published it is "stable". Since the concern apparently is ...that no one builds upon, or has expectations for, code that we ourselves are not yet sure is fit for all purposes, just explicitly state that! The current solution of avoiding setting expectations through secrecy is antithetical to open source. (For what it's worth, the MediaWiki Action and REST APIs mark some modules as experimental, and as a result, we don't get complaints by people when they change or go away.)

I don't see value in addressing the rest of your comment that seems to focus on the absolute worst-case scenario (community members demanding incompatible changes be merged when the ticket I linked was about data corruption) until we resolve the more pressing issue. Legoktm (talk) 04:40, 2 April 2023 (UTC)

Dear Legoktm,

We are not “trying to confuse the definitions” here. Several times earlier in this subheading I have acknowledged that the workflow we currently have is not standard but that we’re trying our best to improve it too. Quoting myself: “...increase the frequency (i.e. decrease the latency) of the public stable versions of the code, working towards the goal of matching normal Wikimedia practices” and, “...trying to work in good faith as close to the spirit of the standard practice as possible, and working towards an improving it”.

In other words: Yes, we currently publish our code open source on a stable-version ‘delayed’  basis, but not so delayed [currently approx 6 months] that there would be time for community tools to become dependent upon them. BUT, and more importantly for this conversation, we’re already and actively working on making it formally open source too. Moreover, we’re hoping that will be soon, but can’t promise a specific time (yet).

Regarding the tickets you mentioned, I’ve checked again with Haroon and:

• T298436, this is a scenario where the changes might be not-ideal for our current users.
• T331765, for the potential data corruption ticket. From an open source point of view the code related to the dumps creation is already available in our current Github repository. As mentioned in the ticket, the engineering team are looking into this and probably will have a resolution soon. 

LWyatt (WMF) (talk) 18:28, 3 April 2023 (UTC)

@LWyatt (WMF): I second Legoktm's concerns above. The enterprise project does feel a little bit like a closed-off skunkworks project. The data quality problems have plagued the dumps from the beginning and still haven't been addressed. You're (somewhat understandably) prioritizing paying customers first, but at the same time you're also making it impossible for technically minded volunteers to help out. All we can do is sit and wait and hope that maybe one day some of the paying "enterprise" customers figure out that they're paying for stale data. – Jberkel (talk) 17:12, 11 May 2023 (UTC)

@LWyatt (WMF) Any updates on this? https://github.com/wikimedia/OKAPI hasn't been updated since you made these commitments. Do better. AntiCompositeNumber (talk) 16:28, 12 November 2023 (UTC)

I had a good talk with multiple Enterprise team members at WCNA this past weekend, and they were receptive to my (our) concerns and issues with the lack of compliance with the open source principles the WMF and Enterprise has committed to. Hopefully we'll be seeing another source code dump in the near future and can then address a proper long term solution. Legoktm (talk) 05:40, 15 November 2023 (UTC)

Hello AntiCompositeNumber, I acknowledge our lapse in meeting our commitment and would like to also echo the sentiment from LegoKTM about our intent to work towards a longer term solution, consistent with WMF standard practices. We are sensitive to your concerns and want to move forward in increasing our frequency to publish our source code. The team is working on the next stable-release of code, and is planned to be available early January.

I would also like to update you on the efforts to present a single place for our source code. We have in the past months created a new Github organization and new structure under the name of Wikimedia Enterprise (rather than the previous project name ‘okapi’). This is consistent with our media wiki presence as well and will help us move away from the code-word naming. You can explore more here: https://github.com/wikimedia-enterprise This is where we will be adding SDKs for integrations and moving our code from the OKAPI repo as well. HShaikh (WMF) (talk) 14:51, 15 November 2023 (UTC)

Thanks for the update @HShaikh (WMF), but I have to say this actually seems like a step backwards. Why is Enterprise moving farther away from Wikimedia norms into a separate GitHub organization and not moving onto Wikimedia GitLab? Especially when Enterprise is already using a private GitLab instance...

It seems clear to me that needing to wait 11 months to see new source code is a clear violation of the Enterprise Principles (is there disagreement on this?), so I'd hope that resolving that is an ASAP task. Legoktm (talk) 00:07, 16 November 2023 (UTC)

Hello Legoktm, I would like to thank you for taking the time to chat with Enterprise team members at the WikiconNA and agree that the extended time between stable release versions is neither ideal nor our intent. Nonetheless, recent ‘beta’ software features were publicised, which we hope demonstrates our commitment to show in-development work ‘early rather than complete’ and to demonstrate adherence to principles (especially ‘no exclusive content’ and ‘transparency’). The delay between iterations of stable release is precisely because of a lack of ‘stability’ in that intervening period. We fully intended to make the publishing of the code automated and on a regular cadence.

As for the location of the code, we are not wedded to any particular location. Initially the private gitlab location you referred to was selected after consultation with the WMF team managing gitlab. When the change was being made there were still some things to iron out and thus we chose to do gitlab privately, that way it would be easier to move once all policies and rules are ironed out. The github location was also selected in consultation with the releng team, TCipriani (WMF), considering WMF code lives in Github, gerrit and Gitlab; each due to its own nuances and needing exceptions. We are seeking advice on which/where is the most organisationally-consistent and technically-appropriate place to ‘live’ long term. As part of that we have created a team under the WMF gitlab as well and will try to publish the upcoming release in both places, eventually choosing only one when we publish the plans for a consistent and reliable release timeline. HShaikh (WMF) (talk) 20:36, 17 November 2023 (UTC)

Wherever possible, the technical, legal, and financial activities of the Wikimedia Enterprise project will be built or reported upon publicly. This is pretty clear. Consistency with mission, vision, and values. All activities must be conducted in a manner that is consistent with the Wikimedia Foundation’s overall mission, vision, and values. is also pretty clear in how it relates to m:Wikimedia Foundation Values, including We solve problems better through collaboration. We find joy, belonging, and connection in doing things together. and I share my work early, often, and respond to feedback. AntiCompositeNumber (talk) 22:03, 17 November 2023 (UTC)

My impression is that we need more "Wikimedia" in Wikimedia Enterprise, and for that reason Enterprise should be publishing their code where most Wikimedians are - in Gerrit or the newer Wikimedia GitLab. Take this repository for example, there's no license statement in it, which means it's proprietary code and not actually open source. Had this been in Gerrit/GitLab, I suspect there would've already been a ticket filed in the Software-Licensing Phabricator project by a volunteer about this issue and (hopefully) resolved by now.

I honestly don't understand the desire to be different or diverge from the norm, it's just making this whole process and experience more adversarial than it really should be. I would like to spend my time building things on top of the APIs and dumps provided by Enterprise, and you know, working together to improve the distribution of free content, but instead I'm stuck here, just asking for the bare minimum of freely licensed source code. Legoktm (talk) 07:14, 5 December 2023 (UTC)

Hello @Legoktm, we don't intend to be adversarial and don't want to make this harder than it needs to be. We on the enterprise team agree with your assessment that more "Wikimedia" needs to be in "Wikimedia Enterprise" and we are looking to find what that means. We are consulting with release engineering teams within the Foundation and the legal team to incorporate that into our systems. Based on those we will be publishing to WMF gitlab with mirroring to github as well.

I also appreciate you pointing out the lack of License information in our current github repos and we will correct it going forward. In consulation with the legal team, it is recommended that we move forward with publishing under the same license used by MediaWiki which is GPL. I will note that for Enterprise it is not as straight forward as "be the same as" the Foundation because there are differences within the foundation as well and we are navigating this to what makes most sense for us. E.g. Code is Licences under Apache, MIT or GNU in various repos. There are some code bases that are on Github due to code build scenarios e.g. ios and android repos. and some that have not moved from Gerrit because of test compatibility issues that the foundation team is still working through. We would love to have you build software on what the team has built and apologize for the delays, we are working to have the next stable version available early January. HShaikh (WMF) (talk) 21:57, 6 December 2023 (UTC)

Financial report and product update

Today we published a major update on the Diff blog which contains the promised first year’s financial report, and also a summary of product updates to the API itself.

https://diff.wikimedia.org/2023/02/07/wikimedia-enterprise-financial-report-product-update/
[also available in German]

A public meeting will be hosted by the team in a few days to answer and discuss any questions you might have relating to this announcement. The details of that “office hour” meeting are:

Public meeting on Zoom on Friday, February 10, 19:00 UTC

This will be recorded and the video will be embedded here afterwards.

If you have written questions or comments about the update, please share them here. As described in the blogpost, we consider this report covering the 2022 calendar year to be a “beta” version. We are actively seeking feedback about how its structure, content, and explanations can be improved for the next edition in late 2023, which will cover the 2022-23 fiscal year.

– LWyatt (WMF) (talk) 14:25, 7 February 2023 (UTC)

@LWyatt (WMF) Thank you for publishing the report. The explanation about taxation was interesting. It is great that the costs of operating Wikimedia Enterprise have been covered last year at least in total and that there is a little profit at the of the year. I hope that the revenue will increase a bit or the costs will be lower to make sure the revenue covers the costs. How much was the energy consumption of the used server infrastructure to run Wikimedia Enterprise last year and how many API-Calls have been made. Additional I wish a list of all customers with a comment if they have paid for the services or got it for free. I wish also an overview about the number of API-Calls that have been offered for free. This includes for me Trial-Use, Wikimedia-Project-Internal use and organisations that get the access for free. This information is important to understand if the Wikimedia LLC is profitable. As I have written before I think that a transfer payment from the Wikimedia Foundation to the Wikimedia LLC is necessary to compensate the Use of the Wikimedia Enterprise API-Services free of charge through scenarios except Trial Use. If Wikimedia Enterprise will at least cover the cost there will be more acceptace for it. I think that the revenue should be much lower than the 30 percent of the total revenue of the Wikimedia Foundation defined as maximum. Hogü-456 (talk) 20:10, 7 February 2023 (UTC)

Dear Hogü,

Since there are several related questions in this paragraph, I will attempt to address your questions in approximately the order that you’ve asked them:

"How much was the energy consumption of the used server infrastructure to run Wikimedia Enterprise last year”

This is something that can perhaps be investigated in the context of Sustainability reporting, but it should be noted that - at least for the time being - the Enterprise server infrastructure is via a third party - not owned and operated by the Wikimedia Foundation. The technical documentation is here. The non-technical explanation for that is here. This means that the energy consumption of our service is spread across an existing system (AWS) which is run by a FAR larger organisation than Wikimedia. The data itself isn’t easy to estimate accurately with the information we’re provided by AWS. To do it correctly we’d need to understand the resources that we utilize from their server centers which are notoriously opaque.

“How many API-Calls have been made”, made by free/trial accounts, and “a list of all customers”

I understand that your stated motivation for this question is “...to understand if the Wikimedia LLC is profitable” however, the finance report already provides that information - both on a “month by month” basis and also “since the beginning of the project” basis. The things you’ve mentioned you want to know might satisfy a sense of curiosity, but they would not actually improve anyone’s indirect understanding of profitability - especially since that information is already explicitly in the financial report.

Maintaining a public and comprehensive list of paying and free/frial customers would look like advertising/promotion of those customers, and also introduce a new privacy (and potentially security) problem: i.e. In the same way that it would be inappropriate to make a public list of “all people who have used the Wikidata Query Service this month” (for example) - it goes against our privacy culture. Nonetheless, we do intend to be making “use case” blog posts - which will describe how some users (either general categories or individual cases with their permission) are benefiting from the service in the real-world.

"...a transfer payment from the Wikimedia Foundation to the Wikimedia LLC is necessary to compensate the Use of the Wikimedia Enterprise API-Services free of charge”

I am confused by the request that the Wikimedia Foundation should make a financial donation to the LLC. You state that it is to “compensate the Use of the Wikimedia Enterprise API-Services free of charge” however one of the fundamental purposes of the project is for revenue to flow from the Enterprise service to the WMF, not the other direction. Supporting commercial-users who are investigating/testing the product to see if they wish to use it (via the “trial” service) is part of the business. And making the service available for free to non-commercial organizations who have a mission-relevant use-case (such as what we do with the Internet Archive) is an important way to ensure that anyone can support Wikimedia’s mission with this service.

"...the revenue should be much lower than the 30 percent of the total revenue of the Wikimedia Foundation defined as maximum”

This is the maximum proportion of total revenue - and we are a long way from it being anything other than a hypothetical scenario. Serious conversations about what can, and should, happen if we are approaching that point but that would need to be at the level of the WMF Board of Trustees, not at the level of the staff working on the project itself.

Finally, I hope you will be able to attend the public meeting this Friday, so that we can discuss these questions and topics in greater detail. Sincerely, LWyatt (WMF) (talk) 18:44, 8 February 2023 (UTC)

@LWyatt (WMF) From my point of view at least the list of paying customers should be published and if the contract volume is higher than 2 percent of total revenue of the Wikimedia Foundation the amount the company paid to Wikimedia LLC to use Wikimedia Enterprise should be published. From my point of view granting free access to the Wikimedia Enterprise API for the Internet Archive is a donation. From my point of view such an donation should be if possible valuated. In Schedule I Part II of the Form 990 there is an overview about grants and how much was granted. I want to attend at the Office Hour on Friday and I think it is great that it will happen and will ask some question and hope that there will be discussions. Hogü-456 (talk) 19:16, 8 February 2023 (UTC)

Two financial and one product questions: what is "software amortization", how is "customer service" different than staff and contractors, and are real time page view statistics supported or planned? Δπ (talk) 18:31, 8 February 2023 (UTC)

Dear @Δπ:

The practice of amortisation (aka Depreciation) is described at this [English] Wikipedia article: Amortization_(accounting). Rather than accounting for the value of something all at once, its value is spread over several reporting periods - representing the useful lifespan of that thing.

"Customer support" in the budget refers to the cost of having people available 24/7 for responding to enquiries within the contractually-required timeframe (depending on the 'tier' of how significant the problem might be this can be handled by a customer-support company or might be escalated to someone senior in our own engineering team). That is a whole workflow and process in its own right and involves an external org who specialises in this kind of thing. It is separate from the "staff and contractors" which includes all the people specifically named on the team subheading.

Finally, yes we are thinking into whether more granular pageview data is possible than the current "daily" - not just for the benefit of Enterprise API customers but for everyone. BUT there is a significant privacy risk for readers if that data would become too granular... So, while there are many who would like that feature, it would need to be investigated cautiously and with a readers-privacy-first focus. LWyatt (WMF) (talk) 19:17, 8 February 2023 (UTC)

I guess I meant, what sort of software costs $300,000 per year amortized? Δπ (talk) 06:33, 9 February 2023 (UTC)

Sorry Δπ - I was not clear. The line in the budget that says “Software Amortization - $300k” is not referring to the cost of purchasing copies of external software, but refers to the cost of development of our own software. The relevant quote from the text of the report is: “The amount capitalized for Wikimedia Enterprise was about $1.9 million at the end of 2022, of which $380,000 has been amortized (depreciated) so far since 2021.” [The line in the table says $300k not $380k because it covers only the 2022 calendar year]

The Wikimedia Foundation incurs costs which are eligible for capitalization (expensing the value of an asset over its useful life, rather than all at once). These are primarily personnel expenses and outside professional service costs to develop the Wikimedia Enterprise API software itself.

According to the relevant Accounting Standard [footnote 1 in the report] we are required to capitalize the costs for the application development phase of software development. “Capitalize” means we are not "expensing" these costs as they incur (what we usually do) but instead we spread them out over the useful life of the software (usually 3 years). We remove the applicable costs from the “staffing costs” and “professional services and contractors” line items and, once the software goes into production, we begin expensing these costs over the useful life of the software. When we start doing that, even though they were originally personnel and prof. service costs, we show these costs as “amortization” and not under the original line of “staffing costs” and “professional services and contractors”.

Sincerely, LWyatt (WMF) (talk) 18:14, 9 February 2023 (UTC)

I really appreciate the detailed explanation, but wish this was simpler. Someone had to decide how much of the staffing costs were amortized and how much would not be. I'd prefer all or nothing, but I'm no accountant and can believe there are good reasons. Thanks again. Δπ (talk) 22:54, 10 February 2023 (UTC)

"...but wish this was simpler..." – me too Δπ, me too!

In the last couple of week's I've learned more than I would ever care to learn about American state regulations for financial reporting, taxation, and accountancy standards! The answer above has been provided to me from the WMF Finance team and they are the experts in this matter. They did ask me to ensure that it's clear to anyone reading thi,s that the amortization process described is not a choice but a requirement in accordance with "Accounting Standards Codification (ASC) Subtopic 350-40, Intangibles – Goodwill and Other – Internal Use Software" of the Financial Accounting Standards Board (FASB). -- LWyatt (WMF) (talk) 11:47, 11 February 2023 (UTC)

@LWyatt (WMF): Thanks for this message here. I got curious today after Maryana's update, and spent some time clicking around to find this report. Would it make sense to link the most recent version in the FAQ on enterprise.wikimedia.org ? Maybe I overlooked it though, just thinking about improving findability, thanks! Effeietsanders (talk) 01:50, 14 October 2023 (UTC)

Hi @Effeietsanders,

The Financial report is already linked in the FAQ here Meta. In the subsection "Financial", Under the question "How much money will this raise?", the first sentence is a standalone paragraph and states:

The first financial report is published here. This covers the 2022 calendar-year, which represents the project's first year in business.

The same text is also repeated at the bottom of the "Principles" page (and of course, here in this section of the talkpage).

The FAQ on the project website (enterprise.wikimedia.com, not .org [the explanation for that TLD is also on the FAQ]) is directed at technical issues and customer/user questions (such as "what does this error code mean?" and "what is a namespace and how do I use it?") rather than questions about how the project operates within the organisational/values context of the Wikimedia movement. The "About" page on the .com refers people who have questions about that kind of thing back here, with the following text:

To learn more about how this product relates to the wider Wikimedia ecosystem, please visit our pages on meta.wikimedia.org. That includes FAQ, operating principles, the team, and a community essay.

We've been thinking about making an "Annual Report", incorporating the content of the "financial report" also the updates on the software, team, roadmap etc. etc. If/when we do that extra activity, then it would be sent to customers, published on the WMF website and yes, on the .dom website too.

LWyatt (WMF) (talk) 11:27, 14 October 2023 (UTC)

Customers

Google is still the only paying customer at this time, right? And Internet Archive the only non-paying one? Andreas JN466 09:16, 10 February 2023 (UTC)

As stated in the original press release, Google and the Internet Archive are indeed the first to receive paid and free access (respectively) but we have not publicized the subsequent customers (paid or free) who have signed-up to the service. I responded to a similar question two days ago on this talkpage, so I will copy/paste that text again here for consistency:

Maintaining a public and comprehensive list of paying and free/frial customers would look like advertising/promotion of those customers, and also introduce a new privacy (and potentially security) problem: i.e. In the same way that it would be inappropriate to make a public list of “all people who have used the Wikidata Query Service this month” (for example) - it goes against our privacy culture. Nonetheless, we do intend to be making “use case” blog posts - which will describe how some users (either general categories or individual cases with their permission) are benefiting from the service in the real-world.

No one is required to publish whether, or how, they read/reuse Wikimedia content – this is consistent with that practice. In accordance with The Board’s statement and the relevant item in the project’s Principles, all potential customer contracts valued over $250k p/a are notified to the Board of Trustees in advance, for their consideration. This is consistent with the “Gift Policy” – That way there is the same oversight regardless of whether the WMF receives large payment via a philanthropic grant, a donation/gift, or a contract for an API service. -- LWyatt (WMF) (talk) 16:54, 10 February 2023 (UTC)

What is the situation like these days? Is Google/Alphabet still the major source of income? Can you give a ballpark figure – is it 30, 60 or 90 percent? Andreas JN466 06:40, 5 July 2023 (UTC)

Hello Andreas. The financial situation remains broadly similar since the previous financial report, thanks for asking. as stated in the previous financial report's announcement - "the next edition in late 2023, which will cover the 2022-23 fiscal year." After the first report which covered the calendar year, the intention is for all future Enterprise financial reports to be made in parallel with the WMF's own financial/audit reporting schedule (the July-June financial year). That way everything is reporting at the same time, about the same timeframe, and the accounting-staff don't have to do double the work! Meanwhile, and as with all financial matters (e.g. fundraising), the WMF Board of Trustees is regularly updated. LWyatt (WMF) (talk) 09:24, 5 July 2023 (UTC)

February 2023 Community conversation focusing on the finance report

The public "office hours" conversation video call with project staff, focusing on the Financial report & Product update (as advertised in the subsection above of the same name, and elsewhere) was held yesterday.

The video is available on Commons and is embedded here. The approximate timecode of questions discussed during the meeting were:

• 1' Introductions
• 5' Summary of report
• 10' Financial accounting for free-users
• 25' Ratio of Free/Paid queries on the API
• 27' Meaning of 'optimization' in the software update
• 32' Integration of Wikidata
• 36' Uptime/availability stats
• 42' Future revenue prospects
• 49' Principles of commercial project in a nonprofit movement
• 56' Effect on corporate donations
• 62' API development plan
• 65' Development expectations from customers
• 70' Community considerations in development process
• 75' Editor/reader privacy
• 84' Movement communications in general
• 95' Where has this been discussed before
• 99' Concluding remarks

Some links which were referenced during the call: Product roadmap; WMF Financial reports (Form990); live status and incident history; project principles; OpenFuture.eu blogpost; Where has this been discussed before? FAQ.

Thank you to everyone who participated. -- LWyatt (WMF) (talk) 13:38, 11 February 2023 (UTC)

@LWyatt (WMF), @LBecker (WMF): Thank you for releasing the financial statement and doing the video call. I had a few questions that I don't think have already been asked or answered; I watched some but not all of the video, so apologies if I've missed the answers somewhere:

1. Am I understanding correctly that thru 12/31/22, lifetime income for Enterprise is ~$3.1M and lifetime expenses are ~$4.5M, meaning Enterprise is lifetime ~1.4M in the red?
2. I understand we're roughly breaking even now and expecting (but can't guarantee) to reach monthly profitability by end of (calendar year?) 2023. Do we have a projection for when we will reach lifetime profitability? I'm assuming not by the end of calendar year 2023. Are we thinking calendar year 2024, or is that not realistic?
3. The 21-22 annual plan said the expectation was over $10 million in revenue (I assume annual revenue) for Enterprise. Am I misunderstanding that figure? Is the WMF planning to significantly revise that downward, or is that still the expectation? The reason I ask is that if we're at $3.1M this year, I'm having a hard time imagining how that would triple? Like maybe in 10 years but not this year or next year or the year after that? Or are we indeed expecting 3x revenue growth in the near-term?
4. Will Wikimedia Enterprise LLC release GAAP-compliant financial statements prepared by professional independent auditors (like the WMF's), with the usual statement of activities, balance sheet, statement of cash flows, etc.? If so, when; if not, why not?

I heard Lane say in the video that projections are expected to be released in the coming months as part of the WMF's annual plan, so if the answers to my questions will be available then, I'm happy to wait :-) Thanks! (please ping on reply) Levivich (talk) 19:38, 12 February 2023 (UTC)

Dear Levivich, the answers to your question (in the order that you’ve asked them) are as follows:

1: Yes.

2: Yes. Hard to say with any degree of certainty given that we’re still [obviously] very new and therefore adding a few extra big customers could dramatically change the annual revenue projections. Equally, we’re reluctant to make predictions in writing lest they be understood as promises. Nonetheless, given the track record from the first year of ‘being in business’ your estimate is a reasonable one.

3: The annual plan you reference (21-22) was written during 2020-21, before the Enterprise project itself was barely more than a ‘good idea on paper,’ and so like all estimates they are best-guesses. Having spent the intervening undertaking extensive market research (both in terms of product needs and pricing) and then developing the software itself, the best-guess gets revised. I refer also to the answer to the previous question - with regards to being reluctant to make predictions in writing 🙂

4: I refer to the paragraph in this financial report itself which notes that Enterprise activity is included within the WMF’s own audit report:

As the LLC is wholly owned by the Wikimedia Foundation, all of the financial information presented here will also be included within the Wikimedia Foundation’s audited financial statements and will be in the next Wikimedia Foundation “Form 990” filing as it relates to fiscal year 2021-2022, and future years. There is no equivalent reporting form for a Limited Liability Company (LLC) which is wholly-owned by a nonprofit organization.

It is precisely because the Enterprise information will be part of this larger whole that we have published this report separately. Again, quoting from the report:

One of the principles of the Wikimedia Enterprise project has been “the publication of overall revenue and expenses, differentiated from those of the Wikimedia Foundation in general, at least annually”.

Sincerely, – LWyatt (WMF) (talk) 15:07, 13 February 2023 (UTC)

Thanks for the quick response, LWyatt (WMF)! Levivich (talk) 19:36, 13 February 2023 (UTC)

Any chance of an automated transcript of the meeting? I believe if it's uploaded to YouTube, e.g., the site will generate one automatically. Alternatively, multiple free services are available. Andreas JN466 20:13, 12 February 2023 (UTC)

I have now added a machine-generated transcript + timecode of the meeting to the file’s page on Commons. However, the quality/accuracy of its text is highly variable - especially considering the various technical terms, different people’s accents and microphone quality. In terms of increasing the accessibility of the real-time conversation format: On 26 May 2022 you requested that I "provide a summary here as well" (see the section "How are we doing?") and I have done so, both at the previous meeting and this most recent meeting - with a timecoded listing of the subjects we discussed. Moreover, the recording + timecode summary was published and community notified within a day of the meeting. Also for accessibility to the most-interested audience, I made sure that the report itself was published simultaneously in German and English (which are the two most commonly spoken tongues of the people who comment on this talkpage). I also ensured that people could ask their questions and be understood during the meeting in those two languages (and at least 4 more). I believe that these actions will be of more practical utility in increasing accessibility as I am unconvinced this machine-generated transcript will actually help anyone in their ability to understand what was actually said. Nonetheless, here it is. LWyatt (WMF) (talk) 17:10, 13 February 2023 (UTC)

Thank you very much, Liam. I for one am finding it very useful ... I just prefer reading to listening. With a transcript people can skim half an hour's worth in a few minutes, and there is always the possibility of then going to that point in the video if a passage in the transcript is unclear. So thank you very much for the extra effort! Andreas JN466 22:07, 16 February 2023 (UTC)

Most articles are not available for zh-min-nan

Only 16 thousand articles (less than 5 percent) for Chinese (Min Nan) (zh-min-nan) are available: https://dumps.wikimedia.org/other/enterprise_html/runs/20230201/zh_min_nanwiki-NS0-20230201-ENTERPRISE-HTML.json.tar.gz

Why? (ping @LWyatt (WMF)) Prof.DataScience (talk) 20:58, 12 March 2023 (UTC)

Thanks for noting this, there are multiple possibilities on why this might happen. We'll take a look into this, unfortunately I can't answer the question right away. We are going to double check what's going on and identify the problem. — Stephan Protsack 10:36, 15 March 2023 (UTC)

UPD: similar problem for Amharic (am) Wikipedia: https://dumps.wikimedia.org/other/enterprise_html/runs/20230301/amwiki-NS0-20230301-ENTERPRISE-HTML.json.tar.gz --Prof.DataScience (talk) 15:58, 14 March 2023 (UTC)

Thanks for noting, we have done a large overhaul of or infra recently. I will need to review if it persists in the next run at the end of the month as it will be done using new infra. Protsack.stephan (talk) 12:56, 13 April 2023 (UTC)

There is no enwiki-NS0 in the recent dumps

There is no enwiki-NS0 (as well as frwiki-NS0, dewiki-NS0 etc.) in the recent dumps:

• https://dumps.wikimedia.org/other/enterprise_html/runs/20230420/
• https://dumps.wikimedia.org/other/enterprise_html/runs/20230501/

Why? (ping @LWyatt (WMF)) Prof.DataScience (talk) 16:49, 2 May 2023 (UTC)

There was a problem with mirroring the dumps to https://dumps.wikimedia.org/ during the previous run, after that Dumps Generation team has introduced the fix to the downloader script that makes the mirroring happen. I think the current mirroring download is still in progress. We are going to review and see if it's still the case after it has finished. Protsack.stephan (talk) 19:34, 2 May 2023 (UTC)

What does the "experimental" status of the public Enterprise HTML dumps mean?

Hi, I'm starting a project that will involve repeated processing of HTML wikipedia articles. Using the enterprise dumps seems like it would be much simpler than converting the XML dumps, but I don't know what the "experimental" status really means.

I see in the original announcement post from a year and a half ago that there is a warning about bugs and downtime, but the meta wiki page and dumps site don't have any more information.

Is there less of a commitment to keep posting the enterprise dumps compared to the database XML dumps?

I was referred here from the xmldatadumps mailing list. NewSchmidt (talk) 15:25, 11 May 2023 (UTC)

Hi @NewSchmidt, thanks for the question - it’s actually something we should update at this point. I would say you should absolutely use the HTML dumps for your work, we are fully supporting this work and the experimental tag was a relic of a few years ago when Wikimedia Enterprise was more of an “experiment”. HShaikh (WMF) (talk) 20:16, 15 May 2023 (UTC)

That's great to hear! Thanks for the response. NewSchmidt (talk) 14:22, 16 May 2023 (UTC)

Esperanto (eowiki-NS0) and Aragonese (anwiki-NS0) Wikipedia problem

Many articles are not included in eowiki-NS0 dump in 1 June 2023. This dump file has 997,202,485 bytes. For comparison, eowiki-NS0 dump in 1 April 2023 has 2,333,115,851 bytes.

Another observation:

• anwiki-NS0 dump in 1 April 2023 has 249,198,914 bytes.
• anwiki-NS0 dump in 1 June 2023 has 1,022,666,177 bytes.

Can you correct those (and maybe other) dump files? (ping @LWyatt (WMF)) Prof.DataScience (talk) 16:52, 10 June 2023 (UTC)

I'll pass this information along to the engineering team. Thanks, LWyatt (WMF) (talk) 19:41, 10 June 2023 (UTC)

Thanks for flagging this, we are going to take this into works try to figure out what is the problem here. Protsack.stephan (talk) 09:39, 27 June 2023 (UTC)

Recent beta feature additions

In recent weeks, two new beta features within the Enterprise API suite have been published:

• Breaking news – announced in TechNews 2023/37 and FAQ.
• Structured Contents endpoint – announced in a blogpost and FAQ.

You can read about these features' purpose, technical design, and methods for how to access them at the above links.

In both cases, the intent has been to "releasing early" rather than waiting to perfect more fully-featured tool. This is adherence to the project's Principles (especially of transparency and no exclusive content) and also to request feedback from any community members who wish to test and play with these systems, to give advice on how they might be improved. Both features' have roadmaps for development and areas where user-testing feedback would be of great benefit (see documentation).

If you have questions or ideas for either of these features, please ask them here. Please also tag FNavas-WMF in any questions about Breaking News, and tag SDelbecque-WMF in any questions about Structured Content. LWyatt (WMF) (talk) 11:08, 18 September 2023 (UTC)

Relatedly, the latest quarterly product/technical update was just published on the mediawiki documentation page at: mw:Wikimedia_Enterprise#2023_-_Q3. Sincerely, LWyatt (WMF) (talk) 15:57, 28 September 2023 (UTC)

LLC Operating Agreement update

This is a notification that two straightforward changes to the Operating Agreement which governs Wikimedia Enterprise’s activities have recently been made by the LLC's Board. You can see the new LLC Operating Agreement amendments on Foundation.Wikimedia.org. The previous version (signed March 2021) is also available under the “File History” section on the same page. An explanation of what the LLC is, and how it relates to the Wikimedia Foundation, is given on our FAQ.

Specifically, two sections have been changed:

• Section 2.6 has been updated to limit the LLC from making distributions to any party other than WMF.
• Section 5 has been updated to prohibit the addition of new members (other than WMF) to the LLC and to prohibit the transfer or sale of WMF's interest in the LLC to a third party.

These changes were, in part, a response to a question we received earlier in the year about the wording of Section 5 and whether WMF would ever transfer its interest in the LLC to a third party. During those discussions, we agreed to update Section 5 to formally prohibit such a transfer. The change to Section 2.4 is intended to align with that update, and to help affirm that Wikimedia LLC exists solely for charitable non-profit purposes.

The specific changes are shown here. Changes indicated in green text with strikeouts showing text which has been removed.

...
2.6 Distributions.

(A) The Company may make distributions to the Sole Members from time to time in such amounts as the Sole Member determines.

(B) The Company shall issue no distributions, units, profits interests, or equity compensation to any member other than the Sole Member. All such distributions must be made pro rata to each Member in accordance with its interests as set forth on Schedule 2.2 of this Agreement.

…

5 Additional Members.

5.1 Additional Members. The SoleA Member shall not mayadmit additional members to the Company.

5.2 Transfers. The SoleA Member shall not may transfer all or any part of its interest in the Company to an assignee only upon the written consent of the Sole Member.

’’’Execution of Agreement Required. The admission of an additional member or transferee member under this Section 5 becomes effective when such additional or transferee member consents in writing to be bound by all of the terms and conditions of this Agreement, as amended to accommodate such additional members.

…

Sincerely, SSpalding (WMF) (talk) 18:33, 27 October 2023 (UTC)

Updated financial info within WMF Audit report

Yesterday the WMF Finance department published the WMF fiscal year 2022-2023 audit report. While Enterprise finances are not the primary focus, they do appear within it - notably to state that revenue increased to $3.2M (from $1.6M in FY 2021-22). In the audit report itself it referred to by the project's legal name "Wikimedia LLC" on page 10 section 1(n). In the associated FAQ here on meta, there is also a description under the "What's new this year?" section.

NOTE: When compared to first financial report of Wikimedia Enterprise itself (which covered the first period of its operation - the calendar year 2022), this Audit report covers the financial year 2021-22. Thus, there is a 50% overlap in the time-periods covered which means that the data are not directly comparable - since half of it appears in both reports.

Furthermore, the structure and content of the Audit report is dictated by American regulatory requirements and fiscal reporting standards. Therefore, now that the formal WMF Audit process is completed, the WMF Finance team intend to make an extra report just for the Enterprise data, covering the 2021-22 fiscal year and with the more expansive level of financial detail that was covered in the project's first financial report. This will be published in January. From then on, with the reporting periods 'in sync', the intention is to then report both WMF and Enterprise finances at the same time from that year onwards.

LWyatt (WMF) (talk) 11:33, 10 November 2023 (UTC)

Hello @LWyatt (WMF),

this is great if there will be a extra report regarding Wikimedia LLC. I read the audit report and I plan to read the report about Wikimedia Enterprise published in January. Hogü-456 (talk) 21:08, 14 November 2023 (UTC)

Followup Hogü-456 - the 2022-23 financial report is now published. See: Talk:Wikimedia_Enterprise#2022-23_financial_report. LWyatt (WMF) (talk) 21:10, 10 January 2024 (UTC)