So far the generations of static site generators have been:

1. 1990s — static sites were generated by humans, written by hand, editing HTML directly in tools like frontpage, dreamweaver and notepad
2. 2000s — static sites were generated through desktop applications, where the end-user edited their website via a desktop app, and unbeknown to the user the application would update an internal database, maintain the files, and upload them to the server
3. 2010s — static site were generated through file system compilers, these focused on developer power, with features like file system as the database, and markdown support, early prominent examples include Jekyll for Ruby and DocPad for Node.js

I see a new generation emerging, containing the following interdependent ecosystem parts:

• External Database: content is stored in a modern database system that supports realtime publish/subscribe, such as couchdb and rethinkdb
• Importing: content is imported into the database from any location, such as a computer’s file system, a medium blog, a Wordpress blog
• Rendering: content is exported from the database to any location, such as a static site generator to generate a static website, or to a comment javascript widget
• API Extensions: content is updated in the database using rich API extensions that wrap/extend the database, such as a Zapier or IFTTT extensions that tweet new posts automatically, or SDKs for different languages, or an API extension that allows native comment interfaces to read and add comments to blog posts, or even an extension to provide a Wordpress compatible API hook their desktop interface Calypso up to the database.
• Native Interfaces: content is exposed from the database with interfaces optimised for particular tasks, want a Wordpress/Calypso style interface, want a Medium style interface, want a Tumblr style interface, or a custom interface for your particular client? These interfaces can be built ontop of the API extensions as an alternative to importing content from existing systems.

So what’s the problems with today’s static site generators?

• Todays SSGs use an in-memory database or their own external database system, both of which are designed only for their static site generator, and are not extensible as an open eco-system
• Todays SSGs load, render, and forget on each run, with large static sites taking minutes to generate accurately (change the title of a page that is references in the menu that is used on every page should update every page), realtime changes are not possible with this current system
• Todays SSGs require complex workarounds for anyone but developers to edit then publish the content; web design firm clients may be forced to edit content locally then send to the developer to update, or the developer sets up a workflow on the clients machine, or tells the client to use some special webservice like Prose.io, all of which are inferior compared to what that Wordpress admin interface they are use to — plus when they click save, they must wait minutes to see the final result of each change locally, and even longer to see each change eventually propagate to the live website, all unacceptable to the majority of clients — plus in some systems, clients could break things as they may now edit content or template files that they are not familiar with

The proposed 2017 generation of SSGs will solve this by:

• Importers will be able to allow clients to use the multitude of services they already use, such as Medium, Wordpress, Twitter, Tumblr, Instagram, and for developers the file system, and import that plethora of content into the modern database speedily
• The modern database will readily provide access to the latest direct content and imported content, across the interwebs rather than just a local machine, so that a team can work on the same content, including updating and exporting it
• Exporters will allow for realtime changes to be rendered to all needed destinations, with only the needed changes being rendered and propagated and deployed, rather than the entire static website — reducing minutes to seconds
• API Extensions will allow interactivity with these static sites through pragmatic developer tools or even ideal Native Interfaces for particular clients, allowing dynamic extensible experiences, at little cost

Why hasn’t this occurred yet?

• Today’s SSGs chose in-memory databases due to the complex setup of powerful database systems at the time, however in 2017 powerful database systems are a lot easier to setup, often with one click installers and even as bundled dependencies as part of a applications or SSGs
• Today’s SSGs were intended for the hobbyist programmer, with the value to clients being an afterthought, as such the workflow for clients is incredibly complex, and things like editing and previewing production changes is just too complicated to be worthwhile — now with hindsight we can rearchitect the SSG to meet all needs, with different importers covering file system use cases for developers and external content services for clients
• Today’s SSGs are competitive rather than collaborative because at the time, no one else was doing it, so they could be independent — however now there are over 400 static site generators — and this competition is causing duplicate effort — how many markdown rendering plugins do we really need? — instead importers can be written to import in popular SSG source content to migrate from them, and exporters can be written to export to popular SSG source content to render with them, as interim solutions

Is anyone already doing this?

• Contentful is the main player with their coupled system of Database + API + Interface, and ecosystem of extensions for importers and exporters. However, their current ecosystem is a fraction of what is ultimately possible—I’d like to see SSGs tout Contentful support on their homepages, as well as hundreds of integrations and contributors, not tens. Their solution also requires dependency on connection to the Contentful service, which requires online availability, which means no offline/local development/testing/previews. It also requires fitting within their payment plans, which in turn allow for premium support. Finally, as their solution is a coupled solution, performance and customisation are sacrificed for convenience. None of which are necessarily bad things due to the tradeoffs each thing provides, however still they are limitations worth noting.

What proposals exist for what can be done?

• Existing static site generators can continue to try to meet evergreen needs like realtime content imports and client updates with their existing architectures but ultimately fail as their architectures can only hack such features into them, rather than support them by design
• Contentful can allow local installs of their platform to solve the local development, testing, previews issue, as well as improve their ecosystem and API to offer more power to the developers as a workaround for their proprietary nature.
• The community can organise to develop these ideas further, into an open and collaborative effort between forward-thinking static site generators. A database system will need to be picked, I believe rethinkdb is the best for this, but it should be discussed. Once picked, work can then commence on Importers, Exporters, API Extensions, and Native Interfaces around the chosen database system. SSGs can then update themselves to be exporters for this new system — giving them the benefits of this new united system. An agnostic database system is also an option but its complexity over agility makes it better for a later feature of the system rather than an initial consideration.

2017’s Generation of Static Site Generators was originally published in Bevry on Medium, where people are continuing the conversation by highlighting and responding to this story.

Your name & project introduction

Benjamin Lupton, however you’ve probably used my software under the Bevry moniker instead, among others. I’ve been writing software for the commons since 2005, with now hundreds of npm packages that get 500 million installs a month, that’s 10x more installs than react gets which is by a well funded team.

Motivation behind the OSS project?

It has always been to scratch my own itch, with solutions that rethink and thus simplify the problem space.

In 2005, I set myself up with a teenage blog and wanted to customise it, this saw the creation of various plugins for PrototypeJS (such as Lightbox), for jQuery (such as jQuery Lightbox), and for b2evolution. Eventually I started getting commissioned to build plugins for other people, to scratch their issues too.

In 2010, having watched Google continue to fail miserably to properly implement client-side state management with their hashbang implementation, I leveraged my prior expertise from creating jQuery History and jQuery Ajaxy, to innovate History.js, which solved the problem properly and became one of the top javascript projects in a week.

In 2013, I saw a gap in the technological market again and implemented one of the first notable Node.js projects, a dynamic static site generator called DocPad; its ideas are now seen in tools like Remix and Astro. To make DocPad possible, I first had to lay the groundwork and invent alongside it hundreds of low-level dependencies to empower the higher-level use cases. Even after DocPad’s demise; many of those dependencies have gone on to be foundational to the Node.js ecosystem, enabling the high-level use cases that enterprise depends upon, and enabling the direct dependencies of today that get the eyeballs and sponsorships.

Since then, I’ve been significantly constrained with my open-source portfolio due to a lack of funding; so despite grandiose zero-to-one ideas, my contributions have focused on automating maintenance and easing the maintenance burden.

Number of contributors across all your projects

Open-source projects can take many forms over their lifecycles depending on the intent of the project.

For most libraries, you’ll have a core maintainer, and then contributions are limited to minor fixes and improvements (this is about 99% of my repos — with perhaps 0–5 contributors per repo).

Some projects are intended to be an ecosystem, such as DocPad, where there is an expertise barrier to the core, so that has been mostly me, but alongside a rich plugin ecosystem with a lower barrier of entry. This project reached dozens of active plugin developers and about 150 contributors across its ecosystem from memory.

Some projects are intended to be collaborative, such as the Definitive Listing of Static Site Generators or the Definitive Listings of Text or Binary Extensions, in which a core maintainer lays the groundwork, but the majority of commits are subsequent pull requests; with core maintenance focusing on compatibility with ecosystem conventions and changes.

Some projects grow beyond their original intention, in which their core maintainer will be a merry go round while different companies have different requirements, such as History.js and the typical Browserify maintenance system.

All in all, there’s at least 200 contributors over my several github organisations; however 99% of it has been me, and the automations I’ve written. Which is quite different to some other github models where it is under a brand that initiates it, receives the funding, but outsources all the work to others; which results in high throughput but varying conventions and quality.

What projects are you working on today?

Since 2018, my focus had switched to end user applications, however they are beyond my means to implement in a way that can withstand plagiarism from more well funded entities (the late mover advantage), so they have been shelved. Instead I’ve focused on Dorothy, a dotfile ecosystem that anyone who has ever opened a terminal can benefit from, and most recently Fareness to address the aforementioned competitive issue; it will attempt to give open-source developers a competitive chance against secret keepers who have an extended competitive playbook, which in game theory will always win, unless regulated with (dis)incentives; which is what Fareness will do, it’ll enforce reciprocity either via source or funds, so indie open-source devs can have a fighting chance against plagiarism cohorts, late movers, and extend and extinguish strategies.

Is this a full time gig for you or do you do other work on the side?

The demands are definitely full time, in fact they are more than even I can handle. In all the 17 years I’ve done this, my open-source work has only brought in about $100,000 dollars, which is a wage gap at least an order of magnitude smaller than the equivalent work in a closed-source environment. This is why the indie open-source developer is underrepresented, it is an endangered species, outcompeted by the security, safety, and perks of salaried employees whose open-source efforts are loss-leaders to closed-source returns. To really drill this home, History.js was one of the top 5 javascript projects during its time; used in everything and by everyone; it demanded a full time workload (at one point I had thousands of github issues across my repos to work through); yet it received zero dollars of funding and support. I use to feel as a failure, and have incredible shame that I couldn’t support my work in the way it needed, and eventually the project starved to death from unavoidable neglect; this was at the time when a zero-commit streak on github would shame you with “current status: a rock in a hard place”; I wrote an open issue to github, requesting better support to their top users, which was cosupported by many other devs in the same situation, however it went ignored; salaried employees just couldn’t seem to understand this “slavery to servitude” experience that top indie open-source devs were having. Eventually, most of them would take a hint and drop out and leave, and their abandoned original works would go on to be replaced by plagiarism cohorts under consistent brands.

How much do you need to make this a full time gig?

Just $500/month would allow many of us indie devs to keep our heads above water and stop incurring further debt. However, ultimately, the goal shouldn’t be sustainable asceticism, but ‘like for like’ salaries; we see that the work is important, and abandoning and fragmenting it is damaging, but due to simple economics, scarce resources aren’t traded for free resources, so there is no imperative for ‘like for like’ pay; as such, I believe solutions like Fareness that enforce reciprocity are the only solution for widespread fairness, and not just the sponsored celebrity endorsement model we have today.

What does this money mean to you & what it will enable for your project?

For developers, it will enable the same opportunities that salaries offer employees: A reduction of debt, building of savings, freedom by vehicle ownership, safety by house ownership, security by healthcare, the opportunity to have and support your family.

For projects, it’ll afford the time to maintain them; this means:

• improved productivity for your own developers as maintainers can afford the time to keep their packages up to date with the latest conventions, which also reduces lost time to fragmentation across the ecosystem
• reduced risk as maintainers can afford the time to keep their own dependencies dependencies up to date and patch disclosures reactively and proactively — and unfortunate events are prevented or able to be responded to quickly
• most importantly; maintainers are smart and innovative people, which is why developers elected to use their packages time again, and by funding them, they can afford to contribute new innovations to the commons, enabling companies to better compete with each other.

How does it make you feel knowing that company x is using your project?

The first several years, it felt magical and important; that I’ve made a difference, made an impact, made that dent in the universe. But as the bills accumulate, and the companies that sell your work within a closed-source product get richer, you start to recognise you were just their free labor, and that is part of their competitive advantage; it gets old fast, and is why startups avoid open-sourcing their IP.

How does it make you feel knowing that company x is sponsoring you & your work?

It really matters, even if it is $1/month, it really matters. Reciprocity is a critical piece of civil technology of sovereignty, and if it fails, monopolisation ensues and empire’s colonisation triumphs. There are pros and cons to both models, so no need to be an ideologue about it — however imbalances when not corrected meet chaos; we are seeing over the years, even in open-source, an increase in rebellion from the sovereignty side as the empire side expands. Moderation to ensure both sides gets a seat at the table, have representation, and are supported, goes far to ensuring the bridge symbioses remains open and that parasitism avoided.

What message do you have to companies that are giving back to the community?

Services that reward breadth, splitting $1000/month to a thousand developers makes a much bigger impact than the three hundredth sponsor to the top ten developers again and again. Keeping a thousand developers afloat, so they aren’t rebelling or dropping out, is much better than another house for the memorable. It only takes about $500/month to keep the ascetic head afloat, yet it takes $17,000/month for a top-end competitive salary; if $17,000 was split, that could keep 34 developers afloat. If say 34 companies each do this split, then that is now $17,000 to each of the top 34 developers, rather than another $578,000 to the top dev. There are certainly advantages of the celebrity sponsorship model, the same advantages behind the adpocalypse, however it goes back to the empire vs sovereignty issue. Having a thousand, or even a million companies, sponsoring the top thousand or million indie developers, would go far for protecting sovereignty against empire, and allows everyone a fighting chance, not just the monopolies.

What message do you have for companies that are considering donating?

Even $1/month makes all the difference. It isn’t just you, it is a very ghandi-esque ‘be the change you want to see’; it scales not just the impacts of your behaviour, but it also scales your behaviour to others too! There is a human bias towards following, to not risk standing out; but if a few do, people are generally supportive and welcoming, and you become a beacon. When you donate, you aren’t just donating, but you are spreading the idea of donating, you offer your actions and the ideas behind your actions, a fighting chance.

Generally speaking, what do you believe the factors are in the open-source funding issue?

Normativeness

Any initiative, be it singular or collective, has a telos (a set of values and goals) that manifests and constraints its ethos (behaviors, culture); the more ethos supported by a telos, the wider the normativeness; the more rigid the ethos must be, the narrower the normativeness.

A company that has a wider normativeness can hire more employees, with a more diverse culture. A company that has narrow normativeness can hire less employees, as its culture is more superficial. Companies can also have a narrow normativeness for their internal culture, and a wide normativeness for their external culture.

Companies sponsoring individual developers directly are exposing themselves to this normative risk — it signals support of the developer — does the developer comply with our internal normativeness, our external normativeness, or neither?

Having companies sponsor intermediaries such as ThanksDev and Fareness, allows the intermediary to diffuse this normative risk instead of the company. In the same way we are against sweatshops, but still buy devices and products that used them, because for most of us, that is the manufcaturers problem not ours. Intermediaries allow us to partake in the value, while allocating the risk and resolution to the responsible parties.

Awareness

The biggest issue with current funding paradigms (direct sponsorship) is that they reward only those who funders are aware of — this is either monopolies already, or developers of direct dependencies — yet most of our dependency trees are indirect dependencies.

The realm of indirect dependencies is comprised of hundreds of prolific developers, and plenty more smaller developers. Optimizing for breadth in direct sponsorship will help this: having thousands of companies giving equal money to thousands of developers, or at least a hundred developers, instead of just five or ten. However, the solution is that which a single payment goes to potentially millions of developers.

The ecosystem needs to do a better job of raising awareness for the need to fund a larger breadth of developers so they can keep their heads above water, so such developers are found and supported, or to promote solutions where a single payment is split between a plethora of developers.

The other issue here, is that many prolific devs will choose to collaborate under a github organisation that is a moniker — not a personal brand — and as such, there is the false assumption it is a well-funded company that doesn’t need funding as it has high throughput — yet it is just some committed indie devs.

Scarcity

While sponsorship is the dominant way of funding indie developers, it isn’t the dominant form of funding open-source, which is open-core, or rather giving a portion of your source code away, yet increasingly moving the key value into closed-source offerings. This is not good for the commons and it is not good for companies’ abilities to compete with each other. It moves the open-source landscape from indie developers to big companies that can extend and extinguish competition better.

Enforcement

What open-core has recognised, is that the scarce resource of money isn’t traded for the non-scarce resource of open-source code; there has to be a scarce for scarce trade at play. This can either be in the form of advertisements of sponsors (this is optional so is not enforced), the form of open-core (scarce extensions, this is partial so is only partially-enforced), or in the form of dual-licensing (open-source but charges for commercial use, this has been lacking the ability to enforce). Developers are now looking to solutions like Fareness to allow enforcement of dual-licensing.

Black Sheep

Prolific developers may decide to leave the industry if their efforts are not reciprocated. This has taken many forms, some silent, some vocal, some rebellious. What they all have in common is a feeling that they are black sheep, that their work is consumed yet they are not rewarded, that the industry is not rejecting their work but it is rejecting them. This exodus of top talent from open-source is awful and hurts everyone. Companies should take pride when funding the breadth of open-source, ensuring the developers of the commons that their products are built upon are also valued, and not just their employees.

Let me know your thoughts, which you can also do so privately by emailing me at b@lupton.cc — happy to chat.

If you wish to fund once and have it distributed to many developers of the commons, then these services are live today: ThanksDev, StackAid, TideLift

If you are inclined to support me directly, you can do so via GitHub Sponsors.

And if you despise everything about this, then please consider funding a service-dog for Helen instead.

Indie Open-Source Sustainability was originally published in Bevry on Medium, where people are continuing the conversation by highlighting and responding to this story.

Currently Bevry (our open-source community) earns $0.52USD/week from Gratipay donations, and also received $6000USD at the start of the year by the wonderful Hybris (thank you), coming to around $6500USD for the past 12 months (weekly donations were a bit higher before Gratipay v2.0) — this amount turns out just isn’t enough to live productively, and just isn’t enough to work on a projects that demand a full-time workload. A change is required.

A little bit of history of what has worked and what hasn’t. Bevry created two very popular and involved open-source projects; History.js and DocPad. Over the recent years, our focus has been solely on DocPad. DocPad has been around for 4 years now. In 2011 DocPad was a personal side project for myself with DocPad getting a few hours of attention a month, in 2012 DocPad and its associated projects were used in few consulting gigs getting a few hours a week, in 2013 DocPad was sponsored at $6000USD/month by the amazing Myplanet (thank you) and got a full-time workload, in 2014 the income disappeared so I went moneyless to see if that could work which it more and less did although it did decrease the investment into DocPad to a few hours a month — it turned out that moneyless living (at least for me) requires a lot of time for finding shelter, finding food, etc as well as eliminates any chance to obtain items of scarcity such as computing equipment/services to work productively like a phone that isn’t generations old or even a domain name renewal, or the right consistency and quality of food and shelter for a good consistent baseline of health — perhaps I can write about this sometime so other people interested in moneyless living can learn a balanced perspective, particularly around the role of scarcity and abundance including the commonplace abuse of each by society and individuals.

It is now near the end of 2015, and I’m tired of this. I’m tired of an endless stream of unpaid requests from users. I’m tired of having created two incredibly popular open-source projects (DocPad and History.js) that demand full-time workloads and 183 node.js packages that demand occasional maintenance, that don’t provide enough income to cover their investments. This wouldn’t be that weird if it was just myself using these, but these projects aren’t even small deals, these are projects used by Microsoft, Basecamp, GitHub, 37Signals, and so on — in internal projects as well as projects that reach millions of users each day. These are projects that deserve more attention than I can afford to give them.

In 2015 I shutdown Bevry the company which provides me with legal protection because I simply couldn’t afford the accounting anymore. In 2014 I wrote “Surviving Free Culture” a story of the strain open-source has on the mental health of the maintainers. I’m tired of this being a problem.

But Ben, come on, why don’t you just distribute the workload of these projects across many independent company employees? That’s an option when that’s an option, but it isn’t always applicable for these reasons:

1. Splitting the breadth of an entire project over several people requires the breadth of the entire project to be understood through several people. This isn’t always feasible to do during the initial phases of a project (it doesn’t really make sense to decouple a project before a project’s coupling is even established) and it isn’t always possible during later phases of a project either (as it could require an exorbitant amount of unpaid time to do the decoupling) — these factors make up DocPad’s case.
2. History.js however is already as small as sensible, breaking it up further would hinder efforts to understsand it. Many people understand it, however maintenance of it is incredibly time intensive, as testing it takes a lot of time and understanding and merging pull requests including debugging issues from many people from different use cases and companies takes another exorbitant investment of time that just isn’t possible unless done full-time and paid.

Ok Ben, but what about other business models like:

• Premium Prioritised Development: We’ve offered prioritised development (where development gets sponsored and prioritised) over the 4 years of DocPad being around. This has been requested twice, and proceeded once to $2000USD from it over the 4 years of DocPad’s existence. It’s just not enough.
• Premium Prioritised Support: We’ve offered prioritised support for History.js and DocPad since their inception, as mentioned in their READMEs and on the DocPad website. This has been requested once, and proceeded for $40USD. It’s just not enough, plus ideally everyone should get great support as the sooner a documentation or app improvement is made to fix the support issue, the less support issues around the problem will arise in the future.
• Premium Prioritised Trainings, Workshops, Online Courses, etc: These have been suggested as options, but never booked — indicating there just isn’t enough demand.
• Premium Features: This is something we originally planned, but as Eben Molgen’s argues and in Marco Arment’s Overcast 2.0 business model announcement demonstrates — having most of your users stuck with an inferior app because they won’t pay or are unable to pay, doesn’t make sense in terms of competition or empowerment.
• Crowdfunded Milestones: We have considered this but there just hasn’t been anyone so far to put their hands up to support this so far. If there turns out to be demand for this, we can evaluate it further.

Ok Ben, but come on, of course investing more time into something than your business model affords you is how debt is created and burnout and bankruptcy occur, just abandon the projects if they aren’t worthwhile and do something else. Completely correct, and that sucks, as I said before, these projects deserve attention, they are big deals! One would have thought that donations or sponsorship would work considering their reach and impact, but even after considerable investment into promoting those options over the years, they just aren’t working — and that haunts me, it haunts me that each day people use these projects often in high-profile use cases, each day people tell me all about the potential for these projects, each day the demand for these projects increase, each day the amount of requests for changes and support increase, each day their impacts on the wellbeing of the world increase, and each day their possibilities increase — however there just aren’t any funds to sustainably meet that demand without increasing psychological and financial debt to myself — and this isn’t even a problem unique to Bevry’s open-source initiatives, it’s a problem for many open-source projects and maintainers of which I’m familiar with and I’m sure even more that I’m not familiar with, a fact that haunts me even more so.

So I’ve reached a point, where I’m not going to let that happen anymore.

I’m going on open-source software strike.

From now on, I’m only going to invest time into open-source under the following conditions:

1. It is for my own benefit
2. It is paid by someone else for their benefit

I am no longer going to:

1. Work for free for someone else’s benefit and not my own

However, considering the current climate of donations and sponsorship, this means that effectively I quit my open-source maintenance, as $0.52USD/week doesn’t really afford much time to support full-time projects. Which sucks. So in order for that not to happen, in order for those projects such as DocPad to get the maintenance that they deserve, I have a proposition for DocPad that I would like your feedback on.

Here it is:

1. DocPad will become paid software.
2. This will probably be accomplished via paid subscriptions. Implementation, structure, and pricing is still to be determined and feedback welcome. Perhaps something like $500USD/user/year or $1000USD/site/year (5 users working on 1 site, will mean you can either pay $2500USD/5-users/year or $1000USD/site/year).
3. There will probably be some trial mechanism like a 30-day trial.

But Ben, what about all the years of your evangelising that money and closed-source software are immoral? Eben Molgen’s case is still sound to me, so I’ve thought a lot about this and believe I’ve come up with a decent enough solution:

1. DocPad will remain permissively open-source licensed.
2. There will be a pirate mode introduced to DocPad, accessible via a `--pirate` flag added to the CLI and options of DocPad, it will let DocPad run the same as purchased, with some caveats with details as follows.
3. The pirate mode will output a message like the following, which captures the spirit of this mode: I understand you may not have the ability or desire to financially contribute back to this project so the maintainers can afford the ability to feed themselves and the time to improve the software, so perhaps instead you could offset that cognitive dissonance by contributing some time to improve the project or by considering this unrelated yet perhaps more important set of data http://balupton.com/v
4. The pirate mode will generate the website with a non-visible indication that it was generated using the pirate mode, probably something like changing the meta generator content value from `DocPad v6.78.3` to `DocPad v6.78.3 (Pirated)`
5. Usage of the pirate mode will be reflected in the usage statistics. Our Privacy Policy already indicates that usage statistics will only ever be visible outside of Bevry and the necessary 3rd-parties required to provide the usage statistics to Bevry.
6. There may or may not be a public shame list on the DocPad website of live websites that were published with the pirate mode. I’m unsure how I feel about this at this, keen for feedback on this.

So this is all pretty crazy so far, so here is the reasoning for how this all makes sense, at least to me:

1. The beauty of commercial software is that the business receives money directly for what the users are actually using, which is incredibly sustainable: it is good for the business as they are encouraged to spend their time working on what pays for their time, and is good for the user as their payment encourages the business to focus on what they paid for. There are no conflicts of interest where the money earner is what a minority of users actually use (premium features) or something that none of your users actually use (advertising), requiring and perhaps even encouraging business investment into something conflictual to the interests of the majority of the users. Investments into the product can be proportionate to the value of the product to its users — a lot of users means a deservably lot of investment into the product, a small amount of users means a deservably small amount of investment.
2. The beauty of the commercial and pirate mode, is that it provides an ethical default case for the flow of the product. If you are a business using DocPad for profit, you now have a moral responsibility to pay for the software — if it is reasonable for you to purchase it, then it means you should, however if it is not reasonable for you to purchase it then you can pirate it instead — whether you do or you don’t is up to you, you remain empowered either-way, however this clearly establishes a default workflow and a moral responsibily — establishing both the shoulds and shouldn’ts while enabling the cans and can’ts.

The reasoning for why do this verse quit or continue as is:

1. This is the only way I am currently aware of that can provide the necessary sustainability for DocPad to accomplish its full potential and get the time its impact deserves. For DocPad users, imagine a paid team of people working on DocPad full-time (scaling to the income), providing great documentation and support, videos, trainings, conferences, incredible performance and speed improvements (minutes to seconds), and all the rest indicated on the Bevry roadmap on our zero donations so far Patreon.
2. If I don’t do this: things will continue unsustainably, that is to say I will incur psycholohical and financial debt for working on my open-source initiatives, leading me to quit open-source or end up in a ditch.
3. If I do this and it works: we get a model that can sustain development of DocPad and its associated open-source projects in a way that empowers everyone while making business/financial/psychological sense. And if it works, it could even be scaled to other open-source projects suffering the same issue if feasible, of which there are many.
4. If I do this and it fails: then at least I tried, and we know yet another business model that doesn’t work for open-source, which leads to me trying to find something else.

Thanks, keen to receive your feedback. Especially:

• Do you consider this proposal a good or bad idea? Why so?
• Will you leave the DocPad project if this proposal is implemented? If so, why? If not, why not?
• Are there any changes you would like to see made to this proposal? What are they?
• Would you consider this proposal beneficial or detrimental if implemented for your own open-source projects? Why so?
• Do you have any other feedback or suggestions?
• Do you have any encouragement?

Request for Comment: Open-Source Software Paywalls / DocPad Paid Subscriptions / @balupton goes on… was originally published in Bevry on Medium, where people are continuing the conversation by highlighting and responding to this story.

Cakefiles to Nakefiles

Previously our base files used CoffeeScript’s Cakefile for building, for instance `cake compile` would compile our project. Now continuing our migration from CoffeeScript to ES6+, we now use our own “Nakefile” system, here’s how it works.

Nakefiles are a standalone node file called `nakefile.js` which don’t have any other external dependencies while providing tooling for installing, compiling, testing, and releasing your project. Consider them like a cross-platform Makefile.

To get started with Nakefiles:

1. Add our base Nakefile to your project.
2. Add the optional npm run-script aliases.
3. Add/customise package.json:nakeConfiguration.
4. You may also want to add our base CONTRIBUTING.md file too.

This is a great move for our projects, and for all projects that want a light-weight cross-platform build system.

Heroku to GitHub Pages with Travis CI for Continuous Deployment

Heroku announced that in August they will require popular free applications to be offline for at least 6 hours a day. Bevry had been using Heroku for everything, utilising DocPad’s dynamic server abilities to perform regenerations in production of new documentation content. This announcement, partnered with the ocassional downtime such generations could cause, prompted us to move from Heroku to GitHub Pages, with Travis CI for Continuous Deployment. This migration completed incredibly succesfully. Our websites are now faster than ever thanks to production static serving and GitHub Pages powerful CDN network. They will also have permanent uptime now, thanks to every change to the website having to be tested first, and being generated locally rather than on the live production server.

We’ve updated our DocPad Deployment Guide with details on how to take advantage of this. We’ve also added a section on OpenShift deployment to it too, in case you still require dynamic servers.

New DocPad Releases

v6.78.2 and v6.78.3 are out, they break the multiple month gap between DocPad releases while I was taking my time off. These releases bring OpenShift support thanks to our new hostenv package, as well as minor improvements to our profiler support and hostname output.

Casper DocPad Skeleton

The beautiful Capser theme from Ghost is now available to DocPad users thanks to the work of DocPad user Drew Strickland who ported it over as an Official DocPad Skeleton. Which means besides just cloning it, it will also be an option when starting your next DocPad project.

Updated Projects

Other projects that have seen updates are Type Checker, Lazy Require, Safe FS and Ambi. All of which have been updated to ES6+, our new basefiles, and other smaller updates around that. They’ve also gotten rid of their `cyclic.js` file, which appears to be no longer needed thanks to updates to npm.

DocPad Extras has also been updated, which now includes automated testing of the integrity of the `exchange.cson` file that contains the list of the official DocPad Skeletons available for your disposal.

New Talks & Conferences

Our long-time DocPad user Łukasz Górnicki has been presenting his talk Documentation Continious Delivery at several conferences and meetups now, here’s the blurb:

My talk is about how we in hybris (SAP) use DocPad to generate devportal.yaas.io. where our whole YaaS is cloud solution based on microservices architecture. So how we enable our teams to deploy their documentation together with their service without CMS publishing nightmare.

Onwards, during my time off I gave a talk at BrisJS about Mental Health in Programming and my Hitchhiking Adventure. It’s now online.

Official Blogs

This Bevry Blog is now official, yep that means you can now access it at https://blog.bevry.me — we also now have an Official DocPad Blog at https://blog.docpad.org which is begging for content, so if you want to contribute articles get them on medium and submit them to that publication, submissions are warmely welcome.

Welcome to Slack

We’ve also updated our Official Support Channels to mention our new Bevry Slack Community. It’s going well, and we have several channels now with several active users. It’s a nice place to hang out with Bevry team members and Bevry users, while getting the latest news as it happens.

Fund our Roadmap on Patreon

We have a Bevry Patreon Page now. Needless to say, there are a lot of things planned for the future and we need funding to accomplish them. If you are an individual with some excess cash who wants to feel warm and fuzzy, or a company that depends on DocPad, consider donating/sponsoring the roadmap by giving on Patreon. We’d greatly appreciate it. If you sponsor high enough, you’ll even be listed at the bottom of these updates. Very cool.

What’s next?

We’ll continue our move from CoffeeScript to ES6+, as well as increase our support efforts through Slack. We’ll get a new helper service up and running, and move the Startup Hostel website to GitHub Pages as well. Then from there will be knocking off a few more of our Trello Cards, and then continuing with our Patreon Roadmap.

Want to help this Blog with editing or new blog posts? Let @balupton know in our Slack 😎

All the best,
Benjamin (founder of Bevry)

Bevry News 2015 Weeks 34, 35, 36 was originally published in Bevry on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today, as Bevry’s director, I filed the paperwork to shut down Bevry Pty Ltd (the company). Before you panic, this is merely a legal entity change. Bevry (the community) will continue as is — the only difference is instead of being run by the entity Bevry Pty Ltd (the company), it will now be run by the sole-trader entity Benjamin Lupton.

In 2015, Bevry obtained $6000USD of sponsorship from the wonderful Hybris, as well as ~$1500USD from our lovely Gratipay donors from their years of Gratipay activity. $7500USD over 6 months unfortunately just covered Bevry Pty Ltd (the company)’s operational costs for the past 12 months, and is unable to justify the operational costs of maintaining the Pty Ltd entity.

All operations will continue as normal. Behind the scenes, the following changes will occur:

• Bevry Pty Ltd’s bank accounts will be closed, and replaced by sole-trader bank accounts. This has been completed.
• Our invoice and sponsorship templates, along with our donation and bank account listings will be updated with the new bank account information. Will update on next issue.
• Copyrights and ownerships will see entity changes, where and when appropriate. Will be done as appropriate.
• Subscriptions and accounts registered as Bevry, will too undergo entity changes. Will be done as appropriate.
• Bevry (the trademark) remains owned by myself, with no entity change needed. No todo needed.

Again, Bevry (the community), including our projects, our initiatives, our ideas on business, et al. will all continue to operate as normal. This is merely a legal entity change as there is no financial or strategic sense to maintain the Pty Ltd entity over a sole-trader entity at our current revenue levels. We can always reincorporate Bevry Pty Ltd at a more appropriate time (say if we once again bring in more than $72,000AUD in a financial year). Sole-trader entities are at increased legal risk over Pty Ltd entities in the case of legal issues, but oh well.

All in all, I’m happy and excited by this step, which is biting the bullet to do what’s right for the current situation’s demands. While the company Bevry Pty Ltd joins the statistics of yet another failed startup, I’m glad our community and our initiatives will not join that statistic and will continue to live on — a lively success, one that our community deserves credit for.

Bevry Pty Ltd (the company) ran from the 18th of July 2011 to June 2015 aging 4 lovely financial years.

Bevry (the community) marches from 2010 and onwards!

Further questions about this change can be directed here or directly to me at b@bevry.me

Changes to Bevry was originally published in Bevry on Medium, where people are continuing the conversation by highlighting and responding to this story.

Core Releases

• v6.53.0 September 17, 2013
  - Improved configuration loading
  - Improved locale support
  - Fixed subscribe and tos metrics
• v6.52.2 September 12, 2013
  - Fixed completion callback errors
  - Better iconv loading
• v6.52.1 September 8, 2013
  - Fixed “structure already exists” errors when scaffolding
• v6.52.0 September 8, 2013
  - Improved statistic reporting
  - Fixed DocPad::getBlocks() return value
  - DocPad now exists gracefully instead of forcefully

Full changelog available here.

Plugin Releases

• Services
• UMD

Ecosystem Releases

• InlineGUI
• js2coffee
• CSON
• Projectz
• Caterpillar
• Taskgroup
• TypeChecker
• Ambi
• Domain (Browser)
• Events (Browser)
• DocPad Helper
• SafePS

As well as all the amazing 3rd party plugins that have been published but not listed here. Thank you all to those amazing plugin authors!

Meetups

• DocPad and Semantic UI discussion
• DocPad’s Ecosystem at SydJS
• DocPad at IT Business Plaza in Japan

Developments

Documentation Rethinking

We got a huge amount of interest in improving our documentation! So much that we’ve actually put together some criteria for documentation changes and are brainstorming ways to improve the documentation and improve the website as well.

A place for requesting Trainings and Meetups

We put together two new repositories for the community, one for requesting meetups as well as one for requesting trainings. The most requested training so far is a Query-Engine Training so if you’d like to see that happen be sure to +1 that issue and perhaps place bounties to help it along.

Business Interest & Discussions

As business interest in DocPad increases, we’ve embarked on how to help enterprise clients to see the benefits of Static Site Generation and have created the Go Static campaign to help facilitate that along with the rest of the SSG community.

Sponsorship and Contributor License Agreements

As the community grows, we also started the process of figuring out how we can best protect the community and the projects during this time of rapid growth. Provide your thoughts and feedback here.

Summary

We saw huge growth this month, lots of new faces, and lots of valuable pull requests, issues, discussions, feedback, and tweets all round. Keep it up!

The next month will be focusing on refining the efforts made here with stabilising this rapid growth of DocPad and it’s community. As well as working on exciting new projects like Web Write’s InlineGUI, a new DocPad Website, and more abstraction of the core.

Special shoutouts go out to Eduán Lávaque for his championing in the IRC Channel as well as his YouTube Videos on DocPad, Chase Colman for his participation in refining the community growth plans and looking into the watchr issues, our amazing and anonymous Gittip Donators we love you!, and Myplanet Digital for their continued financial support. And everyone else playing their amazing roles in helping this all come together.

It’s an exciting project to be a part of at such an amazing time. So thank you for being part of it, and thank you all for your continued tremendous support.

• Benjamin Lupton, founder Bevry.

On September 25, 2013 I gave the talk “DocPad’s Ecosystem” at SydJS, the local JavaScript meetup here in Sydney. You can watch a re-recording of it here.

It went very well, was well received, and paved the way for a consolidated vision for DocPad’s future, as well as unified marketing strategy to accomplish that vision.

Originally, the presentation was set to be all about the techincal roadmap we’ve accomplished in the last 2.5 years, but after deeply connecting with the the book The Presentation Secrets of Steve Jobs which delievered one point very well — it is all about the story and experience that creates. I was swept into a pardaigm shift, a looking lense on how DocPad was able to reach its success today, and how it will can continue to do so in the future.

That brings me to what makes DocPad so darn interesting.

Amazing Developer Experience

The success of DocPad so far has been based on it’s ability to deliver an amazing developer experience. You can get up and running in a new website in minutes, deploy it to any web host (dynamic, static, it doesn’t matter), and hack away things like you’re playing with Lego. It’s abstraction friendly, fun, and get’s out of your way.

This path, this reasoning, this experience was well grasped and beautifully catalogued by meltmedia the company that designed our current website as well as our current marketing slogan, that enticing DocPad Sets You Free that we’ve come to know and love so well.

This vision, and the combined manifestations of it with our contributions and yours, have helped serve all of us as developers incredibly well. But now it is time to turn the next leaf, especially as businesses are growing interested, and partners are joining our initiative to provide services and solutions to businesses through DocPad and its ecosystem. It’s time for a new leaf to turn.

Amazing Client Experiences

This initiative was really paved by these three amazing people:

• Chad Auld, creator of DocPad Collections Editor
• Jérémy Faivre, creator of MiniCMS
• and Myplanet Digital, creator of Saasy CMS, which is paving the way for Web Write’s InlineGUI

These individuals were able to see that while DocPad is fantastic for developers, it needs a lot of work, now, in order to reach clients. While this has always been something on the DocPad Roadmap and Issue #123 it has really been the efforts of these people to help manifest our client experiences so quickly.

Even more recently, has been the combined efforts of Bevry’s initiatives with Decoupled Content Managementand Myplanet’s Saasy CMS that have given birth to the Web Write initiative that offers an interesting perspective on content management going forward; great experiences can be decoupled.

Decoupling Great Experiences

For those new to the decoupled content management initiative, it can be summed up with the following rules:

1. Don’t couple creation experiences to backend experiences and vice versa
2. Backends and frontends should operate independtly and angosticly with each other
3. If a developer wishes to use X backend, and a user Y frontend, that should be possible

This has come together quite nicely with the Importers Implementation that DocPad has offered for a while now, allowing people to use their existing content creation services (like Tumblr already, and eventually things like Wordpress, Dropbox, Medium, etc) along with DocPad on the backend.

The recent efforts between Myplanet and Bevry have been able to show the flipside of this coin, we can also create great decoupled content creation experiences that work with any backend. So you could hook InlineGUIup to not only DocPad, but also Wordpress backends if you wished to have the necessary adapter created.

This is really quite amazing, in terms of being able to always provide the greatest content creation experience for writers, and the best backend experience for developers, ensuring the best experience for everyone.

But it doesn’t stop there, the community has also voiced new ideas as well.

Great Decoupled End-User Experiences

End-user experiences could come in form of a CodeKit lookalike for designers powered by DocPad on the backend, or even a Wordpress.com style Software as a Service solution allowing people to create DocPad websites directly in the cloud instead of on their local machines, and an accompanying iPad app.

These are just some of the ideas brewing, but you can join in the discussion on where to take this here.

Summary

In closing, DocPad is tying all the pieces together nicely to create great decoupled experiences for everyone. It’s going to be very exciting to see where this can go.